ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Quoted-Printable-8bit

2021-03-29 18:44:22
Gene Hightower writes:

On 29/03/2021 05:07, Viktor Dukhovni wrote:

> Sorry, OOPS, I meant BINARYMIME...

BINARYMIME requires the CHUNKING extension; it doesn't work with the
DATA/dot-stuffing method of transferring a message.

Quoted-Printable-8bit & quoted-unprintable are ideas that work with the
8-bit MIME Transport extension (RFC-6152).
That is, more efficient and/or otherwise more useful ways of transport
encoding for 8-bit channels.

Interestingly, 8BITMIME is almost universally adopted. BINARYMIME not so
much.

I asked myself the same question again: what is the value-added here. 8BITMIME has clear benefits to both the sender and the recipient. The sender does not need to transcode 8bit to quoted-printable. The receiver can actually receive all PGP-signed mail. Transcoding breaks PGP signatures (I think this was a mistake – applying signatures to the wire content, the PGP signature should be calculated for the decoded content, so transcoding to a different MIME encoding won't break the signature, but that's water under the bridge).

So, what is the answer to the same question, for BINARYMIME? This is mostly conjecture, but I'd say that email implementations tend to fall into two broad categories.

The first one is where mail is stored in its original unaltered RFC 2?822 format. Access to it is exposed by POP3, IMAP, and Webmail servers that read and parse it. I see no upside to sending and receiving BINARYMIME, here. This requires more work, and more opportunities for breakage.

The second one is where mail is transformed into an internal format that's specific to the mail store. Attachments get decoded and saved. Mail access is with custom clients. I am talking about stuff like Exchange and Outlook; or going back earlier in time, Lotus Notes.

Mail is likely to be processed, from on-the-wire format. Seems to be there's less work to send and receive BINARYMIME, here.

But, again, you can't assume BINARYMIME availability and you still have to implement sending and receiving mail in RFC 2?822 format. So, given that this needs to be implemented anyway, again the question is whether it's worth the effort to support two code bases that do the same thing. I suppose that if the implementations' particulars means that doing BINARYMIME requires very little additional work, it might be worth it. But, how likely is that…

Attachment: pgpt47J_2lDFP.pgp
Description: PGP signature

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp