Re: POP3 UTF-8 support

Am 05.08.21 um 17:09 schrieb Charles Cazabon:
> Matthias Andree <[email protected]> wrote:
>> Am 05.07.21 um 18:27 schrieb Charles Cazabon:
>>> If I had to guess, I would say it seems to expect the client to issue the
>>> "UTF8" command from RFC6856, which is not an accepted standard.
>>>
>>> The server is broken.  Report the problem to the postmaster of the server.  Do
>> See courier-mta.org's libs/imap from the courier-IMAP tarball:
> [...]
>>>     * Provide an substitute message to IMAP clients that did not enable
>>>     UTF-8.
> Okay, so that's confirmed - it's enforcing rfc6856 even though that's not an
> accepted standard.  I would be interested to hear if the message being
> retrieved actually has non-ASCII characters in its headers, or whether Courier
> is doing something stupid.
>
> Making such a drastic, incompatible change to 822/2822 -- allowing
> non-encoded, non-ASCII charaters in the header (as opposed to body) -- seems
> like a pretty dumb idea to me.  There is a lot of legacy software out there
> that is never going to be updated to handle that.

The thing is that systems behaving that way and offering 8-bit header
and envelopes are creating their own disconnected islands until the
entire subnet sending, transporting, receiving the e-mail is upgraded...

It's not just this RFC-6855/6856 (IMAP/POP3 UTF8), but also RFC-6530 ff
which set and details the framework for internationalized e-mail, and
there are RFCs describing downgrading from message stores (not in
transit though) and what not.

That said, and without regard to Python's mail client libraries'
features: for a mail retrieval client such as getmail, it might make
sense to hand the user a switch that, if enabled, can be used by the
client's POP3 or IMAP implementation to tell the server "hand me that
UTF-8 stuff" and let the user deal with it, rather than suffer Courier's
surrogate message.

Creating an e-mail address such as 不谢谢@example.comstill seems
ill-advised though for the next one to three decades...