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

You've come to this page because you've said something similar to the following:
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:

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

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

Logically and practically, SMTP Relay servers

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:

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

© Copyright 2004-2004 Jonathan de Boyne Pollard. "Moral" rights asserted.
Permission is hereby granted to copy and to distribute this web page in its original, unmodified form as long as its last modification datestamp is preserved.