3 ms·

What next? Replacing Sieve with something cumbersome, but JSON based? There is no good desktop implementation of MUA with old technologies (IMAP, Sieve), will

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.

mmooss 1y ago
> 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 1y ago
  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 1y ago
    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 1y ago
      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.
Avamander 1y ago
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 1y ago
  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 1y ago
    No proper SMTPUTF8 support for starters.
    - blacklion 1y ago
      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 1y ago
        > 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.

mmooss 1y ago

> 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 1y ago
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 1y ago
  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 1y ago
    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.

Avamander 1y ago

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 1y ago
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 1y ago
  No proper SMTPUTF8 support for starters.
  - blacklion 1y ago
    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 1y ago
      > 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.