[Mimedefang] validating 'possibly forged' helo IP's?

[Gary Funck]

> 4.  I don't know what end goal you are trying to achieve but using reverse
> records for any type of sercurity or blocking has pretty high
> false positive
> rates.  ISPs in my experience don't even really care about setting reverse
> DNS up.

KAM, thanks.  I'm looking to munge my greylist log entries looking for
further improvements on the 'accept without delay' heuristic.  A greylist
log entry is of the form:

MDLOG,k08G82sc010344,grey_new,60,202.223.97.20,norika_nitta at yahoo.com,gary at i
ntrepid.com,?

The perl script says the following:
./dns.pl 202.223.97.20
domain: pdf6114.tokynt01.ap.so-net.ne.jp

where the fields are queue id, record type, timeout, helo IP, sender
address,
recipient address, and subject.  Subject is always '?' on new greylist
entries.
I'd like to validate the HELO IP in some fashion without having to schlep
further
into the log to see if sendmail complains with "possibly forged", because
the
heuristic when implemented won't have the luxury of knowing what sendmail
thinks
down the line.  Of course what is missing in the log entry above is the
claimed HELO name.  Given that I could try and resolve that to an IP and
then
compare that IP to relay IP, which would be a more reliable check.

Perhaps a better heuristic for me to try is to take the sender's domain,
convert that to an IP address, and then check to see if the relay address
is an MX for the sender, or in the same /24 as the sender, or has a 'pass'
in the SPF records.  Keep in mind that the only bad thing that happens if
the heuristic fails is that the message is not tempfailed.