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 8BITMIME. 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 8BITMIME. I looked at yEnc (www.yenc.org); 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. Cheers, Sabahattin
