Date: Sun, 17 May 1998 12:03:35 -0400 (Eastern Daylight Time)
From: John C Klensin <klensin@mci.net>
Subject: Re: State of 821bis and RSET inconsistency
In-reply-to: <19980517112444.17382.qmail@cr.yp.to>
To: "D. J. Bernstein" <djb@cr.yp.to>
Cc: drums@cs.utk.edu
Message-id: <SIMEON.9805171235.F@p6.mci.net>
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Priority: NORMAL

On Sun, 17 May 1998 11:24:44 +0000 "D. J. Bernstein" 
<djb@cr.yp.to> wrote:

> John C Klensin writes:
> > there were enough systems around that passed gratituous nonsense 
> > following DATA
> 
> Evidence, please. This is exactly the sort of information that
> implementors want to know.

Dan, I don't have my notes handy, and that was a long time ago 
as time is measured in the recent evolution of the Internet.  
One of the interesting side-effects of introducing the SMTP 
extensions mechanism was that it caused a lot of scum --in the 
form of really terrible implementations-- to be floated to the 
top of the pond and washed away.  So, even if problematic 
implementations existed then, many (or even all) of them may 
have been fixed or just fallen into disuse.

More important, the constraints on, and goals for, RFC 1869 and 
its predecessors were a little different from those associated 
with DRUMS and 821bis.  In the former case, the intent was to 
create the minimal number of stresses possible to the installed 
base in the hope that the mechanisms could and would be swiftly 
deployed.  There was an effort to tighten some of the 
infrastructure definitions at the time. That effort was rejected 
by the community in that context (a decision which produced some 
of the momentuum for getting what is now DRUMS together).

By contrast, DRUMS has some mandate for cleaning up messes 
that result from prior misunderstandings, insufficiently 
strong definitions, and similar messes.

> > I think that suggests that this is the time to start cleaning up 
> > our acts and suggest that servers should start rejecting DATA 
> > followed by things that aren't standard with syntax error 
> > replies.
> 
> That's a useless suggestion.
> 
> If bad clients actually exist, then every popular MTA will handle them,
> for the same reason that every popular MTA violates the RFC 1651
> requirement that servers check the ESMTP parameter syntax.

Dan, hyperbole aside, one can rationally adopt at least two 
different philosophies about the existence of bad behavior:

  * One can immediately standardize it and insist that everyone 
     adopts to the bad behavior
  * One can eliminate any ambiguity about whether or not it is 
     bad, then leave it to implementors to figure out what they 
     want to do with it.

I tend to believe in the latter, because I think the former 
gives the whole works over to creeping (or galloping) 
mediocrity.  I also tend to favor supplemental/ informational 
documents that describe bad behaviors and suggest ways to 
cope with them.  Reasonable people may disagree with either or 
both of these inclinations.

    john