[Top] [All Lists]

Eight-Bit Line-Oriented Binary Encoding in SMTP

2010-01-03 22:04:38

Hi all,

It seems to me that we have enough implementations out there now demonstrating:
(A) Eight-bit (8bit) transfer encoding support, as used by 8BITMIME
(B) Eight-bit cleanliness in today's SMTP environment.

There are implementations out there (Exim, several Windows servers, Qmail, 
Courier, XMail) that do "Eight-bit vain", which is a new name I just made up 
which means that they assume the whole world besides themselves will be happy 
to deposit eight-bit data, with no special checking or support on that data, 
but rely on senders never to send it as a means of being fully compliant to 

It will have been discussed before now, but it's quite apparent that we want 
the ability to send binary data that isn't line-oriented using as simple sudden 
implementation change as possible.  That means we need to decouple the 
transport from the encoding, or declare that a server can accept eight bit data 
using the DATA command.  If this means that somebody comes along with a new 
MIME CTE, then so be it, but the two need not be specified together.  In fact, 
the SMTP extension can come first to allow servers to get on with the business 
of spewing eight-bit data now, including 8bit, without worrying about 
conversion or other requirements specified by 8BITMIME and, in particular, with 
no compulsive behaviour changes other than ensuring that they are not about to 
push eight-bit data down the throat of someone who isn't clearly able to 
receive it, which as I've said is how current implementations are treating 

I looked at yEnc (; without the silly headers and trailers, the 
encoding fits RFC 5321 linear limits and RFC 2045 character restriction 
requirements as used by 8bit.  It would then be a small matter (yeah, right!) 
to declare a new CTE and, as and when appropriate, gradually begin using this 
new "8BITCLEAN" extension to use the newer, more efficient encoding, and thus 
save us all from the continued nonsense that is allowing 33% over for quotas on 
advertised maximum attachment sizes, file sending services, added disk and 
network, etc, etc, etc.

I suppose it would be ever-so-slightly more innocuous if I suggested that 
8BITCLEAN be not unlike 8BITMIME, to provide the conversion requirements.  It 
requires a new CTE though, so this seems like a silly inhibition, but it could 
add the gatewaying advantage.  It's not something I'd like to depend on, but 
there is the important problem of how new CTEs will take if we don't protect 
centuries-old software.  So, I'd love your input on that too, even though as an 
SMTP server code implementer my guess is that people would have chosen CHUNKING 
if it fit that need before now, and they didn't.  My point here is that for a 
lot of implementations, this new extension is nothing - just add an extension 
parameter in the MAIL command in the client if there's a new CTE or for audit 
purposes, and an extension keyword to EHLO responses in servers to inform 
clients they can get away with murder if they so choose.

And then there's always the possibility, of course, that I'm dreaming again 
and/or something important is missing.


<Prev in Thread] Current Thread [Next in Thread>