[Top] [All Lists]

Re: [ietf-smtp] Compressing SMTP streams

2016-01-29 15:14:15
On Fri, Jan 29, 2016 at 1:04 PM, Carl S. Gutekunst <csg(_at_)alameth(_dot_)org> 

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

1000 recipients at ~30 bytes each with each domain likely the same... maybe

If you're only compressing the data, what's the interaction with RFC 1870?
Do you use the compressed size or the original, and if you use the
compressed size, does that mean the server will accept larger uncompressed

And I'd think it's an alternative to BDAT, same thing, but compressed?
Unless we extend the BDAT syntax for compression...

ietf-smtp mailing list