Subject: Re: SMTP WG Last-Call

From: "Nick Shelness/SSW/Lotus" <[email-masked]>
Date: Fri, 21 Jul 2000 10:39:06 +0100

Dave,

You ask

> What is the measure of rough consensus? Some fixed number of positive
> responses? A certain ratio of positives to negatives?

Let us begin with consensus. This is when all members of a community agree 
with a proposition, or in a slightly weaker form choose to either agree 
with a proposition or abstain from opposing it.  Within IETF working 
groups, opponents may wish to express objection, but do not feel strongly 
enough about the issue to block progress. This is often referred to 
informally as rough consensus. In addition, there may be disruptive 
individuals, who if pure consensus was required, could cause a working 
group activity to grind to a complete halt. Therefore, IETF procedures 
allow a working group chair to declare rough consensus even when full 
consensus has not been achieved. In reaching this decision, the chair must 
take into account the number, the standing and the credibility or the 
objectors. IETF procedures also allow this declaration to be appealed to 
the IESG and beyond. In the vast majority of working groups this never 
occurs.  Unfortunately, the drums chair has had to do so on an overly 
large number of occasions (I wonder why), though he tries to avoid it at 
all costs. Instances that I particularly remember include the retention of 
VRFY and EXPN commands in 821bis. There were many others. 

Nick

Nick Shelness, IBM Fellow
Chief Technology Officer
Lotus Development Corp
Tel: (617) 693-7484

Assistant: Mary McGurran
Tel: (617) 693-4321

---

From: "Nick Shelness/SSW/Lotus" <[email-masked]>
Date: Mon, 24 Jul 2000 06:17:03 -0400

Dave,

You wrote in response to my response to Dan.

> >1.
> >>   In reality, for interoperability with existing clients, servers
> >>   recognize \012 as a line terminator ...
> >
> >This is true, but is independent of whether it should be required under 

> >the standard. I believe that we reached rough consensus that under the 
> >standard, <CRLF> be the only valid command terminator.
> 
> The question is not whether it should be required or not, the question
> is whether or not servers should be allowed to recognize \012 as a
> line terminator. Nobody is arguing that clients should be allowed to
> send \012 as a line terminator.

Very early on in the drums effort, the working group was faced by a 
choice. In updating RFC 821/1123 and 822, we could a)leave the documents 
largely as they were, b) update the documents to legitimize what had 
previously been protocol violations, or c) update the documents to 
actively reject protocol violations. If a) was the choice taken, then 
there was not much need for drums. Both b) and c) are perfectly legitimate 
choices. At the time the consensus of the group was to pursue c) and this 
has been the case ever since.

What you are arguing for here is effectively a), which in this case 
clearly hasn't been historically very successful. If we can't reach rough 
consensus on a matter (see for example, the reply-to: discussions, then 
the group has little choice to stay with a). But in this case, we 
previously did reach rough consensus, which was to pursue approach c) and 
to actively reject illegal command terminators.

> >2.
> >>   In reality, for interoperability with existing clients, servers
> >>   accept (for example) EHLO requests containing underscores. ...
> >
> >Again, this is true, but is independent of whether it should be 
required 
> >under the standard. I believe that we reached consensus that under the 
> >standard EHLO requests MUST NOT contain underscores.
> 
> Same thing: `should servers be allowed to *accept* EHLO requests
> containing underscores', not `should clients be allowed to *send*
> them'.

See my response to 1 above.
 
> >3.
> >>   In reality, if an SMTP client is in the middle of sending a 
message,
> >>   and is unable to read the next portion of the message from disk, it
> >>   ruthlessly closes the connection. ...
> >
> >Again, this is true, and the standard should and does state what a 
server 
> >and client should do when a connection is closed prior to the 
transmission 
> >of a QUIT and receipt of a QUIT response.
> >
> >To that end, I think that the text in the final paragraph of section 
3.9 
> >(the only one that addresses client behavior) could be expanded 
slightly 
> >to make it clear that there are environmental circumstances (in 
addition 
> >to those listed) beyond a client's control that may require it to 
> >terminate a connection. For example,
> >
> >   SMTP clients that experience events beyond their control, such as an 

> >   unrecoverable disk read failure, a notification of impeding system 
> >   shutdown,> a connection close, a connection reset, or other type
> >   communications failure (in violation of the intent of this 
> >   specification but sometimes unavoidable) SHOULD, to maintain the 
> >   robustness of the mail system, treat the mail transaction as if a 
451 
> >   response had been received and act accordingly.
> >
> >But fundamentally, this was never at issue. What was at issue is 
whether 
> >it was valid under the standard for a client to tear down a connection 
> >after receiving a positive response to a <CRLF> . <CRLF> and with out 
> >sending a QUIT and receiving a response. Again, I believe that rough 
> >consensus was reached that it was not.
> 
> That may be so, but isn't a little silly to go through all the trouble 
> to mandate sending the QUIT when possible, if it serves no useful
> purpose? Especially when skipping the QUIT exchange saves several
> round trips?
> 
> If servers have to Do The Right Thing when the connection dies at a
> certain point, what is gained by outlawing the intentional breaking of 
> the connection?

Clearly SMTP could have designed originally without starting and ending 
in-band brackets (i.e., without HELO and QUIT commands), but it wasn't. 
The working group, with the exception at the time largely of Dan, didn't 
feel comfortable about removing them. So that today, a client that tears 
down a TCP connection prior to sending a QUIT and receiving a response, is 
violating the protocol. In the context of my response to 1 above, the 
working group chose approach c).

> >13.
> >>  In reality, firewalls and POP toasters often run pure SMTP servers.
> >>  They do not send mail through SMTP, and they are not expected to
> >>  support any SMTP client features. Installing unused code is a
> >>  violation of some corporate security policies. ...
> >
> >RFC 821bis describes on the wire behavior. Thus, an SMTP server need 
only 
> >support on the wire RFC 821bis server features, and an SMTP client need 

> >only support on the wire RFC 821bis client features. Where's the 
problem?
> 
> The problem is that the draft goes beyond specifying wire behavior: it 
> says that not supporting VRFY is a potential interoperability problem,
> which it isn't.

VRFY and responses to it are on the wire. For the rest, see my response to 
1 above.
 
> >15.
> >>   In reality, there are many common non-MIME body structures. ...
> >
> >This is also true, but again rough consensus was reached within the 
> >working group that RCF 821bis and 822bis should strongly encourage the 
use 
> >of MIME, to the exclusion of all other body structures.
> 
> So the rough consensus of the working group was to lie? It's one thing 
> to encourage MIME, and another to pretend that it's the only way to
> structure bodies.

On the widely interoperable Internet, which is what RFC 821bis and 822bis 
are addressing, it is the only way to structure bodies! This in no way 
precludes communities from employing other experimental encodings.

Nick

Assistant: Mary McGurran
Tel: (617) 693-4321