John Levine:
> It appears that Wietse Venema <postfix-users@postfix.org> said:
> >> BINARYMIME avoids the 33% size increase of base64. If people cared
> >> about that, since every MTA now supports 8BITMIME it would be easy
> >> to invent a quoted-unprintable content-transfer-encoding which
> >> escaped only the few characters that are special in 8BITMIME (CR
> >> LF NUL and to be on the safe side, 0xff.) That would get you about
> >> 98% of the way to binary with 2% of the work.
> >
> >This would turn binary content into a long line. That works perfectly
> >with qmail and Postfix (except that the Postfix SMTP client will
> >need a hint to avoid folding such lines at the 998 octet limit of
> >RFC 5321).
>
> My quoted-unprintable would turn NUL CR LF \ xFF into \0 \r \n \\ \x.
> The decoder ignores unescaped CR and LF. Just like with base64, insert
> an unescaped CR LF after every 998 octets to make the lines the right
> length. That still would put you within 2% of the size of pure binary.
Sorry, I cannot resist. I'm reviewing conference papers right
now, and I routinely sanity check numerical claims.
With uniform or compressed payloads, 256 bytes become 261 on average,
thus it takes 978.9 bytes on average to expand into 998. Add CR
and LF to the 998, and we have an expansion of 1000/978.9=1.022 or
just a little over 2%.
With non-uniform input, or with input from a smaller alphabet, I
expect that YMMV (the expansion can be less or more than 2%). For
example 1000 null bytes expand into 2000 (100%), and when content
requires no escaping, 998 bytes expand into 1000 (0.2%).
It could have been a good idea 25 years ago.
Wietse
