220 heaven.af.mil ESMTP HELO gateway.af.mil 250 heaven.af.milRFC 1123 requires that the parameter be ``a valid principal host domain name for the client host.'' However, some clients don't have names. I recommend that they use bracketed IP addresses:
220 heaven.af.mil ESMTP HELO [10.43.0.25] 250 heaven.af.mil
If the server accepts the HELO request (required code 250), its new envelope is empty.
The server's response text begins with the server's name. The server must be careful not to use another host's name here: if a sendmail client on that host connects and sees its own name, it will refuse to ``talk to itself.''
Some servers do not accept MAIL requests before HELO. Clients use HELO as the first request in every session. (Exception: see EHLO.) This is a waste of time. I recommend that server implementors let clients skip HELO, to support a future transition to a world without HELO.
Beware that many servers reject all HELO requests after the first, so clients cannot rely on HELO as a way to clear the envelope. For example, sendmail returns a 503 code.
A few servers reject messages from clients whose HELO parameters do not match the results of PTR lookups on their IP addresses. This behavior is a disaster in practice; surveys in 1998 found that more than 10% of all clients by volume use invalid HELO parameters. Compuserve reportedly uses unqualified names:
HELO NIH2WAAFRFC 1123 prohibits HELO-based rejections.
RSET parameters are prohibited. Some servers reject any RSET request with a nonempty parameter. I don't know if there are any clients that send RSET with an empty parameter, i.e., RSET followed by a space.
There is a useless RSET extension that promises support for RSET. Servers are required to support RSET anyway. Clients don't pay attention to the RSET extension.
NOOP parameters are prohibited. Some servers reject any NOOP request with a nonempty parameter.