spamassassin-users October 2010 archive
Main Archive Page > Month Archives  > spamassassin-users archives
spamassassin-users: Re: Full circle DNS test?

Re: Full circle DNS test?

From: Cedric Knight <cedric_at_nospam>
Date: Sat Oct 30 2010 - 13:58:09 GMT
To: users@spamassassin.apache.org

On 30/10/10 07:42, Henrik K wrote:
> On Fri, Oct 29, 2010 at 10:02:56PM -0400, Darxus@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