[wayne]
As others have pointed out, many MTAs already have an option to
validate the HELO domain. I think doing the SPF checking is better
than most of these options, but these MTAs didn't have access
to the SPF
code when the options were created.
Many mailers do a PTR lookup on the IP address of the SMTP-sender and
try to validate the FQDN from the HELO string. Some do further DNS
tests. While this is far from universal, this practice does reject some
spam while having little collateral damage. Systems that don't have
rDNS properly configured will end up sending DSN's to their own users
and the problem is easily fixed, so any damage tends to be
self-correcting. Some people consider this a BCP.
As a policy, it says, "I am suspicious enough of SMTP-senders that don't
include their FQDN in the HELO string, or worse, include someone else's,
that I won't accept mail from them". Though a successful SPF-check
gives more information and makes this test redundant, requiring rDNS and
match of the rDNS result with the HELO domain is something we can do
today when there is no SPF record for a domain, or if the SPF record has
weak policy (like ?all or +all).
Given today's internet problems, is there any reason _not_ to configure
your HELO string with the real FQDN and enforce this from the
SMTP-recipient side, even though the RFC's don't strictly require it?
--
Seth Goodman