Re: no rDNS and RDNS_NONE (Was: New free blacklist: BRBL - Barracuda Reputation Block List)

[Justin Mason <jm...@jmason.org>]

mouss writes:
> Justin Mason wrote:
>  >[snip]
>  >
>  > In fairness -- if you drop mail with no rDNS, you are dropping 3.6% of
>  > legit email in general, going by the test results for our RDNS_NONE
>  > rule... ;)
> 
> It just came to my mind that RDNS_NONE does not mean the client does not 
> have a reverse DNS, be it confirmed or just a PTR.
> 
> RDNS_NONE uses the rdns field determined from the Received headers, but
> - some MTAs do not do rDNS lookup

true.

> - there may be a temp fail

But this would be indistinguishable by an MTA that refuses at SMTP HELO
time, too.

> - there may be a mismatch (PTR exists but doesn't resolve back to IP)

I don't know of an MTA that removes rDNS from the Received: header if
that occurs.  do you?

> so the 3.6% include more than IPs without a (valid) PTR.
> 
> It would be interesting to get stats for each category, but this 
> requires doing the lookup in SA. which brings us back to an old request: 
> add the possibility to lookup rDNS in SA. Are there any caveats in 
> adding this? I am thinking of something like
> 
> resolve_ip (0|1|2)
> where 1 means a PTR lookup only, and 2 a "double" lookup ("FcrDNS"), and 
> the lookup is only done on the most external relay?

There *were* rDNS lookups in SpamAssassin, but they caused trouble:

- 1. they need to be asynchronous, like the most of the rest of
  SpamAssassin's network test infrastructure, and they weren't.

- 2. it causes differences in running many of SpamAssassin's rules, even
  non-net-test ones, depending on whether -L was on or not.

simpler to take it out and rely on the MTA.

--j.

Re: no rDNS and RDNS_NONE (Was: New free blacklist: BRBL - Barracuda Reputation Block List)

[mouss <mo...@netoyen.net>]

Justin Mason wrote:
> mouss writes:
>> Justin Mason wrote:
>>  >[snip]
>>  >
>>  > In fairness -- if you drop mail with no rDNS, you are dropping 3.6% of
>>  > legit email in general, going by the test results for our RDNS_NONE
>>  > rule... ;)
>>
>> It just came to my mind that RDNS_NONE does not mean the client does not 
>> have a reverse DNS, be it confirmed or just a PTR.
>>
>> RDNS_NONE uses the rdns field determined from the Received headers, but
>> - some MTAs do not do rDNS lookup
> 
> true.
> 
>> - there may be a temp fail
> 
> But this would be indistinguishable by an MTA that refuses at SMTP HELO
> time, too.
> 
>> - there may be a mismatch (PTR exists but doesn't resolve back to IP)
> 
> I don't know of an MTA that removes rDNS from the Received: header if
> that occurs.  do you?
> 

postfix will set the rdns to "unknown". I don't know what other MTAs do. 
but in general, it is unwise for an MTA to set the rDNS if it is not 
"forward confirmed".

>> so the 3.6% include more than IPs without a (valid) PTR.
>>
>> It would be interesting to get stats for each category, but this 
>> requires doing the lookup in SA. which brings us back to an old request: 
>> add the possibility to lookup rDNS in SA. Are there any caveats in 
>> adding this? I am thinking of something like
>>
>> resolve_ip (0|1|2)
>> where 1 means a PTR lookup only, and 2 a "double" lookup ("FcrDNS"), and 
>> the lookup is only done on the most external relay?
> 
> There *were* rDNS lookups in SpamAssassin, but they caused trouble:
> 
> - 1. they need to be asynchronous, like the most of the rest of
>   SpamAssassin's network test infrastructure, and they weren't.
> 

indeed.

> - 2. it causes differences in running many of SpamAssassin's rules, even
>   non-net-test ones, depending on whether -L was on or not.
> 
> simpler to take it out and rely on the MTA.


true. I have some mail that is fetched from an ISP where rdns lookup is 
disabled. but I guess I'd better pass mail to a script that does 
resolution before passing mail to SA instead of changing SA!

thanks for the comments.

Re: no rDNS and RDNS_NONE (Was: New free blacklist: BRBL - Barracuda Reputation Block List)

[Joseph Brennan <br...@columbia.edu>]

--On Monday, September 29, 2008 11:52 +0100 Justin Mason <jm...@jmason.org> 
wrote:

>> - there may be a mismatch (PTR exists but doesn't resolve back to IP)
>
> I don't know of an MTA that removes rDNS from the Received: header if
> that occurs.  do you?


Sendmail.  The name is not shown if there is no PTR, or if the name in
the PTR record has an A record pointing only to some other IP address.


Joseph Brennan
Lead Email Systems Engineer
Columbia University Information Technology