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