An SMTP client, after receiving the greeting message,
will normally send an HELO or EHLO command.
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.
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.
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.