de-facto 8 bit SMTP

[Robert Ullmann <Ariel@xxxxxxxxxxxxxxx>]

Hi,

Several people (most notably MRC :-) keep saying it will take a long
time to get implementations to pass 8 bits when relaying SMTP mail.
I'm not disagreeing; it will take several years.

What they are overlooking is that it isn't the _next_ several years.
The process has already started. Prime (as I said before), has been
shipping 8 bit MTAs for several years; Sun (at current release, 4.1)
passes 8 bit; DEC does, at least outside the U.S.

This has been happening because a vendor of any size must sell to SE
Asia and to Europe; both markets demand 8-bit, and the Internet RFC
that (supposedly) prohibits it carries no formal weight.

At least one implementation doesn't do 8-bit _only_ because of the
"prohibition"; if it was lifted, to at least "permit" 8 bit, whether
or not it is required, 8-bit support would appear immediately. I
suspect there are others as well, waiting only for the RFC to be
updated.

----
I also want to mention that I have a different viewpoint on how long
it takes to get s/w upgraded. Several people here lament that it
takes forever, or is essentially impossible, to get some offending
system fixed.

I work with commercial customers, in the Real World (TM) (:-), where
a version upgrade can be done overnight, and is sometimes done in
minutes. (in general, the faster it is done, the happier the customer)

I understand that if the system is in another university department,
run part time by some grad student, and the MTA is a hack-from-someplace,
it can be a real problem.

But when the system is properly administered, and the user complains
that it is out-of-spec, _and_ the vendor says, "Yes, that is a bug,
it doesn't do the (new) standard. You need (e.g.) rev 2.1.0 of
PDNmail; here it is ..." things happen just a bit faster.

----
There is _already_ an installed base of mailers that will do 8-bit.
It would be a real shame if a mailer called up one of them, said
ISOC, (or D8TA, or whatever), got the 500 ... reply, and crunched the
message. After all, if it just ignored the "problem", it would work
fine. (_In_this_case_)

IMHO, an 8 bit mailer should just assume the other is 8-bit, and my
software does that. But I recognize that others want their mailers to
be more helpful. (In spite of the fact that there is no thing
conceivably worse than a "helpful" mailer :-) [sorry, this is getting
longer than I intended :-]

----
So how do they (assuming the standard is now 8) detect an "old" 7-bit
implementation?

ISOC (or whatever) is no good; it will see all the existing 8-bit
implementations as 7-bit (except for the one that uses ISOC already,
of course).

Possible answer: send the command  n o o <eth> <nbsp> p <cr> <lf>
(Hex: 6E 6F 6F F0 A0 70 0D 0A)

An 8-bit mailer will reply 500 No Such Command. ("Nooeth p"? Nil. :-)

A 7 bit mailer that strips 8th bits will "see" noop <sp> p <cr> <lf>
and reply 250 OK. A 7 bit mailer that elides octets with the 8th bit
set (MMDF) will see noop <cr> <lf> and also reply 250 OK.

This even works if the server-SMTP thinks it is 8 bit, but the
channel is in fact 7.

----
I don't care how such a client-SMTP "converts" 8->7; as I said, my
software won't be doing it.

IMNSHO: In two years, the idea that SMTP was ever restricted to 7
bits it going to look silly. Whether the RFC is updated or not.
<grin>

Best Regards,
Robert Ullmann
+1 508 620 2800