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

That's about exactly what I was thinking.

Brandon

On Fri, Jan 29, 2016 at 10:07 AM, John Levine <johnl@taugh.com> wrote:

> >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
>
> _______________________________________________
> Shutup mailing list
> Shutup@ietf.org
> https://www.ietf.org/mailman/listinfo/shutup
>