"John R Levine" <johnl(_at_)taugh(_dot_)com> writes:
Here's an alternative hack that only compresses the message body. I
think it avoids the CRIME problem since it seems it'd be pretty hard to
predict where in a stream the encoded data would start. It is about as
effective as compressing the whole stream since the SMTP commands and
responses are generally very short, while making the code considerably
simpler since only the part that sends or receives the message body
needs to understand compression.
We considered this in NNTP and abandoned it because the implementation
complexity seemed a lot higher for the typical NNTP implementation. The
advantage of compressing the whole stream in a protocol that already
supports TLS and SASL is that you just stack the compression into your
transport layer, and you already have a system for dealing with that.
This requires building knowledge higher in the stack in the command
processor.
That said, NNTP and SMTP differ here in that NNTP has multiple different
commands that send or receive larger data, whereas SMTP basically has only
the one, so the issues don't apply in the same way. Also, there's the
CRIME problem -- the NNTP proposal tries to deal with the most obvious
implications by requiring AUTHINFO happen before compression is
negotiated, but there are probably other issues even after that one.
--
Russ Allbery (eagle(_at_)eyrie(_dot_)org)
<http://www.eyrie.org/~eagle/>
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp