Hi,
rfc2821bis:
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").
------------------------------------------------------------------------
As far as I understand it, rfc2821 should cover everything that is in
rfc821 with the exception of a few well documented obsoleted items.
Also, rfc2821 wants to discourage the use of HELO without banning it
entirely. Enhanced HELO (EHLO) builds on HELO and adds, not modifies,
functionality.
This makes me believe that
a) rfc2821 tries to avoid using HELO except where necessary
b) rfc2821 tries to avoid talking about HELO except where/when necessary
c) there usually is no need to spell out "HELO or EHLO", unless something
EHLO-specific is talked about
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").
Rationale for 2.2.1: this makes it unambiguously clear that both forms
are discussed and should be interpreted that way.
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.
regards,
Alex van den Bogaerdt