On 31/01/2016 02:48, John R Levine wrote:
>> What purpose is served by using BASE64 beyond making the content able
>> to travel through a 7-bit-only hop? Since most (all?) hops are now
>> 8-bit ones, why not just send the actual 8-bit version of the data
>> instead of converting it to the 7-bit BASE64 format?
> The answer to this question is quite complex. The 8BITMIME extension
> was defined in 1994, and nearly all current MTAs can handle it. But
> all it says is that the MTA can handle 8 bit characters. It doesn't
> affect the rule that the message must consist of lines no more than
> 1000 characters long with \r\n at the end of each. As far as I can
> tell, the main effect is that people can send ISO-8859-x and UTF-8
> without encoding, which is useful but generally not a big deal.
> BINARYMIME was defined in 2000 to avoid that issue, and invents a new
> BDAT command that uses a byte count rather than escape sequence, so
> the message body can be an arbitrary sequence of octets. Gmail,
> hotmail and icloud/me.com support it, Yahoo and AOL don't, but I've
> never seen client software that would take advantage of it.
> What we've never seen is a quoted-unprintable encoding, which is like
> QP but intended for binary data. It could be like QP without soft
> line breaks and \r\n pairs are ignored. It's an obvious idea so there
> must be some reason. Dave Crocker or John Klensin or Ned Freed would
The problem with any of these is what to do if YOU accept 8 bit
characters, but you have to send the message to a mail server which
doesn't say it does. Some just pass it on and hope (which is against the
rules AFAICS - e.g. we regularly receive messages with NULL characters
in), other than that you can recode the message (which risks breaking
DKIM etc) or reject the message (which risks upsetting someone).
That's why we don't support these extensions. If every server supported
BINARYMIME it wouldn't be a problem, but the transition period is nasty.
This argument works in the case of BINARYMIME for SMTP, but fails in every
other case. There just isn't enough support for BINARYMIME in this situation
to matter, so there's no compelling reason for you to add support for it.
In the case of 8BITMIME, however, suppport for the extension is sufficiently
widespread that it's often seen on SMTP relay operations for 8bit messages,
which IME are the majority these days. So the result of your not providing the
extension is that you force other compliant agents to either transcode, reject,
or violate the standards when relaying to you, with all that implies.
In other words, you may be making your life a little (very little given how
easy it is to properly support 8bitMIME) easier, but you're making your user's
lives harder, because most of those messages would never needed to be
The case for SUBMIT isn't as compelling, but it's there: First, Since message
modification is explicitly allowed in the SUBMIT context, claiming that you
shouldn't be doing that as an excuse doesn't fly.
Second, for 8bitMIME you'll be forcing the client to encode, which given the
widespread support for 8bitMIME (3/4 of MAGY, most US ISPs, etc.) means you're
exploring the lesser used code paths in clients, which is rarely a good idea.
As for BINARYMIME, the case against that is that unless your software is binary
clean to begin with it can be a royal PITA to add support. That plus the
fact that few clients have support for it is a fairly compelling argument not
to bother, but it's not the argument you gave.
ietf-smtp mailing list