Compression has been removed completely from TLS v1.3, the outcome of
the room consensus at IETF-89.
Bummer.
Well, in that case, here's a straw man proposal.
The extension name is COMPRESS, the EHLO keyword is COMPRESS and is
followed by a space-separated list of compression schemes, currently
consisting only of DEFLATE (RFC 1951.)
There's one new command, COMPRESS which takes as an argument the type
of compression to be used. If you want to do both STARTTLS and
COMPRESS, the results of doing COMPRESS before STARTTLS are
aggessively undefined.
The responses to COMPRESS are:
500 compress not supported
501 compression scheme unknown
220 go ahead
After a 220 response, subsequent traffic is compressed. It's up to
each end to ensure that there's a compression block boundary every
time the transmission direction changes, i.e., after each command or
response, or if pipelining after each pipelined group. If the
compress command fails, the client can at its option continue an
uncompressed session or give up.
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: COMPRESS DEFLATE
S: 220 go ahead
<subsequent traffic is compressed>
... blah blah ...
C: QUIT
S: 221 sayonara
R's,
John
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp