[Top] [All Lists]

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

2016-08-16 16:24:22
Hi John,

To move the discussion along, here's a draft for the CDAT compressed
data command.

I see that the draft has recently expired.  Are there any news about it?

In case a -01 version is scheduled, I would like to point out a fairly recent updated draft regarding the COMPRESS extension for NNTP:

Section 3 about "Compression Efficiency" may be of interest, especially if you wish to add something like that in your draft. Of course Section 6 about "Security Considerations" could also be a useful source of inspiration for SMTP (notably the advice not to compress two different messages together, so as not to possibly leak information about them, as they should be considered "private"). You could say it explicitly: when you have an end-marker (LAST), the reset-marker (RESET) is mandatory. At least, if I read well the ABNF syntax.

As for your "open issues":

   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.

   o  If a server supports both COMPRESS and CHUNKING [RFC3030], can you
      mix compressed and uncompressed chunks of data?  I don't see why
      not, but ugh.

=> Whatever the final choice is (to allow or not to allow), I believe it should be explicitly mentioned in the draft.

   o  Do we need new 5xx codes for bad compressed data, or can we use
      554 for bad data and 552 for too big?

=> According to RFC 5321:
   552  Requested mail action aborted: exceeded storage allocation

   554  Transaction failed (Or, in the case of a connection-opening
      response, "No SMTP service here")

Both of these codes are valid in response to a DATA command, so I think it is OK to use them for CDAT compression errors.

Incidentally, are you sure a separate CDAT command is the wisest solution for SMTP (instead of a compression layer, like TLS)? 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.

As far as NNTP is concerned, we already had separate commands like XZVER, XZHDR or XFEATURE COMPRESS (enabling compression for a subset of subsequent NNTP commands). The problem is that they do not work for new NNTP extensions; one has to create again other separate commands dealing with compression. That's why I reckon a more global solution (like a compression layer) should really be encouraged. Or, if you really want, both CDAT and COMPRESS :)

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