Blocking email on bad HELO/EHLO information

What are we talking about?

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

EHLO domain

where the domain given is the fully qualified name (host+domain) of the sending client.
Recently, some spammers have been using the IP address of the server they are connecting to as a domain


This is annoying. Some people wonder if a test for this practice can be used to block spam.

The standards

RFC 2821 is clear, that the domain name should be that of the sending system, and should be a fully qualified name known in DNS. If such a name is unavailable, a domain literal should be used, again for the sending system.

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:

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.

Practical considerations

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.

Possible blocking rules

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.


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.