Re: [ietf-smtp] quoted-unprintable ?

[Ned Freed <[e-mail]>]

> 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