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

[Sam Varshavchik <[e-mail]>]

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…