Dan Kohn wrote:
Or, more specifically, Ned and I are now thinking of escaping the octets
NUL, CR, LF, TAB, SP, and "=" (the SP and TAB prevent potential
corruption on some buggy MTAs, and the "=" is used as the escaping
character).
I'd be tempted to add '@' as some buggy UAs tend to grope, agonizingly
slowly, and hogging CPU resources, through binary content in the vain
hope of finding an email address. But it's not worth encumbering a
transfer encoding with that; let user pressure for the bugware
suppliers to squash the bugs.
The other alternative is to expect encoders to be a little smarter to
always have a 998 line count rather than having it be probabilistic.
The encoder could process each octet one at a time, escape the six that
need to be, output the result while incrementing a counter by the number
of octets outputted (either 1 or 2), add a CRLF when the counter reaches
997, and then reset the counter.
I noticed that in Ned's draft, and I like it.
BTW, does anyone know of NNTP or 8BitMIME ESMTP transport
implementations that do not support 998 octets per line?
Don't forget POP and IMAP!