--On Tuesday, March 30, 2021 18:09 -0400 John Levine
It appears that Paul Smith <paul(_at_)pscs(_dot_)co(_dot_)uk> said:
We dont either, but RFC 6152 (written in 2011) has the text
that [if the server does not advertise 8BITMIME support]:
"then the client SMTP must not, under any circumstances,
attempt to transfer a content that contains characters
outside of the US-ASCII octet range (hex 00-7F)."
This seemed quite a strongly worded requirement, so we'd made
the decision that that requirement made it too complicated
to handle gracefully, and as it was so strongly worded, we'd
better not ignore it.
But, if people are ignoring that requirement, it's actually
interesting. Not because people aren't following the
standards, but that suggests that 8BITMIME isn't actually
that widely used...
I think you're right. If your user base speaks English, it is
not likely to be sending around a lot of text where 8BITMIME
would help, and binary data is all sent as base64 because as
we have seen, the 25% bloat hasn't been enough to invent
something like quoted-unprintable.
For really large stuff, people use Dropbox and its competitors.
I don't have a strong position on the 8BITMIME question itself,
but, as people think about changing or ignoring the requirement,
they should probably keep in mind that SMTPUTF8 (RFC 6530ff)
require 8BITMIME, i.e., advertising SMTPUTF8 without also
advertising 8BITMIME is invalid. That is, of course, consistent
with the 6152 requirement quoted above because one cannot comply
with RFC 6531 and 6432 without transmitting non-ASCII header
field material and...
ietf-smtp mailing list