Re: [Emailcore] SMTP-TCP is de facto 8bit (suggested clarity in 5321bis)

Viktor Dukhovni <[email protected]> Mon, 1 Nov 2021 14:54:21 -0400
Newsgroups gmane.ietf.smtp
Message-ID <[email protected]>
> On 26 Oct 2021, at 12:46 pm, Sabahattin Gucukoglu <[email protected]> wrote:
> 
> I don't intend to die on a hill on this issue. If the consensus is that 8BITMIME should be mandatory but that the obligation to send MIME content that is declared as such remains with the originator of the message, and that any intermediate relays must enforce by rejection or conversion the 8BITMIME requirement not to forward onward, it is still preferable to the status quo. At the very least it would strengthen the case for proper 8BITMIME enforcement , however weakly, to have mandatory 8BITMIME support which senders can rely on in the general case.

FWIW, neither mandating nor not mandating 8BITMIME will make any difference
to Postfix.  In its default configuration, Postfix will continue to downgrade
MIME bodies to 7bit (encode to quoted-printable) when passing 8bit content to
non-8BITMIME systems.  The receive path is 8bit clean, so if some Postfix admin
turns off advertising 8BITMIME and some sender fails to apply 7bit conversion,
that'll also work.

What's more fragile is sending overly long lines in a multi-byte character
encoding.  When forwarding SMTP messages we fold lines longer than 998+CRLF
*octets* by inserting <CRLF><SPACE>, at some octet boundary that may well
corrupt multibyte UTF-8 or other encodings.

So I think the line length limits are far important in practice than 8bit vs.
7bit.  If you're going to send non-Latin text, and violate the 1000 byte
limit on text+CRLF you can't expect much joy...

-- 
	Viktor.