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.
Yes, order must be STARTTLS, then AUTH, then COMPRESS.
We assume that binary MIME (ala RFC 3030) is dead.
Alternative: Is there any benefit to compressing the envelope? With
pipelining, probably; otherwise no. If we don't compress the envelope,
then we could make compression an option on the DATA command. Now we
have something that starts to look like RFC 3030, but without the
assumption that the sender should not use Base64 (with its attendant and
DKIM-breaking content transfer encoding conversion at each hop).
<csg>
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp