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
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
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
John Levine, johnl(_at_)taugh(_dot_)com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.
ietf-smtp mailing list