On Fri, Aug 19, 2016 at 3:30 PM, John R Levine <johnl(_at_)taugh(_dot_)com>
wrote:
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
folks.
R's,
John
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
miserably.
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
issue.
Brandon
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp