[Top] [All Lists]

Re: [ietf-smtp] Compressing SMTP data

2016-01-30 11:36:35
If we are not doing the full stream compression (which I prefer), I would 
really like a BDAT variant, it is easier to code. (Speaking from experience 
implementing both client and server side.)

Having sketched out some code, I agree.

The problem with doing full stream comprssion is that the compressor is a coroutine that sits between the application and the network. If you also are doing TLS, that's already a coroutine between the application and the network, so this is now a coroutine in front of the other coroutine. The TLS coroutine code in my MTA is a kludge, and doubling the kludge and making it work both with and without TLS would be fragile. Besides, if we only do it for the data I think we can ignore the CRIME issue.

For the DATA only part, it's easy enough to start up zlib or its equivalent and tell it to deflate or reflate blocks of data. But for my proposal where the compression stops after \r\n.\r\n it's harder to tell it to stop and then to continue processing uncompressed data after that. It'd probably work since the client will flush the output but again, it's fragile.

So the revised straw man invents a CDAT command which is like BDAT except that the data is compressed. The length is the length of the transmitted compressed data, and if your compressor produces blocks of data, it's specifically allowed to split a compressed block between two CDAT blocks. (This poses no problem to zlib.) All the other rules for BDAT apply, if the message ends in the middle of a MIME chunk or the like, the results are undefined.

For performance reasons you want the chunks to be as big as possible, but on today's computers I expect that a 10Mb compression buffer is no big deal.

John Levine, johnl(_at_)taugh(_dot_)com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

ietf-smtp mailing list