[Top] [All Lists]

Re: [ietf-smtp] Draft for compressing SMTP streams

2016-08-23 19:34:22
On Fri, Aug 19, 2016 at 3:30 PM, John R Levine <johnl(_at_)taugh(_dot_)com> 

We wouldn't mind switching to a world of using BDAT/BINARYMIME (we support
both, but don't advertise BINARYMIME), but when coupled with DKIM, it
becomes harder, since if we switch to generating cte:binary messages and
signing them, or accepting such messages, how do we forward them to hosts
that don't handle them?

I get the impression that for most people, the 25% bloat for base64 isn't
a big enough deal to be worth a lot of effort to upgrade all the required
software to handle binary attachments.  If you really care that much, you
might as well put the attachments on a web server somewhere and use
message/external body with a pointer to where it's stored.  That's been in
the MIME standard for 20 years.

I think the Google Drive folks would be happy with that, but I'm not sure
the rest of the internet would be.

Also, there's the complication of spam/malware/virus scanning, now you rely
on the end user's computer for that instead of the service, unless the
service downloads the message/external and checks it, but that has other
problems with authorization.

Also, the actual support for message/external may be a bit lacking in most
mail clients, just a link in an html message probably works better for most


It's kind of the same problem with SMTPUTF8, of course.

Yes, although with SMTPUTF8 we made a fairly clear distinction that you're
on the bus or you're off, and an entire mail site either supports it or
not.  The experimental version had a bunch of fallback options that failed

Not having a fallback is probably the right choice, but it does make roll
out harder for any service which does forwarding/relaying.

OTOH, as we're pointing out, it's hardly the only smtp extension with that

ietf-smtp mailing list