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?
It's kind of the same problem with SMTPUTF8, of course.
And that doesn't include what happens downstream with POP/IMAP clients as
well, in our testing many of them didn't handle binary attachments well
either.
Brandon
On Thu, Aug 18, 2016 at 2:09 PM, John Bucy <jbucy(_at_)google(_dot_)com> wrote:
On Thu, Aug 18, 2016 at 10:40 AM, John R Levine <johnl(_at_)taugh(_dot_)com>
wrote:
Took out smime, since this discussion has nothing to do with it.
Modern Word and Excel files are in ZIP container formats. Therefore, they
are already compressed. [Looks like Paul Smith already posted about this.]
Oh, right, forgot about that.
It's looking to me like there are two places where CDAT might be useful.
One is to squeeze base64 encoded stuff back to about its original size. The
other, since the compressor is deliberately not reset between messages, is
when you send approximately but not quite the same message to several
people in the same session, e.g., different text with the same
attachments. Imagine you're an ESP sending tarted up mail with lots of
images, and each recipient's name is spliced into the text of his message.
Agree with this. We (gmail) are still interested but it isn't our highest
priority. The draft seems straightforward, I can probably prototype it on
our smtp gateway in a few days when I can find the time.
cheers
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp