[blacklion]

What next? Replacing Sieve with something cumbersome, but JSON based?

There is no good desktop implementation of MUA with old technologies (IMAP, Sieve), will all this JMAP help?

I don't think so.

What is profit to have good server with new good (assume it is good, I'm not sure, but lets assume) protocols without good client?

IMAP4 is underused by modern clients: it allows to effectively store client configuration on server, nobody implements it on client side. It allows to configure per-folder Sieve scripts, nobody implements it on client side. Nobody implements good Sieve client (with folder name autocomplition and such) even for global script, not to mention per-folder ones. Heck, there is no good Sieve editor! (I know about Sieve client built on Electron, it is not good, it is incomplete and buggy).

Servers are solved problem (sendmail, exim, postfix, dovecot, cyrus). Clients are not, they stagnated at the moment GMail was announced.

[Avamander]

Solved problem? Dovecot can't handle UTF-8 to this day. Things like Stalwart do try and change that and actually support non-legacy features. (Though I think Stalwart doesn't do IMAP NOTIFY either.)

Clients on the other hand have actually kinda moved forward, Apple Mail works with IMAP servers and offers features that people only got with Gmail before. But there are many other examples as well.

[blacklion]

What do you mean, dovecot can't handle UTF-8? It works with any properly MIME-encoded message on one hand and allows (even requires) proper UTF-8 for folder and namespace names on the other hand.

I don't have any problems to use UTF-8 in my messages received via dovecot and I have some folders with national characters on my account, and it works both with IMAP and Sieve.

[Avamander]

No proper SMTPUTF8 support for starters.

[blacklion]

dovecot is not SMTP server. And there is standard way to encode any charset in (almost any) message header for ages. We never will create e-mail messages with headers by hand in telnet session anymore, anyway.

[Avamander]

> dovecot is not SMTP server.

Don't get confused by the name of the extension that it's somehow SMTP-only.

> And there is standard way to encode any charset in (almost any) message header for ages.

Actually, no. For example there is no allowed/standardised way to encode a MIME From address that uses UTF-8. It is only permitted to encode the non-structured part of a header such as the comment or phrase, but not the structured part (the address itself). It is also explicitly forbidden to encode anything in the Received header field.

[blacklion]

My bad, I've dug dipper into the problem now and now see, that this is really a problem.

You are right.

But, again, what is simpler: add feature to existing OSS project or write all new protocols?

Second is more fun, for sure, I can understand that as programmer myself.

[mmooss]

> What is profit to have good server with new good (assume it is good, I'm not sure, but lets assume) protocols without good client?

You need both. You could say, what profit is a good client without a server? By that reasoning, we never stake a step forward without a complete solution.

Now a better mail implementation is just a client away.

[blacklion]

Problem with clients not protocols but UI&UX. New protocols can change nothing in this area.

Maybe, Apple Mail is good, again, I don't know as I'm not using Apple, but I don't know any client for Windows and/or OSS with Windows support which has as basic features as support of per-folder settings (identity, sorting mode, etc.) stored on server or proper support for Sieve. In my eyes it is basic features.

And don't let me start to rant about message editor itself, especially in text-only (as opposite to HTML) mode with proper quoting & such.

[mmooss]

On a tangent: For do you use format-flowed in text-only that you send? I'm never quite sure if it's universally and effectively supported enough to implement for less-technical users, or better to just define the EOL (and lose dynamic adjustment to viewer width).

[blacklion]

I had complains about "too long lines" in my e-mails many times and now try to use EOLs, unfortunately.

It is exactly what I said: all modern, GUI e-mail clients suck at basic functions, like displaying simple message with several layers of quotations and long lines, they cannot wrap lines with visually duplicating quotations properly, often they could not wrap even "new" (unquoted) lines at all and show horizontal scrollers. JMAP is no help here.

It was solved problem in age of terminal clients, heck, GoldEd for FIDOnet was able to do this in 1990s.

Instead of new protocols it was better to standardize MarkDown (+extension for nested quoting) in e-mails, but this train is long gone, I'm afraid.