Open letter to Jon concerning M3

[Ayespy]

@luetage GMX.de as best I recall.

[luetage]

@ayespy That's what I thought. It's probably the biggest email provider in german speaking countries. But it's a mistake to believe IMAP isn't working -- I'm using it on my gmx address for over 10 years, on a free account (no pro version needed).

Give them this link.
https://hilfe.gmx.net/pop-imap/imap/imap-serverdaten.html

[Ayespy]

@luetage I'll pass on the info.

[saudiqbal]

I have been using Gmail since it came out, therefore imap is enough for me. I read and delete my emails, so no need for any pop3 for me.

[Codehunter]

@morg42 said in Open letter to Jon concerning M3:

I see clear advantages to developing separate apps: you can have independent release cycles, maybe even different dev teams, and although often overlooked, smaller downloads for the individual programs.

This point is actually raised every time the issue is raised. Those who know a little bit about software development know that this is wrong.

Most applications are modular and use dynamic libraries (. dll under Windows, I think they are called. so under Linux). The function parts that both programs have to share, for example the renderer for HTML mails and image attachments. However, there are also parts of code that cannot be stored in libraries. These are compiled into the main program. Exactly these parts lead to the fact that both programs would be bigger together than if one integrated the function part E-Mail directly into the browser program. However, the difference is likely to be in the single-digit megabyte range. This is unlikely to be a problem at the present time, even with below-average Internet connections.

I also see advantages in the development of a monolithic application. Especially the common work of the developers on browsers and mailers can lead to a better security of the mailer. You have seen for a long time what happens when independent teams have worked on IE and Outlook. The mailer was full of security flaws until the development was structured differently.

Maybe we should look at e-mail differently now than before. Historically, POP3/SMTP and HTTP have come from different directions. We therefore tend to view them separately. However, they have continued to grow together. Since webmail interfaces have existed in the browser (the prime example here is OWL - Outlook Web Access), the boundaries between the two services have finally become blurred. Actually, it is no longer the transmission protocol that matters, but how we communicate today. One could also say that every webchat is a further development of AIM and ICQ. Everything has been moved from a separate program to the browser.

From a technical point of view, the only difficulty is to integrate the shortcomings of the stone age protocols SMTP, POP3 and IMAP into a modern program and implement local data management.

---

Dieser Punkt wird eigentlich jedes Mal angeführt, wenn das Thema zur Sprache kommt. Wer sich ein wenig mit Softwareentwicklung auskennt, der weiß dass das falsch ist.

Die meisten Anwendungen sind modular aufgebaut und nutzen dynamische Bibliotheken (.dll unter Windows, unter Linux glaube ich heißen sie .so). Die Funktionsteile die beide Programme gemeinsam nutzen müssen, beispielsweise eben den Renderer für HTML-Mails und Bildanhänge. Es gibt jedoch auch Codebestandteile, die sich nicht in Bibliotheken auslagern lassen. Diese werden fest in das Hauptprogramm einkompiliert. Genau diese Teile führen dann dazu, dass beide Programme zusammen größer wären als wenn man den Funktionsteil E-Mail direkt in das Browserprogramm integrieren würde. Der Unterschied dürfte sich aber im einstelligen Megabyte-Bereich bewegen. Das dürfte in der heutigen Zeit selbst mit unterdurchschnittlichen Internetanschlüssen kaum ein Problem sein.

Ich sehe dagegen auch Vorteile in der Entwicklung einer monolithischen Anwendung. Gerade die gemeinsame Arbeit der Entwickler an Browser und Mailer kann eine bessere Sicherheit des Mailers bewirken. Man hat ja lange Zeit gesehen, was passiert wenn unabhängige Teams an IE und Outlook gearbeitet haben. Der Mailer war mit vielen Sicherheitslücken behaftet, bis man die Entwicklung anders strukturiert hat.

Möglicherweise sollten wir E-Mail inzwischen auch anders betrachten als früher. Historisch sind POP3/SMTP und HTTP aus verschiedenen Richtungen gekommen. Wir neigen dazu, sie deswegen getrennt zu betrachten. Jedoch sind sie immer weiter zusammen gewachsen. Spätestens seit es Webmail-Interfaces im Browser gibt (das Paradebeispiel ist hier OWL - Outlook Web Access), sind die Grenzen zwischen beiden Diensten doch endgültig verschwommen. Eigentlich kommt es doch gar nicht mehr auf das Übertragungsprotokoll an sondern wie wir heute kommunizieren. Man könnte doch auch sagen, jeder Webchat ist eine Weiterentwicklung von AIM und ICQ. Hier wurde doch auch alles von einem separaten Programm in den Browser verlegt.

