techblog 

About a year ago we ran a test for a couple of hours to see what incoming emails we could reject because they had incorrect HELO/EHLO commands. Our criteria for rejection were:

1. If they specified a hostname (FQDN or not) but it did not resolve.
2. If they specified a hostname which did resolve but the address it resolved to was different from the IP address of the connecting host.
3. If they specified a hostname that did resolve but was different from the hostname obtained by doing a reverse lookup on the IP address of the connecting host (yes I know this was a bit harsh).
4. If they specified an IP address instead of a hostname and this was different from the IP address of the connecting host.
5. If they specified nothing or nothing intelligible.

To our surprise in just the small test period we had hundreds of rejected emails. We did an analysis of the headers and contacted about fifty of the sources to came up with the following characterisations, in no significant order:

• a hostname was specified which was our domain name. This was pretty frequent. This seems to be a clear indicator of spam. Doing a reverse lookup on the IP address invariably gives a hostname from an ISP DHCP pool.
• a hostname was specified that that was the hostname of our mail server. This was fairly rare. Again this seems to be a clear indicator of spam.
• an IP address was specified that was the IP address of our mail server. This was pretty frequent and again this seems to be a clear indicator of spam.
• a hostname was specified but this was a single label. Normally when the reverse lookup was done the hostname obtained bore no relation to the single label specified.
• a hostname was specified that ended with ‘.local’. From examination these all seem to have been Windows Domain Controllers (judging by the rest of the hostname).
• a hostname of ‘localhost’ was specified.
• an IP address of ‘127.0.0.1′ was specified.
• a hostname was specified but it was a domain name, with no hostname part. Again there was no correlation between this and the hostname returned by a reverse lookup.
• a hostname was specified but it could not be resolved. In some cases the hostname given by the reverse lookup was very similar to that specified. This nearly always indicated that the hostname that had been presented was the internal name of the host, which is why it could not resolve.
• an IP address from a private range (RFC 1918) was specified.
• a hostname was specified that resolved but was different from the hostname obtained from a reverse lookup on the IP address of the connecting host. Interestingly very little of this was spam, it was nearly always genuine but the specified hostname was from a related domain. Take the example where a company uses .co.uk for the public names but net.uk for the server names. The mail server specifies the co.uk name but it actually resolves on a reverse lookup to a net.uk name.

Unfortunately we didn’t have the time to do any statistical analysis of these results but hopefully some time we will get a chance.