Re: POP3 UTF-8 support

Am 07.08.21 um 02:13 schrieb RW:
> On Thu, 5 Aug 2021 18:32:57 +0200
> Matthias Andree wrote:
>
>> Am 05.08.21 um 17:09 schrieb Charles Cazabon:
>>> Matthias Andree <[email protected]> wrote:  
>>> 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...
> Is it really that big a problem? My expectation is that most
> software would treat multipart character bytes as opaque data.
>
> I don't receive email with UTF-8 headers, but years ago I have seen
> emails with unencoded headers in ISO 8859-1 etc, and it didn't seem to
> be a problem. Email clients tend to be forgiving of RFC violations.
But if your e-mail client isn't updated for this, the server may not
hand out the e-mail...

The issue I have with this is that this approach seems quite radical for
IETF RFCs. It's really different with respect to interoperatibility, and
while I can understand "unless the client tells it's 8-bit capable,
stick to old standards", this RFC-6530ff and RFC-6855ff standard set
really creates more dead-ends for mail than I think 8BITMIME did,
especially with multi-hop transports and surrogate mails provided by
servers, and it's not as easy to re-encode this UTF8 mail as it was for
8BITMIME where re-encoding in transit was possible, but it is not
feasible for 8-bit headers because re-encoding is limited, RFC2047 isn't
permitted everywhere where the UTF8-headers would require it.