[Top] [All Lists]

Re: [ietf-smtp] Compressing SMTP streams

2016-02-01 11:03:38

On Feb 1, 2016, at 2:53 AM, Paul Smith <paul(_at_)pscs(_dot_)co(_dot_)uk> 

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/ 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 know. 

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).

Or silently discard it, which was my experience with Exchange forwarding 8 bit 
messages to a server which while it was 8 bit clean didn’t advertise the fact a 
few years ago.

There are a lot of CRM systems behind firewalls in a lot of companies that have 
Exchange as a primary MX, and some of those accept inbound tickets over SMTP.

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.

Very nasty. And it can easily last (checks RFC 1869) 20 years or more.

A compression scheme shouldn't have the same problem.

Yes. I’m not a terribly relevant ESMTP implementor, and I’m likely to implement 
whatever a customer wants me to implement rather than anything driven by 
protocol elegance … but stream level compression or a counted-byte BDAT + 
compression both seem like something I’d be comfortable adding to the state 

ietf-smtp mailing list