Date: Tue, 02 Jul 1996 06:44:06 -0400
From: John C Klensin <klensin@mail1.reston.mci.net>
Subject: Re: 821bis outstanding issues list -- post Montreal
To: djb@koobera.math.uic.edu (D. J. Bernstein)
Cc: drums@cs.utk.edu
Message-id: <2.2.16.19960702104406.248f9998@mail1.reston.mci.net>
MIME-version: 1.0
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7BIT

At 00:37 96.07.02 +0000, D. J. Bernstein wrote:
>I propose adding the following text to the 220 discussion:
>
>   Note that many existing clients will use HELO instead of EHLO,
>   disabling ESMTP, if the server's greeting text does not contain
>   the string "ESMTP".
>
>Any objections?

Dan,

Three of them, some touched on in other notes (excuse the redundancies, I'm
going to try to draw this discussion to a close).

(1) Suppose I have a client that is designed to be configured as to which
command to use "first".   [[If I were selling a commercial product, I'd want
to do that and arrange to make the configuration different depending on
target hosts/domains for fear that there were still some of the nasty server
implementations around that would immediately close the connection if any
unrecognized verb was received.  My highly subjective impression is that we
have flushed most of those out of the public Internet, but some are almost
certainly left.]]   

Now suppose that, in addition to the configuration option, I add a heuristic
that says "if ESMTP appears in the greeting, use EHLO preferentially even if
the configuration is set to 'use HELO first'".  [[I personally wouldn't do
that because of reason #2, but tastes, religions, and risk assessments differ.]]

Whatever one thinks of this strategy, one cannot describe the behavior of
the client as having "disabled ESMTP".   Indeed, it is being attempted in a
case in which it would otherwise not be used.

I understand, and it might be interesting to note, that some versions of
sendmail work pretty much this way.

(2) There is a long, and perhaps unfortunate, history of SMTP servers using
the initial 220 line for all sorts of unrestricted editorial comments,
including ads for sites, announcements about potential shutdown times,
telephone numbers of postmasters, and political statements.   The reason I
keep using the word "heuristic" to describe your "put 'ESMTP' in the
greeting" proposals is that no existing protocol prevents such an editorial
comment from taking the form:

    220-foo.bar.baz SMTP service ready
    220 I hate ESMTP and EHLO, they are @#$%

So, while making a small optimization, your proposal also opens up another
potential failure mode.


(3)  Perhaps because of the relatively small number of SMTP implementations
out there and the ease of deploying them (when code bases are weighted by
installed base), the SMTP extensions have been implemented and installed at
a much higher rate than I would have predicted (this contrasts with serious
implementations of MIME, where the situation is the opposite), it is
sensible to push more in that direction.   Making an initial assumption that
everyone has ESMTP capability causes short-term pain for long-term gain (and
creates some useful pressure on the laggards without causing serious
interoperability problems).   Assuming that they don't, or that ESMTP can't
be deployed until yet another generation of SMTP servers are deployed (other
than yours and sendmail, of course), retards that deployment.   

A number of decisions were made in the initial ESMTP and MIME designs using
the logic that, given growth of the network and assuming that serious
interoperability problems could be avoided either way, it was far better to
design things so that the end-state was "right" (clean, efficient,...)
rather than to inflict permanent pain to make things a bit easier in the
short run and to design to reinforce transition rather than waiting.  Those
approachs still seem to me to be sensible; certainly there has been no
consensus that they were a mistake.

Even the short-term pain would not be worth the trouble, but there seemed to
be consensus in Montreal for strongly recommending support for and use of
some specific service extensions to improve network operational quality.
If we are going to do that -- e.g., to recommend that sites that
adminstratively impose size limits on messages advertise the "size" service
extension to prevent a lot of useless transmissions -- then it makes no
sense to exclude any cases in which that advertisement might be received.  

--------

It may also be worth noting that the idea of using specific opening
announcement message text instead of the ESMTP approach was considered by
the WG at some length when the initial extensions work was being done and
the arguments were focused on something then called, by its advocates, "8bit
clean".  The idea was rejected after extensive discussion -- I encourage you
to go back and read the archives if you are interested -- and should now, in
the absence of new technical arguments (none of which have yet appeared on
this list) to be dead.

I am not going to implement the proposed text above unless informed by the
chair or area directors that they have detected consensus behind it.

Since it essentially imposes a constraint on the use of ESMTP that does not
appear in RFC 1869 / STD 10, I would assume that the consensus would have to
be quite strong.

I'm unlikely to respond to further messages on this subject unless
significant new technical arguments are introduced.

      john

p.s. At the risk of starting a discussion of elementary statistical sampling
theory, one has to be suspicious of any email behavior pattern statistics
derived by inspecting the mail database of someone who builds and
distributes mail systems, especially when those statistics "prove" that the
behavior of the mail system in question is dominant/correct.  People who
build and distribute systems do, of course, carry on correspondence with
people who obtain and use their systems.

In any event, only a fool would claim that ESMTP deployment isn't still in a
transitional state.   Statistics that are highly influenced by how much
deployment has occurred, or about transitional strategies chosen by
vendors/producers, do not have obvious value in determining how to proceed
unless they document serious interoperability (not just transitional
inefficiency) problems.