According to the RFC 5321 section 4.1.4 “An SMTP server CAN verify that the domain name argument in the EHLO command actually is same as the IP address of the client and if it fails, the server SHOULDN’T refuse to accept messages on that basis”.Hence to be in compliance with the RFCs, rejecting connections must be based on additional information/policies.

  • Refuse connections from hosts that give an invalid HELO – for example, a HELO that is not a FQDN or is an IP address not surrounded by square brackets.
    • Invalid HELO localhost
    • Invalid HELO 127.123.0.1
    • Valid HELO mydomain.tld
    • Valid HELO [127.123.0.1]
  • Refusing connection from a host that gives an obviously fraudulent HELO – issuing a HELO using the FQDN or an IP address that is unable to match the IP address of the connecting host.
    • Fraudulent HELO friend
    • Fraudulent HELO -233975334
  • Do not accept email from a hosted domain when the sending host is not authenticated.
  • Denying any email whose HELO/EHLO argument does not resolve in DNS. Unfortunately, some system administrators administer the MTA to use a non resolvable argument to the HELO/EHLO command.

You may also like to read:
Enforcing Simple Mail Standards
Invalid Pipelining of Messages
Greylisting of Incoming Messages
Implementing Greeting Delay
No Use In Responding To Spam
Keystroke logging: Types of Keystroke loggers