sendmail, 4th Edition

FEATURE(block_bad_helo)—V8.14 and Later

The HELO and EHLO client SMTP commands are each formed by a command followed by a hostname:

HELO client.host.domain
EHLO client.host.domain

According to RFC2821, the hostname provided by the client (following the HELO or EHLO SMTP) must be:

• The canonical hostname of the sending client machine. That is, a host with a domain part. For example, the name “foo” is bad because it lacks a domain. The name “.com” is bad because it lacks a host part. But the name “foo.com” is canonical and valid.

• The name of the sending client. That is, it must not be any of the names by which the server knows itself, such as “localhost” or “127.0.0.1.”

Although RFC2821 requires that these characteristics be met by the client, it also prohibits rejection based on bad values. If your site is besieged by spam, however, the niceties of RFC2821 may not seem worth following. If you desire to reject badly formed HELO/EHLO hostnames, you may do so by using this FEATURE(block_bad_helo):

FEATURE(`block_bad_helo')

Note that, with this feature defined, certain clients are not checked at all:

• If the client has authenticated with AUTH, the HELO/EHLO host is not checked.

• If the client is listed with the RELAY_DOMAIN mc macro (The RELAY_DOMAIN mc macro on page 269) or in the file specified by the RELAY_DOMAIN_FILE mc macro (The RELAY_DOMAIN_FILE mc macro on page 269), that client’s HELO/EHLO hostname is not checked.

Otherwise, all other clients have the host part of the HELO/EHLO greeting ...