HELO/EHLO checking

For example, spam can be greatly reduced by a number of simple checks confirming compliance with standard addressing and MTA operation

In many situations, simply requiring a valid FQDN in the SMTP EHLO statement is enough to block 25% of incoming spam.

  • Refusing connections from hosts that begin transmission prior to presentation of the receiving host's HELO banner
  • Refusing connections from hosts that give an invalid HELO - for example, a HELO that is not an FQDN or is an IP address not surrounded by square brackets
Invalid HELO localhost
Invalid HELO 127.0.0.1
Valid HELO domain.tld
Valid HELO [127.0.0.1]
  • Refusing connections from hosts that give an obviously fraudulent HELO - for example, issuing a HELO using the FQDN or an IP address that doesn't match the IP address of the connecting host
Fraudulent HELO friend
Fraudulent HELO -232975332
  • Refusing to accept email claiming to be from a hosted domain when the sending host has not authenticated
  • Refusing to accept email whose HELO/EHLO argument does not resolve in DNS. Unfortunately, some email system administrators ignore section 3.6 of RFC2821 and administer the MTA to use a nonresolvable argument to the HELO/EHLO command.

All of the examples above are fairly simple checks, all conform to existing standards and RFCs, and all are missing from most commercial MTA implementations available today.