Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-Id: <v04011700b1e7640b7986@[203.97.157.3]>
In-Reply-To: <19980731040543.5066.qmail@cr.yp.to>
References: <8BB128650D00D211BAEF00A0C9C74EB902E9F6@PILGRIM>
Date: Sat, 1 Aug 1998 01:14:51 +1200
To: drums@cs.utk.edu
From: Glenn Anderson <glenn@qualcomm.co.nz>
Subject: Re: ESMTP in the 220 line

>> in MY honest opinion, that is one of
>> the unfortunate grotesque hacks that is required for interoperability
>
>It is obvious that new implementors will want this information.
>
>Are there any implementors here who disagree?

I disagree. My server implementation always tries EHLO first, and doesn't
look for ESMTP in the 220 greeting. Many years ago I did encounter a server
(I forget what it was) that dropped the connection when a HELO was sent
after the EHLO was rejected, but I coded for this as per section 4.7 of
RFC1651 (now obsoleted by RFC1869) and the problem went away. In over 4
years of use I don't recall any reports of not being able to connect to a
server because it was not compatible with this.

However in the last 4 years had a substantial number of interoperability
problems reported due to servers using just LF for the end of line,
unbracketed MAIL commands, various scripts that don't send a HELO (or EHLO)
command, and an SMTP implementation that advertised BDAT support but closed
the connection before sending a response to a BDAT command. Typically I
have found the problems get fixed and go away when they are pointed out. As
such I would not recommend workarounds for broken SMTP implementations
being added to the standards.

Glenn.