Prev: postfix gmail.smtp.com -port 587
Next: SMTP AUTH not subjected to unnecessary check?
From: Noel Jones on 4 Mar 2010 15:51
This patch adds a "reject_rhsbl_reverse_client" function that
uses the unverified client hostname for the RBL lookup.

The idea is that this might increase rhsbl hit rates if the
hostname is more frequently available. On the other hand,
spam-only domains seem to usually have verifiable hostnames,
so I'm not sure how much this will really help.

This "seems to work", but the usual disclaimers apply.

Comments welcome.



-- Noel Jones
From: Wietse Venema on 4 Mar 2010 16:17
Noel Jones:
> This patch adds a "reject_rhsbl_reverse_client" function that
> uses the unverified client hostname for the RBL lookup.
>
> The idea is that this might increase rhsbl hit rates if the
> hostname is more frequently available. On the other hand,
> spam-only domains seem to usually have verifiable hostnames,
> so I'm not sure how much this will really help.
>
> This "seems to work", but the usual disclaimers apply.
>
> Comments welcome.

Looks OK.

At this point in the code we don't have to worry that the hostname
is a smoking pile of radioactive waste. Postfix's name lookup
routine has verified that the name satisfies the applicable RFC
requirements for syntax and size.

Wietse

From: Stan Hoeppner on 5 Mar 2010 07:05
Noel Jones put forth on 3/4/2010 2:51 PM:
> This patch adds a "reject_rhsbl_reverse_client" function that uses the
> unverified client hostname for the RBL lookup.

Cool. Thanks Noel.

> The idea is that this might increase rhsbl hit rates if the hostname is
> more frequently available. On the other hand, spam-only domains seem to
> usually have verifiable hostnames, so I'm not sure how much this will
> really help.

I don't quite follow your second statement here. Isn't this patch supposed
to grab the domain name from the client's rDNS name? Snowshoe spammers
usually do have reverse name records for all their sending IPs, so this
should work great (assuming the RHS dnsbls are listing the domains).

For instance, here are 5 snowshoe ranges at a spam facilitator ISP I
recently did research on. 33K+ snowshoe IPs all with rDNS names:

http://www.hardwarefreak.com/eonix.rdns.txt
http://www.hardwarefreak.com/eonix2.rdns.txt
http://www.hardwarefreak.com/eonix3.rdns.txt
http://www.hardwarefreak.com/eonix4.rdns.txt
http://www.hardwarefreak.com/eonix5.rdns.txt

If the Spamhaus DBL was listing all the domains in the 5 pages above, would
this patch not reject connections from all these hosts? This is the goal of
this patch, right?

--
Stan

From: Noel Jones on 5 Mar 2010 08:36
On 3/5/2010 6:05 AM, Stan Hoeppner wrote:
> Noel Jones put forth on 3/4/2010 2:51 PM:
>> The idea is that this might increase rhsbl hit rates if the hostname is
>> more frequently available. On the other hand, spam-only domains seem to
>> usually have verifiable hostnames, so I'm not sure how much this will
>> really help.
>
> I don't quite follow your second statement here. Isn't this patch supposed
> to grab the domain name from the client's rDNS name? Snowshoe spammers


By "help" I mean catch spam that would not be caught by the
existing reject_rhsbl_client, ie. domains with spammy rDNS but
no matching A record logged as "unknown".

Seems to me that most dedicated-spam domains are careful to
set up proper FCRDNS; this patch won't have any *additional*
effect on those domains. But it might help catch some. In
two days of using dbl.spamhaus I've had exactly 3 hits on
client names; all had proper FCRDNS and would have been
rejected with the existing rhsbl code. Hopefully this will
improve.

On the other hand, one could argue that it is proper to always
use the unverified reverse client for rhsbl lookups and the
existing reject_rhsbl_client is too strict. I have trouble
imagining a case where using the unverified reverse name would
lead to a false positive.

-- Noel Jones

 | 
Pages: 1
Prev: postfix gmail.smtp.com -port 587
Next: SMTP AUTH not subjected to unnecessary check?