Message-ID: <39773C1E.A22B87B4@cisco.com>
Date: Thu, 20 Jul 2000 10:51:26 -0700
From: Eliot Lear <lear@cisco.com>
Reply-To: lear@cisco.com
Organization: Cisco Systems
MIME-Version: 1.0
To: "D. J. Bernstein" <djb@cr.yp.to>
CC: drums@cs.utk.edu
Subject: Re: SMTP WG Last-Call
References: <1461297.3173012530@nifty-jr.west.sun.com> <20000720001401.19958.qmail@cr.yp.to>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I generally agree with Keith Moore.   We've been around this block
before, but nevertheless, this is the time in our process for
objections.  Consider this note largely speaking an endorsement of
the document, but one or two touch-ups would be nice.

There are two generic themes to Dan Bernstein's note.

The first is that he offensively uses the term "Klensin says" when in
reality John has done an extraordinary job of bringing together
different views for what amounts to the singularly most visible project
since IPng or HTTP1.1.  I agree with others that I find it hard to
navigate through such ad hominem (doubly so when I might agree with one
of his points).

The second is that Mr. Bernstein hides behind the phrase "breaks
existing implementations".  Some behavior is simply wrong and to do
otherwise would cause MORE interoperability problems.  The goal of the
document is to improve interoperability.  There is a natural tendency to
test against existing implementations.  However, we must avoid leaving
sufficient ambiguity in the text that several independent
implementations could be developed such that it would be impossible to
interoperate amongst the group.  A clean and clear spec. with as little
wiggle room as possible is the best solution to this problem.

By the way, Bernstein's own mailer is notoriously broken, in as much as
it refuses valid messages from a valid source to a valid destination. 
Playing fast and lose with the rules only further confuses unwitting
civilians for what amount to trivial reasons.

So for the record, in the interests of space and time, unless otherwise
indicated, I fully agree with Keith.  Here are the exceptions and
elaboration.


Dan Bernstein complains 
	about language that says that servers must deal with trivial loops. 
They must.  Because indirection is part and parcel with alias and
mailing list parsing, and because such indirection occurs across
multiple hosts, you need some form of loop detection.  John cites the
obvious method.  However, there are others.  For instance, one can look
to see how many times a message-id was processed over a fixed period of
time or combine that approach with a destination hash.  Each method has
its own pitfalls but is better than nothing.  The wording in the
document demonstrates that this is implementation guidance and not The
Idiot's Guide to SMTP.

Dan Bernstein complains
	that prohibition of the user of VRFY in ESMTP without it being listed
in the EHLO response is foolish, even though this is sound conservative
architecture.  More to the point- programs that attempt to use VRFY
should use EHLO and not bother the server if it's not listed.

Dan Bernstein complains
	that rejection of verbs with excess garbage on them is wrong, when in
reality accepting them may well lead to unforeseen interoperability
problems as well as security risks.  What happens if there is a
collision in the non-standard usage?  That turns into an SMTP
interoperability problem, about which Mr. Bernstein later complains.

In fact, Mr. Bernstein is basing most of his objections on HIS
implementation and not looking beyond it.  The group has rightly looked
beyond one implementation and provided for methods for Mr. Bernstein to
deal with his implementation through the use of X- EHLO extensions.

Dan Bernstein complains
	that the document requires SMTP agents to present themselves as full
implementations.  They should.  Firewalls and "POP toasters" need to
follow the same rules as everyone else so long as connections can occur
in a way that was not pre-arranged.  Consenting adults don't need
standards.

Dan Bernstein complains
	about the definition of mail relays.  That definition is consistent
with what we've said previously.  Mention of QMTP or other protocols
would be at best superfluous and at worst an endorsement of a non-IETF
protocol.

Dan Bernstein complains
	that we only endorse MIME as the structured format.  For
interoperability reasons, we should, especially since it is the ONLY
IETF-endorsed structured format.  Structure is most useful when others
can understand it.  Want to use your own?  That's fine between
consenting adults.

Dan Bernstein complains
	that clients ought not use MX records when connecting to relays.  Why? 
This is a perfectly fine use of an MX record and allows for a very
simple mechanism for MULTIPLE relays with preference indication!  In
fact this point bothers me more than most, since a so-called implementor
is making trade-offs against his potential customers.  Please let there
be no doubt.  When we did RFC 1123 we weighed existing behavior against
potential benefit to the user, and neither side had an infinite amount
of weight.

Dan Bernstein complains
	that the document restricts him from copying envelope information into
the headers.  That is correct, it does, in order to preserve blind
carbon copy functionality.  The reasoning for the objection has to do
with multi-drop POP boxes.  Isn't that POP's failure, not SMTP?  It *is*
possible to preserve envelope information at the end points, and that is
strictly an end implementation decision.

Dan Bernstein complains
	about the desire to move people to ESMTP.  This is important, as more
and more clients move to ESMTP, old code paths are going to get dusty. 
Let's move people away from it sooner than later.  The notion that EHLO
adds excessive complexity is beyond the pale.  Especially in mail relays
the benefits clearly outweigh the costs.  Again, I pretty much agree
with Keith on this point.

And so I find myself in luke warm agreement with Dan Bernstein on
several points, the QUIT businesses being two such points, as previously
mentioned.  VRFY and EXPN should be done away with, since at this point
they can cause more harm than good, and we ought not encourage their
use.  Also, clients MUST send the appropriate code, and servers should
be liberal in honoring 3xx.

Finally, I agree with Dan Bernstein that SMTP is most certainly not the
most efficient protocol.  This follows the rule that specific
optimizations always outperform general optimizations.  SMTP must cover
a broad number of cases and provide interoperability for implementations
stretching back 15 years, a truly honerous task, one that Mr. Bernstein
clearly does not appreciate.

Y10K indeed.  Let's see if we can make it to Y2.037k.
--
Eliot Lear
lear@cisco.com