Re: Negotiated noncompliance

[Philip Hazel <[e-mail]>]

On Wed, 23 Aug 2000, Robert Elz wrote:

> Almost everything in this thread has been about what can/should be
> done with clients that send LF where they should be sending CR LF.
> 
> I'd like to leave that one aside for a minute and ask whether there
> are any other areas of the protocol where "negotiated noncompliance"
> (by pseudo-negotiation, rather than anything explicit, which is
> what we're talking abut here) is considered to be likely to be useful,
> or even necessary?

Off the top of my head, some I have come across:

. Space character(s) after MAIL FROM: or RCPT TO:

. Local parts containing null components or having dots at either end.

. Multiple pairs of <>  e.g.   MAIL FROM:<<user@domain>>

> How far do we let servers go along this "I know what he was really trying
> to do, though he stuffed it" response to broken clients, before the
> server is declared broken as well?
> 
> Personally, I would prefer not at all.  Allowing this just entrenches
> broken clients, which helps no-one long term.

I entirely agree. Unfortunately, the commercial world does not, and it's 
too late to put certain genies back into their bottles. Managers don't
want to be bothered with techical details. "Our clients worked with the
old MTA - go make the new MTA work with them too." is something that has
been passed on to me more than once. (The old MTA was "forgiving", you
see.)

> On the LF issue specifically, do we have any evidence at all that any
> large number of clients are still doing this?   I know that sendmail
> used to default to send LF alone, but that was changed ages ago, anyone
> with a sendmail that old should really be persuaded to upgrade, 

So they upgrade to a new MTA, the clients that were broken now won't 
work any more, the managers start screaming at the techs who "broke" 
their email world... A lot of people run a lot of old software.

> it is
> for their own good, those ancient versions had bugs of other kinds...
> (and it isn't as though a fix to the CR LF problem takes more than a
> second to implement - it is in the .cf file after all - if the site can't
> upgrade for some reason).

Of course I agree with you all the way, but I fear that the Real World 
(tm) doesn't work like that. At least, that's how it has been presented 
to me (in my ivory tower :-).

> Let's speed the draft along, just leave the text unchanged - if someone
> feels that their SMTP server just has to violate the rules for some reason
> (and that is actually detected somehow) then let them explain why they have
> to be non-conformant, and let the market decide.

That will of course be what happens anyway. I agree with you about 
speeding the draft along. Let's get it standardised. THEN we can start 
discussing where to go next.

-- 
Philip Hazel            University of Cambridge Computing Service,
[e-mail]      Cambridge, England. Phone: [phone].