Re: Negotiated noncompliance
Keith Moore <moore@cs.utk.edu> Wed, 23 August 2000 14:11 UTC
Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12003 for <drums-archive@odin.ietf.org>; Wed, 23 Aug 2000 10:11:50 -0400 (EDT)
Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id KAA24468; Wed, 23 Aug 2000 10:11:02 -0400 (EDT)
Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 23 Aug 2000 10:11:00 -0400
Received: by cs.utk.edu (cf v2.9s-UTK) id KAA24446; Wed, 23 Aug 2000 10:10:59 -0400 (EDT)
Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id KAA24429; Wed, 23 Aug 2000 10:10:58 -0400 (EDT)
Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Wed, 23 Aug 2000 10:10:58 -0400
Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id KAA12341; Wed, 23 Aug 2000 10:09:36 -0400 (EDT)
Message-Id: <200008231409.KAA12341@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: lear@cisco.com
cc: drums@cs.utk.edu, John Gardiner Myers <jgmyers@netscape.com>
Subject: Re: Negotiated noncompliance
In-reply-to: Your message of "Wed, 23 Aug 2000 04:28:26 PDT." <39A3B55A.C59344D2@cisco.com>
X-SUBJECT-MSG-FROM: Eliot Lear <lear@cisco.com>
Date: Wed, 23 Aug 2000 10:09:36 -0400
Sender: moore@cs.utk.edu
List-Unsubscribe: <mailto:drums-request@cs.utk.edu?Subject=unsubscribe>
> 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.
- Negotiated noncompliance John Gardiner Myers
- Re: Negotiated noncompliance Dave Crocker
- Re: Negotiated noncompliance Keith Moore
- Re: Negotiated noncompliance Paul Hoffman / IMC
- Re: Negotiated noncompliance Keith Moore
- Re: Negotiated noncompliance Eliot Lear
- Re: Negotiated noncompliance Dave Crocker
- Re: Negotiated noncompliance Eliot Lear
- Re: Negotiated noncompliance Charles Lindsey
- Re: Negotiated noncompliance Keith Moore
- Re: Negotiated noncompliance Barry Leiba
- Re: Negotiated noncompliance Chris Newman
- Re: Negotiated noncompliance John Gardiner Myers
- Re: Negotiated noncompliance John Gardiner Myers
- Re: Negotiated noncompliance Charles Lindsey
- Re: Negotiated noncompliance Philip Hazel
- Re: Negotiated noncompliance DRUMS WG Chair
- Re: Negotiated noncompliance Eliot Lear
- Re: Negotiated noncompliance Keith Moore
- Re: Negotiated noncompliance Robert Elz
- Re: Negotiated noncompliance Philip Hazel
- Re: Negotiated noncompliance Robert Elz
- Re: Negotiated noncompliance Charles Lindsey
- Re: Negotiated noncompliance D. J. Bernstein
- Re: Negotiated noncompliance Russ Allbery
- Re: Negotiated noncompliance Claus Färber
- Re: Negotiated noncompliance Harald Alvestrand
- Re: Negotiated noncompliance Graham Klyne
- Re: Negotiated noncompliance Barry Finkel