SMTP servers should not require, or ascribe meaning to, HELO or EHLO.

The HELO or EHLO verbs in SMTP are how the client identifies itself to the server. Clients that use single-label domain names, or domain names that the server cannot look up in the DNS database, are broken or misconfigured.

This is the Frequently Given Answer to such statements.

Identification of the client via DNS is not the purpose of the HELO or EHLO verbs. Those verbs have nothing to do with client DNS identification. Of the two, only EHLO has any practical purpose nowadays. SMTP Relay servers should not require that clients, that don't require protocol extensions, issue EHLO; and should not require that clients issue HELO at all.

Moreover, SMTP Relay servers are specifically prohibited by the Internet standards from attempting to ascribe a meaning to the argument given to a HELO or EHLO verb. This is also supported by a logical analysis of what SMTP Clients can and cannot use for that argument. The only thing that SMTP Relay servers can legitimately do with that argument is record it in its log and stuff it into a trace header.

The only purposes that HELO and EHLO serve.

The HELO verb serves two purposes, both of which are either unnecessary or obsolete, and neither of which involve DNS identification:

• It provides a mechanism for the client to ensure that the server's state machine is synchronised with it. A HELO verb is defined as resetting the server's state machine.

  This purpose is unnecessary given the sorts of reliable transport protocols that SMTP is usually carried over. The sequenced nature of the transport protocol ensures that the server's state machine does not become become out of synchronisation with the client.

• It provides a means for detecting MTS transport loops. The argument to the HELO verb is intended to be an arbitrary identifier that uniquely identifies an MTS. If the SMTP Relay server detects that its own idenitifier is being used by an SMTP Relay client, it presumes that a transport loop has occurred, causing the MTS to talk to itself. The only requirement is that this identifier be unique.

  This purpose is not only obsolete now, it was obsolete as soon as SMTP began to be adopted.

  This purpose is obsolete now because the burden of preventing loops has long since been shifted from SMTP Relay servers to SMTP Relay clients, which can perform it in a more effective and efficient manner. Instead of SMTP Relay servers checking the argument to HELO, SMTP Relay clients perform MX list truncation.

  For one thing, this eliminates the cost of setting up and tearing down the SMTP connection that is looping back. For another, it is worth noting that this HELO loop detection mechanism isn't as effective as MX list truncation is in the case that the SMTP Relay client and SMTP Relay server of a single MTS live on separate machines. The SMTP Relay server will not recognise the SMTP Relay client as itself if the client uses its own domain name in the HELO verb. (Indeed, this is one of several good arguments against enforcing a requirement that the argument to HELO be the client's own domain name.) Whereas with MX list truncation an administrator simply configures the SMTP Relay client with the correct IP address(es) of its associated SMTP Relay server.

  This purpose was obsolete as soon as SMTP began to be adopted because the the sort of loops that caused the very invention of the mechanism in the first place only occurred with a particular protocol, which fell out of use with the adoption of IP, thus eliminating the loops, between the time that SMTP was invented and the time that it started to be adopted. Mark Crispin has provided a detailed explanation of this.

The EHLO verb serves the two purposes of the HELO verb, and the additional purpose of allowing the client and server to negotiate the use of protocol extensions. This, too, does not involve DNS identification.

The upshot of this is that there's no point to HELO at all in SMTP/TCP, and only a point to EHLO if protocol extensions are actually desired.

What servers need to cope with.

Many MUAs (mis-)use SMTP Relay service in order to submit messages.

In an ideal world, an MUA would only receive the Good Netkeeping Seal of Approval if it allowed the user to explicitly and separately configure what is used for the domain name of the envelope sender, the domain name portions of message IDs, and the argument to HELO/EHLO.

In practice, MUAs don't provide this ability and wouldn't be awarded the GNKSoA:MUA. Microsoft Outlook Express and Netscape Messenger, for examples, do not provide users with a way to explicitly specify the argument to HELO/EHLO. Netscape Messenger apparently uses the domain portion of the envelope sender mailbox as the HELO/EHLO argument. In certain common configurations, Microsoft Outlook Express will use the domain name of the SMTP Relay server that it has been configured to talk to.

Of course, when the SMTP Relay client is in fact an MUA that is (mis-)using SMTP Relay service for message submission, there is no point to the SMTP Relay client actually issuing HELO at all (and the only reason for issuing EHLO is if protocol extensions are desired). The possibility of a mail transport loop simply doesn't exist, so there's nothing for the mechanism to detect.

Moreover, there's no point in the SMTP Relay server checking the argument in such a situation. It is rather daft to use it as a client authentication mechanism, since it is so trivially forged and, in any case, client IP address access controls and the AUTH protocol extension exist for that. It is equally as daft for SMTP Relay servers to expect MUAs to be capable of even locating a domain name, since end-user machines running MUAs may not even have domain names (apart from localhost.). It is downright abusive for SMTP Relay servers to require use of HELO/EHLO and thus require MUAs to obtain domain names from somewhere, forcing them to contain extra mechanisms for doing so, when the verbs are entirely unnecessary for MUAs performing message submission in the first place.