Die einzige Schwierigkeit aus technischer Sicht besteht doch darin, die Unzulänglichkeiten der steinalten Protokolle SMTP, POP3 und IMAP in ein modernes Programm zu integrieren und eine lokale Datenhaltung zu implementieren.

[Morg42]

@codehunter said in Open letter to Jon concerning M3:

Exactly these parts lead to the fact that both programs would be bigger together than if one integrated the function part E-Mail directly into the browser program.

I only said that the single-program downloads were smaller (than an integrated one), not that both together were smaller. Combined with release cycles, this might save some bandwidth.

However, the difference is likely to be in the single-digit megabyte range. This is unlikely to be a problem at the present time, even with below-average Internet connections.

Seeing how (mobile) internet traffic is being weighed in gold e.g. in Germany (compare volume rates and offered data packages to Austria or Scandinavia) and also that mobile bandwidth is only a shared resource, I think there is not enough consideration towards keeping traffic volume down. (Not even to think about video streaming or ad volume..)

This is not so much a practical problem as a general question of principle, as you may have noticed...

I also see advantages in the development of a monolithic application. Especially the common work of the developers on browsers and mailers can lead to a better security of the mailer.

Which just goes to say that the security level of the shared libraries is inherited by all applications using it. Thay may or may not be an advantage...

You have seen for a long time what happens when independent teams have worked on IE and Outlook. The mailer was full of security flaws until the development was structured differently.

Choosing Outlook and IE of all things as an example for security seems.. bold. I hold this to be the prime example of why not to integrate browser and mail technologies. While a browser might be seen as a multifunctional JS-based application host (and still has security issues caused by JS program code), I can't see why this should even be possible in Mail. I'd envision a really tiny HTML renderer for mails (if any), which doesn't even know what to do with JS...

Maybe we should look at e-mail differently now than before. Historically, POP3/SMTP and HTTP have come from different directions.

Funnily, this is not true. Historically, both mail and www were meant for pure information exchange, as gopher before. No one needed fancy font faces or coloured text in mails. It was about content... once.

We therefore tend to view them separately.

And seeing how security-minded many people are towards websites today (luckily), and how naive (security-wise) many people are towards mails today, as well we should view them separately.

Can you tell me why phishing - even in worst form with bad grammar and orthography - apparently works so well that still someone invests money to send the mails?

No, mail should absolutely not be seen in unison with the web.

Sure, one fundamental problem of mail is the "transport organisation", proving who sent a mail still is not possible without getting deeply involved. But as long as this is not resolved, I think it should be a task of the mail client to protect people from harm. And showing fancy login pages and barely facsimile links to known sites should not be encouraged.

However, they have continued to grow together. Since webmail interfaces have existed in the browser, the boundaries between the two services have finally become blurred.

Sorry, but I don't agree.

The browser is - per webmail - increasingly used as a mail client, yes, I guess you are right there (even if I don't see the upside except for universal accessibility).
But a webmail client will never be able to perform as well, as fast, as feature-rich as a dedicated mail client. (The fact that in most (?) cases webmail binds you to the specific mail provider is still another thing.)
Seeing mail as just another application of www leads to exactly the problems we have. Most integration between mail and www seems to be opening links and not having to switch applications for whatever reasons.

One could also say that every webchat is a further development of AIM and ICQ.

Did you ever use IRC?

Everything has been moved from a separate program to the browser.

Hm. If I examine my systems, my browser is only used for browsing (including forums). I have separate mail, chat (irc, whatsapp), terminal, text edit, maps, news (rss), calendar, contacts, banking and whatever apps. I even use a plugin to integrate text editor and web browser, so I can use the extended functionality and comfort of my text browser over a browser-provided text field editor to write this message...

But this is exactly the point. As long as for you everything converges in the browser and you don't want (and don't see) my perceived advantages and added value of separate apps, we will not get on the same side of the argument. I am aware that my conception of using technology might be different from that of many other people.

From a technical point of view, the only difficulty is to integrate the shortcomings of the stone age protocols SMTP, POP3 and IMAP into a modern program and implement local data management.

