Re: Negotiated noncompliance

[Keith Moore <[e-mail]>]

> In reverse order, I believe we are at or near consensus on Chris'
> wording, taking into account John's and Philip's changes.  Do others
> disagree?

The more I think about it, the less comfortable I am with the idea that 
a noncompliant SMTP "negotiates a nonstandard protocol".  There is a
significant difference between a bug and a protocol negotiation.
Protocol negotiations are explicit things; the meaning of a negotiation
and the means for negotiating the feature are (hopefully well-) defined 
in advance.  In the case of an implementation bug, the meaning of the
bug is not well-defined, and the other implementation (the one that
detects the bug) is guessing at what is meant.  This is inherently risky,
and while it may be operationally necessary in some cases, calling this 
a protocol negotiation makes it seem far safer and more legitimate than
it deserves. 

Arguably the standard already defines appropriate behavior of the server 
in the presence of a client that sends noncompliant commands; several error 
codes are defined for the very purpose of rejecting commands that exhibit 
such bugs.  Appropriate behavior of a client in the presence of a buggy 
server is less clear, and perhaps we should remedy that.

so here's another attempt at concrete wording



6.4 Interoperability with Noncompliant Implementations

This standard takes a stricter tone than its predecessor in order to 
discourage deployment of non-complaint software and to prevent harm
caused by poorly designed attempts to interoperate with deployed 
non-compliant software.  It does so with the experience of nearly 
twenty years of odd interoperability failures, and with the realization 
that whereas thousands of people used SMTP at the time of RFC 821, 
now millions of people rely on the standard.  Non-conformance, 
therefore, can be far more costly.

An implementation which receives protocol which is not permitted
by the specification SHOULD (if it is a client) abort the attempt
to send the message and (if it is a server) reject the command
with an appropriate status code (rather than assume that the
non-complaint server will deliver the message).  However, it is 
recognized that non-complaint implementations are sometimes 
widely deployed, and that there is occasionally a compelling 
operational need for a client or a server to cope with 
non-complaint peers until such time as the peers can be fixed.  

An SMTP implementation MAY be configurable to deviate from the 
standard in order to meet operational requirements to cope with
specific non-compliant behavior that is believed to be 
well-understood, subject to the following constraints:

- The SMTP MUST continue to behave according to the standard when
communicating with peers that also appear to behave according to 
the standard, unless it has specific knowledge that the peer is
non-complaint,

- To the extent that an SMTP client or server is purposely ignoring
a protocol error or making assumptions about the nature of the bug 
which causes a protocol error, it SHOULD be possible to configure
the SMTP to reject that command (if it is a server) or abort sending
the message (if it is a client) in the presence of such errors.  Note 
this does not require an SMTP to check for every possible protocol 
error, it merely requires that workarounds for such bugs be optional 
for the operator.

- Options which enable bug workarounds SHOULD be disabled by default.
 
- Implementations which choose to do this SHOULD narrowly tailor 
the workaround to what is strictly necessary to interoperate with 
known deployed non-compliant software.