Re: Draft for compressing SMTP streams

+1 to smime@

> On Aug 18, 2016, at 7:10 AM, John Levine <[email protected]> wrote:
> 
>> Or perhaps 
>> not want compression at all. SMTP has different problems than IMAP, 
>> which I think simple compression will not fix: Submit sees a single 
>> message per connection, plain SMTP sees mostly spam. Why implement 
>> compression, then?
> 
> I think the motivation is people sending around large documents in
> formats like Word and Excel.  Pictures and videos aren't very
> compressible, but they're base64 encoded so compressing that tends to
> get you back to the original size.  (You don't have to tell me that
> BINARYMIME and BDAT solve that particular problem better.)

Modern Word and Excel files are in ZIP container formats. Therefore, they are already compressed. [Looks like Paul Smith already posted about this.]

I would like to see implementations of SMTP compression, but more important than that is binary SMTP (aka BINARYMIME / BDAT), RFC 3030. The difficulty here in addition to general SMTP deployment issues, is that storage has to be binary-clean, which has effects on POP and IMAP. But that is an easy way to save 37%+ on bandwidth.

If the entire payload is base64-encoded and is in standard form (72 characters per line, no weird spaces, etc.), then it would be straightforward to convert the base64 part (of which only 1 exists) to binary, and then de-convert it back for storage.

Servers that support EAI have to support 8-bit clean channels, except for control characters and NULL. Therefore they can be seen as part of the same (not-small) infrastructure upgrade.

S/MIME supports compression, RFC 3274. It is not widely supported, but I know of at least one mail client that supports it. It would be good to support that as well, especially since end-to-end encrypted content will not be further compressible. OpenPGP already supports compression widely (standard algorithms: DEFLATE etc.).

Sean

> 
> Early on people from Gmail experessed interest, but I haven't heard
> from them for a while.
> 
> R's,
> John
> 
> _______________________________________________
> ietf-smtp mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ietf-smtp

_______________________________________________
ietf-smtp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-smtp