ietf-smtp
[Top] [All Lists]

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

2016-08-17 07:55:56
Hi John,

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.

OK, I understand that COMPRESS would not be that useful for SMTP (contrary to IMAP or NNTP). Regarding implementation of COMPRESS in the NNTP world, interoperability is already proven: we have a widely used news server (INN) and a news client (flnews) that implement it. Cyrus NNTP server also added support for it. If the draft ever becomes a proposed standard, we can hope other clients and servers will adopt it. Only 13 news servers left to upgrade :)



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

Sean spoke about LZMA/LZMA2 here. That algorithm also arrived in the discussion in the news.software.nntp newsgroup. Though still not supported, it could in the future (or any other algorithm).

Supporting from the start a syntax permitting to use other algorithms than DEFLATE is easy to do. I do not see why supporting that would create incompatibilities.

If the client asks for an unknown algorithm, the server will just decline it:

      [C] COMPRESS X-SHRINK
      [S] 503 Compression algorithm not supported

Besides, the server advertises the algorithms it knows:

      [C] CAPABILITIES
      [S] 101 Capability list:
      [S] VERSION 2
      [S] READER
      [S] AUTHINFO USER
      [S] COMPRESS DEFLATE
      [S] LIST ACTIVE NEWSGROUPS
      [S] .

Let's activate a compression layer using DEFLATE:

      [C] COMPRESS DEFLATE
      [S] 206 Compression active
      [Henceforth, all traffic is compressed]



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.

A separate command will be "easy" to implement in case SMTP software cope well with null bytes, as Russ hinted at in the discussion. Otherwise, a compression layer is easier to add (the same way a TLS layer or an SASL layer are).

--
Julien ÉLIE

« Il ne faut jamais pleurer d'avoir perdu la lune car les larmes
  empêchent de voir les étoiles. »

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