If you solely use IMAP, a browser webmail client might suffice. As soon as you want local storage, a dedicated mail client is essential (if the mail client is integrated into the browser is not relevant to this point). Again, you have other ways of organising storage, indexing and searching with a native application than with a webmail interface using some kind of HTML5 local storage for mail archives. (my mail archive is ~5 gig from 2000 onward plus some MB index files, maildir format).

But this might get a bit off-course for the topic...

Personally, I'd be happy to see a separate M3 client, but I will not abandon V if it only comes integrated...

[Ayespy]

@morg42 It will come integrated, as I am using it now, and much to my advantage.

My optimal workflow is email (from which I obtain my jobs to be accomplished), bookmark to open the relevant initial page, bookmarks, tabs and webpage interface to move to additional sites, transfer of data to a text document, draft report, edit and email the document, go to the next assignment received in email. Frequently during research, I will move seamlessly between email, web pages, back to email, new tab, back to last tab, reference email again, etc. When email, web, tabs and bookmarks are all available at the same time in the same UI, my work is substantially faster than if I have to shift back and forth between apps.

I developed this workflow while using Opera 12 et prior, which had integrated email and the ability to integrate my email, web, bookmarks, tabs in vertical columns in the same interface in a wide gamut monitor. It is devilishly efficient, and my prime reason for wishing to have integrated email. Using email within Vivaldi returns me to the comfort of my old habits that I developed over more than a decade with Opera.

Further, email adds MUCH less to the size of Vivaldi than downloading or updating a discrete email client, adds efficiencies in resource usage on the platform, and best yet, adds zero to overhead if you don't activate it and set up accounts. Even with it activated, Vivaldi with email consumes much less overhead than Vivaldi plus separate email client. Plus, the presence and use of integrated email seems, to me at least, to impact browser performance not one iota. So to me, integrated email just makes sense. When Opera dropped it and it looked like I might never have it again, I really despaired.

But that's just me, one user.

[Ayespy]

@morg42 And, btw, the download with email is 1.56 Mb larger than the download without email.

[Morg42]

@ayespy said in Open letter to Jon concerning M3:

But that's just me, one user.

I accept everyone who has different views, workflows or peculiarities. I am only a single user, too.

[Pesala]

Why open another application for email? I spend most of the day online. Even if I am using another application to write a book or publish a web site, I will have my browser open for looking things up. Meanwhile, I have Opera running too (on my secondary monitor) so I can see at once if some email comes in.

I stop whatever I am doing, saving my work, before reading the email and dealing with it at once. If I am unable to reply to it for some reason, I tag it, then get on with whatever I was doing before.

After many years of using Opera M2, I still have fewer than 100 emails saved, but I would not want them to be on a server where I cannot access them if my Internet connection is down, etc.

[Morg42]

@pesala said in Open letter to Jon concerning M3:

Why open another application for email?

Yeah. Exactly the kind of argument I'd been waiting for...

I will have my browser open for looking things up. Meanwhile, I have Opera running too (on my secondary monitor) so I can see at once if some email comes in.

So if instead of Opera it was another program for mail, this didn't make a difference? (while it's not integrated in Vivaldi)

I would not want them to be on a server where I cannot access them if my Internet connection is down, etc.

Which is an argument against web mail, but not against dedicated email clients, no matter of which make...

[netwolf]

Slightly off topic, but what's your problem with IMAP?

