ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Draft for compressing SMTP streams

2016-08-16 17:38:26
I see that the draft has recently expired.  Are there any news about it?

No.  If there are people who would actually implement it, it's easy
enough to send in a new rev.

In case a -01 version is scheduled, I would like to point out a fairly 
recent updated draft regarding the COMPRESS extension for NNTP:
    https://tools.ietf.org/html/draft-murchison-nntp-compress-05

I've looked at it, being one of the 14 people in the world who still
runs a news server.  Despite the superficial syntactic similarities,
SMTP and NNTP are not all that similar.  Most notably, SMTP traffic is
very asymmetric, with only tiny amounts from server to client, and
potentially large messages from client to server.  NNTP can go either
way.

   o  Is it worth making provision for multiple compression schemes?
      After 20 years, there still isn't anything much better than
      DEFLATE and zlib.

=> COMPRESS for IMAP permits to use other compression schemes.  We also 
permit that for NNTP.  Better foresee future better algorithms from the 
start.

Does anyone actually use other compression algorithms?  Options that
nobody actually uses are about the best way to create hard to diagnose
incompatibilities.

Incidentally, are you sure a separate CDAT command is the wisest 
solution for SMTP (instead of a compression layer, like TLS)?

Yes, see previous discussion.  The compression layer requires a
three-way coroutine system which is a lot more fragile than sending
the data through already debugged TLS connection code, and this
completely avoids the CRIME issue and its relatives.

Keep in mind that one of the advantages of a compression layer is that 
you can also decide not to compress data (setting the compression level 
at 0 for commands or answers that do not need being compressed).  The 
client may know that the contents is already compressed (jpg or zip 
attachment for instance) and decide not to compress it again.

How is this different from CDAT?  The client can send anything that
DEFLATE can be persuaded to produce.  If you're using zlib, you call
deflateParams to tell it how to change its compression strategy and
keep going.

R's,
John

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp