Re: [Shutup] [ietf-smtp] Compressing SMTP streams

["Carl S. Gutekunst" <[e-mail]>]

> 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>