Subject: smtpupd-09 still discourages HELO

From: "D. J. Bernstein" <[email-masked]>
Date: 29 Jan 1999 17:59:09 -0000

> clients SHOULD preferentially utilize EHLO rather than HELO.

Several people have already objected to this. It's redundant for clients
that _want_ extensions; clients that _don't_ want extensions should be
free to start with HELO. Leiba's DRUMS meeting notes say

   Consensus is that "SHOULD use EHLO" be dropped, and a client that
   doesn't need extensions may use EHLO or HELO at the client's
   discretion.

The poor structure of smtpupd meant that HELO was discouraged in many
different locations in the document. Apparently the editor managed to
fix a few of these locations but missed several more.

I find it disturbing that the editor is so careless in making changes
that go against his minority views. I'm willing to make a thorough list
of HELO/EHLO references that need fixing, but before I go to the effort
I'd like some assurance that the editor will do his job honestly.

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 30 Jan 1999 02:36:58 -0000

Question for the chair: In cases like this, where DRUMS has _already_
agreed that the document should be changed, are you still demanding that
four people speak up?

---Dan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 30 Jan 1999 19:28:55 -0000

> Dan, if there are additional places where the EHLO
> preferences should be toned down as indicated by the minutes,
> please tell me where they are.

Okay. EHLO is mentioned several dozen times; in about twenty cases HELO
should be mentioned too.

> Contemporary SMTP implementations MUST support the basic extension
> mechanisms. For instance, servers MUST support the EHLO command even if
> they do not implement any specific extensions and clients SHOULD
> preferentially utilize EHLO rather than HELO. (However, for compatibility
> with older conforming implementations, SMTP clients and servers MUST
> support the original HELO mechanisms as a fallback.)  Unless the different
> characteristics of HELO must be identified for interoperability purposes,
> this document discusses only EHLO.

Eliminate this paragraph. (The relevant requirements appear below.)

> the client normally sends the EHLO command to the server, indicating
> the client's identity.  In addition to opening the session, use of EHLO
> indicates that the client is able to process service extensions and
> requests that the server provide a list of the extensions it supports.
> Older SMTP systems which are unable to support service extensions and
> contemporary clients which do not require service extensions in the mail
> session being initiated, MAY use HELO instead of EHLO.  Servers MUST NOT
> return the extended EHLO-style response to a HELO command.
> In the EHLO command the host sending the command identifies itself; the
> command may be interpreted as saying "Hello, I am <domain>" (and, in the
> case of EHLO, "and I support service extension requests").

Replacement: ``the client normally sends the HELO or EHLO command to the
server, indicating the client's identity. EHLO, unlike HELO, asks the
server for a list of the extensions it supports. SMTP servers MUST
support both HELO and EHLO, even if they do not implement any
extensions. For compatibility with old servers that do not support EHLO,
SMTP clients MUST try HELO if EHLO fails.''

> - The domain name given in the EHLO command

Replacement: ``The domain name given in the HELO or EHLO command''

> A client SMTP SHOULD start an SMTP session by issuing the EHLO command. If
> the SMTP server supports the SMTP service extensions it will give a
> successful response, a failure response, or an error response. If the SMTP
> server, in violation of this specification, does not support any SMTP
> service extensions it will generate an error response.  Older client SMTP
> systems MAY, as discussed above, use HELO (as specified in RFC 821) instead
> of EHLO, and servers MUST support the HELO command and reply properly to
> it.  In any event, a client MUST issue HELO or EHLO before starting a mail
> transaction.

Eliminate everything except the last sentence.

> immediately after EHLO, before EHLO is issued in the session,

Relpacement: ``immediately after HELO or EHLO, before HELO or EHLO is
issued in the session,''

> after the most recent EHLO.

Replacement: ``after the most recent HELO or EHLO.''

> Since EHLO implies

Replacement: ``Since HELO and EHLO imply''

> MUST first be initialized by the use of the EHLO command.

Replacement: ``MUST first be initialized by the HELO or EHLO command.''

> An EHLO command MAY be issued

Replacement: ``HELO or EHLO MAY be issued''

> RSET followed immediately by EHLO

Replacement: ``RSET followed immediately by HELO or EHLO''

> If the EHLO command is not acceptable

Replacement: ``If the HELO or EHLO command is not acceptable''

> before the EHLO was received.

Replacement: ``before HELO or EHLO was received.''
  
> domain parameter to the EHLO command

Replacement: ``domain parameter to the HELO or EHLO command''

> domain name parameter in the EHLO

Replacement: ``domain name parameter in the HELO or EHLO''

> if no EHLO command

Replacement: ``if no HELO or EHLO command''

> with EHLO before sending these commands.

Replacement: ``with HELO or EHLO before sending these commands.''

> RSET (or a new EHLO)

Replacement: ``RSET (or HELO or EHLO)''

> as presented in the EHLO command

Replacement: ``as presented in the HELO or EHLO command''
  
> not client EHLO. 

Replacement: ``not client HELO or EHLO.''
  
> EHLO, MAIL FROM,

Replacement: ``HELO or EHLO, MAIL FROM,''

> F.3 HELO
> 
> As discussed in sections 3.1 and 4.1.1, EHLO is strongly preferred to HELO
> when the server will accept the former.  Servers must continue to accept
> and process HELO in order to support older clients.

Replacement: ``F.3 EHLO   Servers are now required to accept EHLO as
well as HELO.''

---Dan