On 30/10/10 07:42, Henrik K wrote: > On Fri, Oct 29, 2010 at 10:02:56PM -0400, dar...@chaosreigns.com wrote: >> I see there's a RDNS_NONE rule for when the sending IP address has no DNS >> PTR (reverse DNS) record. But no rule for when that PTR record doesn't >> have a matching A (forward DNS) record that matches the sending IP? >> >> Is this something that would be accepted into spamassassin if I created a >> module? Or a feature that would be added if I didn't do it? > > I doubt SA will incorporate it: > > http://marc.info/?l=spamassassin-users&m=122268554723430 > > Make it if you need it. Share it if you want. People will use it if they > find it useful.
For information, Postfix does a "full-circle" test of rDNS and puts "unknown" in the Received headers if there is a PTR record, but the value of that PTR record does not resolve, or if it resolves but does not match. And since SpamAssassin examines the hostname from the Received headers, an email from a (last untrusted) IP address with an unverified rDNS will hit RDNS_NONE. So for Postfix and sendmail, what Darxus is suggesting is already happening. For other MTAs this may be different. This means RDNS_NONE may be assigned different scores from the scoring process, depending on whether the email corpora checked have had no rDNS added to headers, had unverified rDNS added, or only verified rDNS added. That inconsistency could be an argument for creating a module. One other advantage of a rDNS lookup module would be that having unverified rDNS available to SpamAssassin separately could make it easy to write rules to catch an unverified rDNS values of a type like dsl-189-180-xxx-xxx. IMHO configuring Postfix to reject all email without verified rDNS (even with a 450 temporary error) would result in wrongly bouncing a lot of email from some organisational mail servers. By the way, another way of doing this might be to put the line "smtp: PARANOID" into /etc/hosts.deny. C
