On 10/17/2013 9:51 AM, Kai Schaetzl wrote:
> Neil Schwartzman wrote on 17 Oct 2013 07:01:00 -0700:
> 
>> incorrect, not false, which implies maliciousness. I believe Spamhaus
>> only recently, for some value of recently, started doing NS listings
>> with deeper dives that show up on an SBL listing.
> 
> They didn't list any "NS IP". If you look at the record there was spam 
> sent from 151.1.141.150 in August and nobody bothered to have it removed 
> since then (easy enough). That's why it was included. It looks very much 
> like collateral damage that errebian.it was caught. It's a web server also 
> acting as DNS for some sites.
> 
> The "deeper dive" comes from SA. I'm not yet sure if I appreciate this, 
> but I would fully agree that this should be reflected in the description 
> of the rule. 
> 
> After a second thought I think the current combination is not a good 
> thing. I understand that URIBL is not the same as a black list of mail 
> servers, it hits on spammed sites.

>>>>> Nevertheless in all other regards I
>>>>> expected from URIBL_SBL to work like the original SBL. e.g. get IP 
>>>>> address, look it up, hit or not. I did not expect it to do any fancy 
>>>>> stuff 
>>>>> like getting the nameserver and flagging the hostname if the nameserver 
>>>>> is 
>>>>> listed in SBL. I think I would like to see a second rule like 
>>>>> URIBL_ADVANCED_SBL that does fancy stuff like this.

Maybe I'm misreading you, but it seems you misunderstood what Neil said.
 He stated that the SA test is not responsible for the demonstrated
behavior.  The test queried SBL for the A record of the host in the URI.
 The SBL server in essence scanned its database for that IP, found a
cross reference to an entry in the NS blacklist, and returned 127.x.x.x
because an NS for that IP (or range) was blacklisted.

This is what Neil meant by the "deeper dive".  Again, the URIBL_SBL test
isn't responsible for this behavior.  Spamhaus is.  Thus you can't
create a separate rule to do this "deeper diving".  Spamhaus is doing
it, automagically, and it will continue to do so with the current
URIBL_SBL rule, whether you like it or not (or until enough customers
complain I guess).

> Anyway, moving the score up like the OP did is surely wrong.

Agreed.

-- 
Stan

Reply via email to