This (unfinished) note covers various tests on the legitimacy of what is passed after the initial EHLO/HELO command in an SMTP session. There is an easier way of accomplishing this ... check the Exim site for the 'helo_verify_hosts' configuration directive. The reason I'm doing this the hard way is that for me, 'helo_verify_hosts' is a little too extreme.
Note that all the following ACL snippets are intended to live in the ACL that checks the recipient. The placement seems a little odd, but rejecting at the 'RCPT TO' stage is more likely to be accepted by spamware. Also note that some of the following may be triggered by legimate clients if you haven't setup a seperate MSA.
deny message = Your server announces itself \
($sender_helo_name) with a plain \
IP address which is in breach of RFC2821.
condition = ${if match {$sender_helo_name}\
{^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\$}\
{yes}{no}}
hosts = !relay_hosts
The above checks that $sender_helo_name is not an unadorned IP address ("10.13.243.1"); a correctly formed IP address literal ("[10.13.243.1]") is accepted, it should not detect any FQDN's as there are no legitimate TLD's with all numerics.
deny message = Your server announcement ($sender_helo_name) \
is a single word rather than a FQDN. This is \
in breach of RFC2821
condition = ${if match {$sender_helo_name}\
{\\.} {no}{yes}}
The above checks whether a dot ('.') occurs in $sender_helo_name which indicates that it has a reasonable chance of being a FQDN. All servers should announce themselves with their FQDN (or a properly formatted IP literal); many (most?) servers that announce themselves with a single word are spammers of one kind or another.
Note the unusual ordering of the 'yes' and 'no' in the snippet above ... this is a simplistic way of avoiding looking up how to do 'if not match'.