Two other users replied to your question. For real-world mail servers,
my experience is that the only safe restriction (safe = no false
positives) is "reject_unknown_reverse_client_hostname".
Irrelevant to HELO argument filtering.
Relevant to rejecting emails. Perhaps I should have written "the only
safe reject restriction at that stage of the SMTP session". Once again,
the string that follows HELO/EHLO is purely informational, it should not
be used for filtering purpose.
The OP asked "is it safe", without explaining what "safe" means for him.
For me it means "safe in general", in particular for servers handling
large amounts of email.
Rejecting mail is a far better choice than delivering to a 'spam box'
since most users never bother looking there for anything. Rejections at
least stand some chance of making enough noise on the sender side to get
misconfigurations fixed.
IMO this is naive. As Kris Deugau wrote in most cases nobody ever looks
at that noise, your users will just not receive their email.
And for the particular question of the OP ("HELO <ip address>") there is
not even a reason to consider that it is a "misconfiguration", given that
what you call a "misconfiguration" is explicitly permitted by the
standards. I agree with you that "there are no RFC police". But the
purpose of RFCs is cooperation.
It is true indeed that most users do not look at their spam folder, but
they can (and should) be educated to do so, given that every spam
filtering system I know of has false positives.
Gregory