The secret service part is a joke I guess (nobody seriously believes a SS can't access server-side POP3 traces or MITM the mail fetch), and you can very easily keep a local copy of your mails with IMAP too if you want to.

A few years ago I switched all my account to IMAP and now have them perfectly accessible and synced(!) on all my devices. Nevertheless my Thunderbird is configured to keep local copies of all mails, so even offline I have perfect access to them.

WRT internal/external tool: IMHO only an integrated solution makes sense, as integration is the most important advantage over the dozens of very good email tools available, which are years of development and experience ahead.
THE advantage (at least for me) of M2 is/was that mail (and feeds) is just another tab, not a separate standalone application outside the browser.

[Pesala]

@morg42 said in Open letter to Jon concerning M3:

Exactly the kind of argument I'd been waiting for...

You are looking for arguments, contrary to your alleged acceptance that people have different workflows.

This thread is about the built-in email client, but you don't want it. That is fine by me, but I find that it being built-in improves my workflow as my screenshot shows.

IMAP would be fine if I can store local copies of my email, and then delete it from the server.

[Codehunter]

@Morg42 As a (commercial) developer you always move between the technical ideal, usability and what is economically feasible. You use as much code as possible over and over again. For object-oriented programming with inheritance and code morphing, for procedural programming with libraries and frameworks.

In this respect, it is wrong to believe that two separate applications would be safer than one monolithic application. The opposite is often the case. Because developers have to maintain and keep two different code bases synchronous, errors can creep in. How often has it been the case with Firefox, Samba, all sorts of projects that a bug was fixed in one branch, but then forgot to include the bugfix in the other branches.

Also, the renderer is not made any smaller by configuring it differently in the mail program. In the case of Vivaldi, it is and will very probably remain chromium. Either way, you will need to have Javascript enabled, because the mailer's program interface itself already needs Javascript. That was IMHO at Opera M2, too. So your "security concept" wouldn't work. The better solution is to close known security holes. If you only have to do it once, the better.

Of course you can say that I simply don't use HTML mails. M3 will undoubtedly have such a switch again. However, a mail client that does not have the ability to send HTML mails by default will not succeed in the market.

In practice, what you imagine would probably be built in such a way that you develop the same program twice and then deactivate the browser part in one case and the mail part in the other (e. g. as it was done with Opera Mail, which is still an Opera 12.15 (I think) but without browser function. However, I doubt whether this is an efficient working method for the developers.

---

Als (kommerzieller) Entwickler bewegst du dich immer zwischen dem technischen Ideal, der Usability und dem was ökonomisch machbar ist. Du verwendest so viel Code wie möglich immer wieder. Bei der objektorientierten Programmierung mit Vererbung und Codemorphing, bei prozeduraler Programmierung mit Bibliotheken und Frameworks.

Insofern ist es genau verkehrt zu glauben, dass zwei getrennte Anwendungen sicherer wären als eine monolithische Anwendung. Das Gegenteil ist oftmals der Fall. Weil man als Entwickler zwei verschiedene Codebasen pflegen und synchron halten muss, können sich Fehler einschleichen. Wie oft war es denn schon so, bei Firefox, bei Samba, bei allen erdenklichen Projekten, dass ein Bug in einem Branch gefixt, aber dann vergessen wurde, den Bugfix in die anderen Branches zu übernehmen.

Auch wird der Renderer nicht dadurch kleiner, dass du ihn im Mailprogramm anders konfigurierst. Im Fall von Vivaldi ist und bleibt es sehr wahrscheinlich Chromium. So oder so wirst du Javascript aktiviert haben müssen, weil die Programmoberfläche des Mailers selbst schon Javascript braucht. Das war IMHO bei Opera M2 auch schon so. Dein "Sicherheitskonzept" würde also nicht funktionieren. Die bessere Lösung ist es, bekannte Sicherheitslücken zu schließen. Wenn man das nur einmal tun muss, umso besser.

Klar kannst du sagen, ich benutze ganz einfach keine HTML-Mails. M3 wird mit Sicherheit auch wieder einen solchen Schalter besitzen. Doch ein Mailclient der von Haus aus die Fähigkeit zu HTML-Mails nicht besitzt, wird sich am Markt nicht durchsetzen.

Das was du dir vorstellst würde in der Praxis wahrscheinlich so gebaut, dass man zwei Mal das selbe Programm entwickelt und dann wahlweise im einen den Browserteil und im anderen den Mailteil deaktiviert (so wie es zB bei Opera Mail gemacht wurde, was ja auch nach wie vor ein Opera 12.15 (glaube ich) ist, nur eben ohne Browserfunktion. Ob das aber eine effiziente Arbeitsweise für die Entwickler ist, bezweifle ich.

[Codehunter]

@pesala Thanks for the screenshot. You can't see too much in the thumbnail but the layout looks very familiar.

--

Danke für den Screenshot. Man kann im Thumbnail zwar nicht allzu viel erkennen aber das Layout wirkt sehr vertraut.

[Morg42]

@pesala said in Open letter to Jon concerning M3:

You are looking for arguments, contrary to your alleged acceptance that people have different workflows.

Of course I'm looking for arguments. Only those will be able to make me rethink my positions. "Just because" has never been a strong incentive for me to question my own arguments.

And I don't say your point is invalid. It just might not be valid enough for me. If your workflow and your tools suit you, that's great.

This thread is about the built-in email client, but you don't want it. That is fine by me, but I find that it being built-in improves my workflow as my screenshot shows.

Which is your core argument - I can accept that (though I won't adopt it).

IMAP would be fine if I can store local copies of my email, and then delete it from the server.

I'm not far enough into IMAP to know if that's possible - AFAIK IMAP is just about the opposite, keeping all mails on the server. While you can surely keep an offline storage synced, I couldn't say if it allows mails to be deleted only on the remote system. I think POP3 might stay your way to go, especially as you seem to have it set up just right for you

[Codehunter]

@morg42 said in Open letter to Jon concerning M3:

I'm not far enough into IMAP to know if that's possible - AFAIK IMAP is just about the opposite, keeping all mails on the server. While you can surely keep an offline storage synced, I couldn't say if it allows mails to be deleted only on the remote system. I think POP3 might stay your way to go, especially as you seem to have it set up just right for you

I totally agree with you on that point! IMAP is not really a real transmission protocol but rather a control interface for a (cloud) mail service. Cloud is simply a modern term for everything that is provided on external servers by external service providers. IMAP actually represents the cloud very well, even though the term cloud did not exist before IMAP was invented.

Thus IMAP is actually in a fundamental conflict with what we long-serving M2 users want: A high-performance database engine that can search for keywords in hundreds of thousands of mails at lightning speed. IMAP cannot do this at all on the server side, because IMHO supports a full text search in the IMAP protocol. However, it is only offered by a few mail providers, especially not in freemails. And even if it is available, the search performance varies greatly and also depends on the performance or latency of the Internet connection.

In my opinion, full text search as we know it from M2 can only be done with a local database engine. Therefore all mails from the IMAP server would have to be mirrored locally. This may seem trivial at first glance, as long as you only dock a local mailer to an IMAP account. But as soon as there are several, which is actually one of the advantages of IMAP, the synchronization of user actions on other local mailers becomes very complicated. The developers of M3 like to correct me if I'm wrong.

---

Ja in diesem Punkt gebe ich dir vollkommen recht! IMAP ist eigentlich gar kein richtiges Übertragungsprotokoll sondern mehr eine Steuerungsschnittstelle für einen (Cloud-) Maildienst. Cloud ist ja einfach ein moderner Begriff für alles was auf externen Servern durch externe Dienstleister bereitgestellt wird. IMAP repräsentiert die Cloud eigentlich sehr gut, auch wenn es den Begriff Cloud noch gar nicht gab als IMAP erfunden wurde.

Damit steht IMAP eigentlich in einem fundamentalen Konflikt zu dem, was wir altgediente M2-Anwender uns wünschen: Eine hoch performante Datenbankengine, die in Hunderttausenden Mails blitzschnell nach Stichworten suchen kann. Das kann IMAP serverseitig gar nicht leisten, weil IMHO das IMAP-Protokoll eine Volltextsuche zwar vorsieht. Jedoch wird die nur von wenigen Mailprovidern angeboten, besonders nicht in Freemailern. Und selbst wenn sie vorhanden ist, variiert die Suchperformance stark und hängt auch noch von der Leistungsfähigkeit bzw. Latenz der Internetverbindung ab.

Volltextsuche wie wir sie von M2 her kennen, kann man meiner Meinung nach nur mit einer lokalen Datenbankengine realisieren. Deshalb müssten alle Mails vom IMAP-Server lokal gespiegelt werden. Das mag auf den ersten Blick trivial erscheinen, solange man nur einen lokalen Mailer an einem IMAP-Account andockt. Sobald da aber mehrere dran hängen, was eigentlich einer der Vorteile von IMAP ist, wird die Synchronisierung von Nutzeraktionen auf anderen lokalen Mailern sehr sehr kompliziert. Die Entwickler von M3 mögen mich korrigieren wenn ich mich irre.

[becm]

An IMAP client can mirror all mail data locally for offline access. So it can fully replace the non-strange operation mode (keep mails on server) of POP3.

Additionally, M2 kept a local search index even for mails not mirrored on the client.
This had the advantage of effectively managing large mailboxes with relatively small locally required storage space.

[becm]

Concerning privacy implications on keeping mails on a server:

There are (at least) 18 (interior) secret services in Germany alone.
And your provider will not really delete them, just not show them to you anymore.
Oh, the provider of the sender will of course keep a copy (or two).

So I would assume there are somewhere between 10 and 1000 persistent copies of every mail ever sent. The only result of "mark as deleted" is the loss of a backup location the end user had access to.

[Morg42]

@becm the "p" in mail stands for privacy

For privacy, you don't need to think about mail if you don't completely encrypt mails in your client (and SSL or TLS don't count).
Still, all header data is plainly there for anyone interested to see. Much like postcards, just less secure and less private...