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.
The EHLO keyword is still COMPRESS followed by compression schemes,
currently DEFLATE only. Since you can't add arguments to the DATA
command, this invents a new one CDAT which takes as its argument the
compression scheme. CDAT is like DATA, except that after a 354 response,
the client sends compressed data up to and including the \r\n.\r\n at the
end of the message. The responses to CDAT are the same as to DATA and in
addition
500 compress not supported
501 compression scheme unknown
Example:
S: 220 mx.example smail2 ESMTP
C: EHLO client.example
S: 250-mx.example
S: 250-STARTTLS
S: 250-8BITMIME
S: 250 COMPRESS DEFLATE
C: STARTTLS
S: 220 go ahead
<TLS negotiation>
C: EHLO client.example
S: 250-mx.example
S: 250-8BITMIME
S: 250 COMPRESS DEFLATE
C: MAIL FROM:<alice@client.example>
S: 250 OK
C: RCPT TO:<bob@server.example>
S: 250 OK
C: CDAT DEFLATE
S: 354 send your compressed message
C: ... compressed message and \r\n.\r\n ...
S: 250 message received
C: QUIT
S: 221 sayonara
Regards,
John Levine, johnl(_at_)taugh(_dot_)com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp