> 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,[EMAIL PROTECTED],[EMAIL PROTECTED] 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. _______________________________________________ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list [email protected] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
