Re: Negotiated noncompliance

Robert Elz <kre@munnari.OZ.AU> Wed, 23 August 2000 14:27 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 KAA12647 for <drums-archive@odin.ietf.org>; Wed, 23 Aug 2000 10:27:08 -0400 (EDT)
Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id KAA25985; Wed, 23 Aug 2000 10:26:50 -0400 (EDT)
Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 23 Aug 2000 10:26:49 -0400
Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id KAA25963; Wed, 23 Aug 2000 10:26:49 -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:26:49 -0400
Received: (from moore@localhost) by astro.cs.utk.edu (cf 8.9.3) id KAA12773 for dist-drums@cs.utk.edu; Wed, 23 Aug 2000 10:26:48 -0400 (EDT)
Received: from munnari.OZ.AU (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA21173; Wed, 23 Aug 2000 09:36:10 -0400 (EDT)
Received: from munnari.OZ.AU (128.250.1.21 -> munnari.OZ.AU) by cs.utk.edu (smtpshim v1.0); Wed, 23 Aug 2000 09:36:11 -0400
Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id NA19173; Wed, 23 Aug 2000 23:36:07 +1000 (from kre@munnari.OZ.AU)
From: Robert Elz <kre@munnari.OZ.AU>
To: drums@cs.utk.edu
Subject: Re: Negotiated noncompliance
In-Reply-To: <2882397.3175944200@nifty-jr.west.sun.com>
References: <2882397.3175944200@nifty-jr.west.sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 23 Aug 2000 23:36:07 +1000
Message-Id: <14586.967037767@mundamutti.cs.mu.OZ.AU>
List-Unsubscribe: <mailto:drums-request@cs.utk.edu?Subject=unsubscribe>

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?

Would it be reasonable for a server that receives a RCPT TO without
having received a MAIL FROM to simply assume that the sender meant to
send "MAIL FROM:<>" (no information has been lost) and go on and
deliver the mail anyway?

How about if the client doesn't dot stuff its input (perhaps common
if the "client" in this case is a user telnet'd to port 25). Might
the server then not un-stuff any leading '.' lines (even if they start ..)
and not treat a '.' on a line alone as the end of message unless what
follows is something that looks like an SMTP command?

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.

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, 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).

I heard rumours of some other clients that sent bare LF, though I don't
recall any of them ever being considered in any way major, or very
important - and if someone is stuck with such a mailer, they can always
just relay their mail through a non-conformant mailer which adds the
missing CRs before passing the mail to the rest of the world, so it isn't
as if anyone would be shut out of e-mail if most servers started enforcing
the CR LF rule --- and this assumes that there is anything left out there
in the world (other than perhaps an old sendmail which is trivially fixed)
which has this bug.

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.

kre