What RFC 2821 says

RFC 2821 is a deeply flawed document that is better respected in the breach than in the observance. Its treatment of HELO and EHLO is but one of its many flaws.

RFC 2821 imposes several constraints upon SMTP Relay clients. But

• as pointed out before, there are valid situations where in order to fulfil the actual intended function of HELO/EHLO these constraints must be actually contravened;

  An SMTP Relay client that supplies its own domain name will prevent the loop detection from working if its associated SMTP Relay server has a different domain name, for example.

• there is no reasonable way for SMTP Relay servers to enforce such constraints upon clients;

  In these days of augmented and diminutive roots, and "split-horizon" DNS service, it is unreasonable to expect SMTP Relay servers to have exactly the same view of the DNS namespace as SMTP Relay clients. It is therefore unreasonable to expect SMTP Relay servers to enforce a constraint that the argument to HELO/EHLO be a domain name that exists.

  and
• even RFC 2821 itself acknowledges that the constraints are ludicrous for various classes of client.

  Amusingly, RFC 2821 introduces the notion of a must if possible constraint, which is, at best, a rather woolly one. As RFC 2821 itself acknowledges, SMTP Relay clients can exist that simply do not have domain names. There is no way for an SMTP Relay server to know whether the "if possible" applies, and so no way for it to determine whether the "must" can be enforced (setting aside for now the aforementioned fact that it is not necessarily even able to enforce it).

RFC 2821, § 4.1.4, also imposes a constraint upon SMTP Relay servers that is relatively unequivocal:

An SMTP server may verify that the domain name parameter in the EHLO command actually corresponds to the IP address of the client. However, the server must not refuse to accept a message for this reason if the verification fails: the information about verification failure is for logging and tracing only.

What clients and servers must and must not do

Logically and practically, SMTP Relay clients

• must supply as the HELO/EHLO argument a string that is syntactically correct;
• should not use HELO at all; and
• should not use EHLO unless they want to negotiate protocol extensions.

Logically and practically, SMTP Relay servers

• should deprecate server-side loop detection in favour of client-side loop detection;
• must not require that clients issue either HELO or EHLO, in order to obtain unextended service;
• must not assume that they can perform any sorts of DNS lookups against the argument to HELO or EHLO, or that if such lookups fail that argument is in any way "invalid"; and
• must not, if they reject transactions because they don't like the argument to HELO or EHLO, treat the client as if it has violated the protocol in some fashion.

Note that this does not exclude SMTP Relay servers from performing server-side loop detection as it was originally designed, and rejecting any HELO or EHLO, if used, where the argument is what the server believes to be (one of) its "own" name(s). Rejecting the name localhost., or the server's own IP address (as a domain literal or as an equivalent domain name), is after all operating as the protocol was originally designed. However, DNS lookups are not involved in such a process. The domain names to be rejected are fixed, and known ahead of time by the server.

Common half-baked ideas

It's a half-baked idea to require HELO or EHLO.

This is one of the areas where RFC 2821 is, simply, downright wrong. It states that at least one of these is required before a mail transaction. But if no protocol extensions are required, issuing EHLO serves no useful purpose; and issuing HELO serves no purpose at all.

It's a half-baked idea to require that SMTP Relay clients that don't know a domain name use an IP literal giving their own IP address.

In these days of widespread use of NAT, the server has no way of knowing what the client's IP address really is, and the client has no way of determining what IP address the server will see. There's no way for a client to reliably satisfy a server that makes such checks, and there's no way for a server to make such checks correctly.

It's a half-baked idea to restrict the argument to having two or more labels.

Postfix's reject_non_fqdn_hostname mechanism is a half-baked idea that has two flaws:

• What it is rejecting is not, in fact, non-fully-qualified domain names. Postfix's notion of what constitutes a fully qualified domain name is wrong. (A fully-qualified domain name is something else entirely.) The mechanism is actually rejecting domain names that comprise just one single label.

• Fully-qualified domain names can legitimately comprise just a single label. (localhost. is perhaps the most obvious example of such a domain name.)

It's a half-baked idea to reject arguments that cannot be looked up in the DNS database.

Postfix's reject_unknown_hostname mechanism is a half-baked idea based upon the erroneous notion that a domain name that cannot be looked up in the DNS database is "unknown". But

• the view of the DNS namespace seen by Postfix's SMTP Relay server may not correspond with the view of the DNS namespace used by the SMTP Relay client talking to it;

• Postfix looks for A and MX resource record sets, but a domain name may lack these and still exist nonetheless;

  and

• for the actual purpose that the verbs serve, the argument merely need be unique to a single MTS, it need not actually be a domain name.