Re: Negotiated noncompliance

Chris Newman <> Thu, 17 August 2000 19:41 UTC

Received: from (CS.UTK.EDU []) by (8.9.1a/8.9.1a) with ESMTP id PAA03523 for <>; Thu, 17 Aug 2000 15:41:36 -0400 (EDT)
Received: from localhost (daemon@localhost) by with SMTP (cf v2.9s-UTK) id PAA02133; Thu, 17 Aug 2000 15:41:22 -0400 (EDT)
Received: by (bulk_mailer v1.13); Thu, 17 Aug 2000 15:41:14 -0400
Received: by (cf v2.9s-UTK) id PAA02113; Thu, 17 Aug 2000 15:41:13 -0400 (EDT)
Received: from mercury.Sun.COM (marvin@localhost) by with ESMTP (cf v2.9s-UTK) id PAA02087; Thu, 17 Aug 2000 15:41:08 -0400 (EDT)
Received: from mercury.Sun.COM ( -> mercury.Sun.COM) by (smtpshim v1.0); Thu, 17 Aug 2000 15:41:08 -0400
Received: from westmail2.West.Sun.COM ([]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA07104 for <>; Thu, 17 Aug 2000 12:41:06 -0700 (PDT)
Received: from (nifty-jr.West.Sun.COM []) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL, v1.7) with ESMTP id MAA20072 for <>; Thu, 17 Aug 2000 12:41:04 -0700 (PDT)
Date: Thu, 17 Aug 2000 12:39:44 -0700
From: Chris Newman <>
Subject: Re: Negotiated noncompliance
Message-ID: <>
In-Reply-To: <>
X-Mailer: Mulberry/2.0.3 (MacOS)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
List-Unsubscribe: <>
Content-Transfer-Encoding: 7bit

Personally, I'd like to see some text in this area.  I'm very fond of the 
precision of John's text, but agree with some of the concerns expressed 
about scope.  I like Eliot's first paragraph, but the second is far too 

Here's an attempt to take the best of both and address concerns expressed:

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 where-as 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.

If an implementation receives protocol which is not permitted by the 
specification and the specification does not mandate the response to such 
illegal protocol, the implementation can treat this as a negotiated a 
non-standard protocol.  At that point, the implementation is not 
constrained by the protocol specification in its handling of that 
particular connection.  Implmentations which choose to do this SHOULD 
narrowly tailor the accepted non-compliant protocol to that strictly 
necessary to interoperate with known deployed non-compliant software.

For example, if an SMTP server receives commands terminated by the ASCII
character "LF" but not containing the ASCII character "CR", it can decide
the SMTP client has negotiated a nonstandard variant of
the SMTP protocol wherein the <CRLF> sequence is encoded as a single
"LF" character.  The prohibition against recognizing the sequence
"<LF>.<LF>" as the end of mail data indication would then not apply to
that particular connection.

Note that this negotiation does not release the implementation from the
conformance requirements in any other protocol session, including any
session that relays mail received from a negotiated nonstandard protocol