ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] quoted-unprintable ?

2021-03-22 09:07:28
Over on another list we have been musing about CHUNKING and BINARYMIME.

CHUNKING is easy to implement (I added it to my MTA in about an hour) but 
BINARYMIME
is extremely painful on systems where the native line ending is not \r\n 
because you
have to parse MIME bodies to figure out when to change line endings and when 
not to.

The advantage of BINARYMIME over base64 is that base64 is 33% bigger since it 
encodes
six bits per octet rather than 8.  It occurs to me that since everone these 
days
supports 8BITMIME, one could invent a quoted-unprintable encoding that 
encodes only
the characters that are special, CR LF NUL.  (To play it safe I'd also encode 
0xff).
This gets you about a 2% size increase and stays compatible with 8BITMIME.

It's actually kind of tricky if you want to avoid pathological cases. Combining
the encoding with compression is the simplest way to avoid that, since it's
unlikely in the extreme that the compression scheme will spit out a high
percentage of any specific character.

This seems totally obvious.  Has anyone proposed it before?

At least five times that I know of. Probably a bunch more than I don't. One
scheme that's actually used on the News side of thing is yEnc:

  http://www.yenc.org/

I wrote a draft at one point for one that combined the encoding part of yEnc
with deflate:

  https://tools.ietf.org/html/draft-freed-mime-newenc-00

It never went anywhere.

I realize that there is a severe chicken and egg problem here since you 
wouldn't use it
unless you knew your recipient could handle it.  I suppose one could add an 
EHLO keyword,
but MTAs don't downgrade on the fly any more, particularly since that means 
they would have
to redo DKIM and ARC signatures.

First, there are still MTAs that downgrade, just not for 8bitMIME. It's pretty
much a requirement if you're going to try and deploy smtputf8. However, as long
as the downgrade simply ignores encodings it doesn't recognize, it shouldn't
be a problem.

Second, an EHLO keyword isn't useful, since what matters is that the
*recipient*'s ability to decode. And antivirus scanners, which won't like not
being able to see into all the parts of a message.

And this is pretty much why none of these schemes ever went anywhere.

Anyway, I would be fine with reviving the draft if people either have a way 
around
the chicken and egg problem, or think it can be ignored.

PS: I also realize that the sensible way to send a message with a giant 
attachment is
to put the attachment on a web server and use message/external-body, but that 
doesn't seem
all that well supported, either.

Antivirus scanners don't like message/external-body either, because the body can
be changed after scanning. The few that support it do things like replace the
URL with one that redirects through a server that either does the scan every
time the object is fetched or has a checksum to make sure the object hasn't
changed. But all of this is pretty high overhead, and for reasons I don't fully
understand doesn't work all that well in practice.

                                Ned

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