Responsive vendors and their implications (was de-facto 8 bit smtp)

[John C Klensin <KLENSIN@xxxxxxxxxxxxxxx>]

Robert Ullman writes...
>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
>...
>a version upgrade can be done overnight, and is sometimes done in
>minutes. (in general, the faster it is done, the happier the customer)
>...
>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.

This is, of course, correct, at least for the class of environments 
Robert is discussing.  Of course, there are, in addition to local hacks
and volunteer maintenance, a number of vendors who are, shall we say, a 
little slow about the types of issues Robert raises.  There are at least 
a few out there who often take months to document a problem sufficiently 
that they can make a corporate statement about what, if anything, then 
intend to do about it.  A few of these are rather small companies whose 
technical staffs have gotten stretched too thin.  One or two are *lots* 
larger than Prime.
  Based on his experience and perspective, Robert is an optimist about 
these things.  Possibly based on ours (which includes having significant 
machines abandoned by vendors while the machines were in their prime), 
Mark and I are pessimists.  I can't speak for Mark, but I love being 
wrong when I predict doom.  It doesn't happen nearly often enough.

  But this aside, it seems to me that Robert's argument contains the 
seeds of its own destruction.  Let's assume that the world is populated 
by responsive vendors with good software update and distribution 
mechanisms who can get an update out in a few days if they feel like it. 
Robert says...
>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. 
  Yep.  But then, by his own argument, the users would call the vendor, 
en mass, and say "hey, your mailer is out of spec, it is rejecting mail 
that it ought to know how to handle".  And the responsive vendor, in a 
matter of days (if not hours) would prepare and ship an update that 
would provide a "2xx OK" in response to these eight-bit indicating 
verbs.

There is another point here, which has been said in other contexts, and 
I think bears repeating.  There are a lot fewer SMTP MTAs out there than 
there are UAs that handle RFC822.  The MTAs tend to be part of TCP/IP 
packages, supported by a relatively small number of vendors, and, at 
maximum, there will be one running per host.  The UAs, by contrast, tend 
to be more subject to user whim: it is not unusual to have more than one 
MUA on a given host, providing different interfaces or whatever and I 
suspect there are more homegrown ones.  So, from a speed of deployment 
standpoint, almost anything that is changed in the SMTP/MTA 
specification is going to be out there as rapidly or more rapidly than 
things that require that most of the UAs in the world be changed.

>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. :-)
  I don't know that this is necessary or desirable, especially since I 
think that Robert has just argued that he can quickly adapt to whatever 
is decided and that his customers will make him do that :-), but I must 
say it is a fascinating approach.
   Certainly a string to keep in mind if anyone starts working on 
conformance tests :-)
    --john
-------