ietf-smtp
[Top] [All Lists]

Re: EHLO/HELO

2005-09-08 09:51:44

Alex van den Bogaerdt <alex(_at_)ergens(_dot_)op(_dot_)het(_dot_)net> wrote:

2.2.1
    Unless the different characteristics of HELO must be identified for
    interoperability purposes, this document discusses only EHLO.

3.2
    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").

   I agree, this could be confusing.

I've encountered confusion about the copied text from time to time. In
such cases, people believe the reader should revert to RFC821 to read
all about HELO.  I would like to suggest different wording in order to
avoid such confusion:

2.2.1
    Unless there is need to identify the different characteristics of
    HELO vs. EHLO, this document only discusses the EHLO variant. The
    reader should implicitly add "or HELO" unless the context makes it
    clear that only EHLO is discussed.

3.2
    In the hello 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").

   I've stumbled through the "HELO/EHLO" ambiguity enough times to be
sensitive to it. Personally, I like the "hello command" phrase to refer
to either.

Rationale for 2.2.1: this makes it unambiguously clear that both forms
are discussed and should be interpreted that way.

   I'm less clear that Alex has gotten this wording right.

   Our intent is that any new implementation should not first send HELO;
but new implementations must recognize HELO. Further, we (still) require
compatibility with old clients and servers which do not support EHLO.
Blindly adding an "or HELO" to each EHLO would make it hard to parse
any explanation of that compatibility requirement.

   Further, if we are serious about _trying_ to deprecate HELO, we should
not be encouraging folks to think about it.

   I think we'd be better off generally using "EHLO" (or "hello command")
and relegating usage of "HELO" to a single compatibility note.

Rationale for 3.2: By changing the first EHLO into hello, and keeping
the second EHLO as is, both HELO and EHLO match "hello command" and
only EHLO has service extensions.

   I concur with Alex on this wording.

--
John Leslie <john(_at_)jlc(_dot_)net>

<Prev in Thread] Current Thread [Next in Thread>