Blocking email on bad HELO/EHLO information

An SMTP client, after receiving the greeting message, will normally send an HELO or EHLO command.

EHLO domain

HELO 123.45.67.89

• The SMTP client MUST, if possible, ensure that the domain parameter to the EHLO command is a valid principal host name (not a CNAME or MX name) for its host. If this is not possible (e.g., when the client's address is dynamically assigned and the client does not have an obvious name), an address literal SHOULD be substituted for the domain name and supplemental information provided that will assist in identifying the client.

However, the RFC is also clear that failure for the domain name to match the client IP address is not a basis for rejecting the message:

• 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.

There are good reasons for this MUST NOT. A sending client might be multi-hosted (have several IP addresses and names). In some situations, as when it is behind a NAT box, the client might not even know its DNS hostname or the public IP address to which its internal private IP address will be translated.

However, the concern most often raised is not that the client uses other than its own name. The concern is that the client uses the name of the server itself. RFC 2821 does not appear to take an explicit stand on that particular use. One of the original purposes of the HELO name, was so that a server could detect whether it was connecting back to itself in a loop. It could perhaps be argued that a client using the server name is interfering with this functionality. Whether that is enough to warrant blocking is a decision for the reader to make.

In practice, many PC client email programs do not get the HELO/EHLO name right. This is presumably because typical PC software does not have a good sense of hostname/domain name. Some clients use the PC netbios name, which is normally an unqualified name (no "." separating components). Other clients take the domain name from the sender email address. Others may use the domain of the server to which they are connection.

If you block defective HELO/EHLO names, you may inadvertently block your own users from sending email.

The rules I offer (but do not recommend) attempt to avoid blocking our own users. These rules are offered as hints, with the expectation that you may need to change them to suit your needs.
Note that I have not tested using the rules directly as a HACK. I have tested them manually incorporated into my ".mc" file, where they are integrated into other local rules.

If a client has authenticated, then no check is done on the HELO name. If the client IP begins with a part in class $=R, then we assume that this is one of our own users. Again, no check is done.

If these tests fail, the email is rejected under any one of the following circumstances.

• The HELO name is one of our own IP addresses.
• The HELO name is one of our own hostnames.
• The HELO name is not properly qualified (contains no ".").

Blocking based on a bad HELO is no panacea for the spam problem. The spammers can simply modify their spamware to avoid being blocked.

The suggested rules do not lookup access. One of your own clients, authorized to relay via access entries, could be blocked by these rules. If that is a problem, you will need to add another rule or three to do an access map lookup.