You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Marco <fa...@csi.it> on 2013/10/17 12:25:16 UTC

Strange URIBL_SBL false positive?

Hello,

 If I submit this to Spamassassin 3.3.2:

  <div><b>Da:</b> &lt;<a
href="mailto:ziopino@errebian.it">ziopino@errebian.it</a>&gt;<br>;
   <b>Cc:</b> Alice &lt;<a
href="mailto:alice@errebian.it">alice@errebian.it</a>&gt;,
   Bob &lt;<a href="mailto:bob@errebian.it">bob@errebian.it</a>&gt;<br>;

I see:

 7.0 URIBL_SBL              Contains an URL listed in the SBL blocklist
                            [URIs: errebian.it]

...but errebian.it IPs are not in SBL..!

Could you help me to understand?
Thank you very much!!

Marco


Re: Strange URIBL_SBL false positive?

Posted by Axb <ax...@gmail.com>.
On 10/17/2013 12:25 PM, Marco wrote:
> Hello,
>
>   If I submit this to Spamassassin 3.3.2:
>
>    <div><b>Da:</b> &lt;<a
> href="mailto:ziopino@errebian.it">ziopino@errebian.it</a>&gt;<br>;
>     <b>Cc:</b> Alice &lt;<a
> href="mailto:alice@errebian.it">alice@errebian.it</a>&gt;,
>     Bob &lt;<a href="mailto:bob@errebian.it">bob@errebian.it</a>&gt;<br>;
>
> I see:
>
>   7.0 URIBL_SBL              Contains an URL listed in the SBL blocklist
>                              [URIs: errebian.it]
>
> ...but errebian.it IPs are not in SBL..!
>
> Could you help me to understand?
> Thank you very much!!


errebian.it's NSIP 151.1.141.150 listed on sbl.spamhaus.org

http://www.spamhaus.org/sbl/query/SBL192766

Re: Strange URIBL_SBL false positive?

Posted by Axb <ax...@gmail.com>.
On 10/17/2013 03:37 PM, Marco wrote:
>
>> the unreal score this person is using "7.0 URIBL_SBL"
>> means he's screaming for trouble
>>
>> definitely NOT an FP
>>
>
> I though SBL could be safe for MTA blocking configurations.
> If the plugin works as explained I'll restore the score to the default.
>
> Many thanks
> Marco
>

That rule looks at URIs in msg body.... has nothing to do with MTA/Rcvd 
headers which why it is called " URIBL_SBL"

Re: Strange URIBL_SBL false positive?

Posted by Marco <fa...@ruparpiemonte.it>.
> the unreal score this person is using "7.0 URIBL_SBL"
> means he's screaming for trouble
>
> definitely NOT an FP
>

I though SBL could be safe for MTA blocking configurations.
If the plugin works as explained I'll restore the score to the default.

Many thanks
Marco


Re: Strange URIBL_SBL false positive?

Posted by Axb <ax...@gmail.com>.
On 10/17/2013 08:08 PM, Kai Schaetzl wrote:
> Axb wrote on Thu, 17 Oct 2013 17:05:48 +0200:
>
>> 15 live SBL listings aren't collateral damage:
>
> It doesn't matter if there is more evidence. The scoring via URIBL_SBL would
> have happened no matter whether the other 14 exist or not.
>
>> It doesn't get the nameserver, it gets the NS IP
>
> What's the difference?
> I would think it's got to do:
> - has hostname
> - get nameservers for hostname/zone
> - get IP addresses
>
> not?

since SA 3.3.x you also query a list of NS names as in URIBL's extra 
data sets:

http://www.uribl.com/datasets.shtml
black_ns.txt

Before SA 3.3, you could only query for a NS's IP.

Don't know of any public URI list which provides a *public* list of this 
type, but I know of a number of privately run ones.


>> This rule has been around for +5 years and all of sudden, when it gets
>> good teeth ppl are suprised?
>
> Surprised by my naivety, for instance ;-) I would not have thought it looks up
> nameservers, although I may have read it about 5 years ago. (I've been using
> SA much longer than 5 years.)

SA offers a huge wealth of features to make our lives easier - 
following the develpment list /SVN commits is a good way of goind deeper.

> I think it's good that these issues come up, as people can make up their mind,
> changes can be done or rules disabled or they just continue using and adjust
> their scores ...

Most don't need or want to wade into the code so SA devs have always 
trie to deliver a working set for most, but there's a lot to more to 
discover under the hood.



Re: Strange URIBL_SBL false positive?

Posted by Kai Schaetzl <ma...@conactive.com>.
Axb wrote on Thu, 17 Oct 2013 17:05:48 +0200:

> 15 live SBL listings aren't collateral damage:

It doesn't matter if there is more evidence. The scoring via URIBL_SBL would 
have happened no matter whether the other 14 exist or not.

> It doesn't get the nameserver, it gets the NS IP

What's the difference?
I would think it's got to do:
- has hostname
- get nameservers for hostname/zone
- get IP addresses

not?

> This rule has been around for +5 years and all of sudden, when it gets 
> good teeth ppl are suprised?

Surprised by my naivety, for instance ;-) I would not have thought it looks up 
nameservers, although I may have read it about 5 years ago. (I've been using 
SA much longer than 5 years.)

I think it's good that these issues come up, as people can make up their mind, 
changes can be done or rules disabled or they just continue using and adjust 
their scores ...


Kai

-- 
Get your web at Conactive Internet Services: http://www.conactive.com




Re: Strange URIBL_SBL false positive?

Posted by Axb <ax...@gmail.com>.
On 10/17/2013 04:51 PM, 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.

15 live SBL listings aren't collateral damage:

http://www.spamhaus.org/sbl/listings/it.net

Obvious that ISP doesn't care - I would take my business somewhere else.


> 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.

be patient - till next sa-update :)

> 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.

It doesn't get the nameserver, it gets the NS IP
name server lookups require a urifullnsrhssub eval rule.

This rule has been around for +5 years and all of sudden, when it gets 
good teeth ppl are suprised?

Since it was born, there have been many changes/additions in the 
URIBL.pm plugin.
See the SVN log for that module for details, etc.



Re: Strange URIBL_SBL false positive?

Posted by Axb <ax...@gmail.com>.
On 10/17/2013 08:27 PM, Stan Hoeppner wrote:
> On 10/17/2013 10:55 AM, Axb wrote:
>> On 10/17/2013 05:41 PM, Stan Hoeppner wrote:
>>> 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).
>> Stan,
>>
>> Spamhaus did nothing other than publishinh an IP with a karma
>>
>> elts get the termis right
>> SA did a a query using eval:check_uridnsbl, which means:
>>
>> Is the domain's NS IP listed in SBL?
>> sbl.spamhaus.org replied with yes...
>> rule hit
>
> I may be misreading it, but it seems to suggest that's only true if
> version < 3.004.  If greater, then the check is for the A record, not
> the NS IPs.  Or is this version of 25_uribl.cf out of date?

check_uridnsbl has always been about NS IPs

as from SA  3.4 check_uridnsbl also does A lookups

by adding  "a" to the tflags


>
> http://svn.apache.org/repos/asf/spamassassin/trunk/rules/25_uribl.cf
>
>
> ###########################################################################
> ## Spamhaus
>
> uridnssub       URIBL_SBL        zen.spamhaus.org.       A   127.0.0.2
> body            URIBL_SBL        eval:check_uridnsbl('URIBL_SBL')
> describe        URIBL_SBL        Contains an URL's NS IP listed in the
> SBL blocklist
> tflags          URIBL_SBL        net
> reuse           URIBL_SBL
>
> if (version >= 3.004000)
>    ifplugin Mail::SpamAssassin::Plugin::URIDNSBL
>
>      uridnsbl        URIBL_SBL_A    sbl.spamhaus.org.   A
>      body            URIBL_SBL_A    eval:check_uridnsbl('URIBL_SBL_A')
>      describe        URIBL_SBL_A    Contains URL's A record listed in the
> SBL blocklist
>      tflags          URIBL_SBL_A    net a
>    endif
> endif
>
>> Spamhaus' FAQ is incorrect:
>>
>> http://www.spamhaus.org/faq/section/Spamhaus%20SBL#270
>>
>> I hear the SBL can also block domains, how? What is "URIBL_SBL"?
>>      Yes, the SBL can also be used as a URI Blocklist and is particularly
>> effective in this role. In tests, over 60% of spam was found to contain
>> URIs (links to web sites) whose webserver IPs were listed on the SBL.
>> SpamAssassin, for example, includes a feature called URIBL_SBL for this
>> purpose. The technique involves resolving the URI's domain to and IP
>> address and checking that against the SBL zone.
>>
>> I'll try to get this corrected...
>>
>> h2h
>


Re: Strange URIBL_SBL false positive?

Posted by Stan Hoeppner <st...@hardwarefreak.com>.
On 10/17/2013 10:55 AM, Axb wrote:
> On 10/17/2013 05:41 PM, Stan Hoeppner wrote:
>> 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).
> Stan,
> 
> Spamhaus did nothing other than publishinh an IP with a karma
> 
> elts get the termis right
> SA did a a query using eval:check_uridnsbl, which means:
> 
> Is the domain's NS IP listed in SBL?
> sbl.spamhaus.org replied with yes...
> rule hit

I may be misreading it, but it seems to suggest that's only true if
version < 3.004.  If greater, then the check is for the A record, not
the NS IPs.  Or is this version of 25_uribl.cf out of date?

http://svn.apache.org/repos/asf/spamassassin/trunk/rules/25_uribl.cf


###########################################################################
## Spamhaus

uridnssub       URIBL_SBL        zen.spamhaus.org.       A   127.0.0.2
body            URIBL_SBL        eval:check_uridnsbl('URIBL_SBL')
describe        URIBL_SBL        Contains an URL's NS IP listed in the
SBL blocklist
tflags          URIBL_SBL        net
reuse           URIBL_SBL

if (version >= 3.004000)
  ifplugin Mail::SpamAssassin::Plugin::URIDNSBL

    uridnsbl        URIBL_SBL_A    sbl.spamhaus.org.   A
    body            URIBL_SBL_A    eval:check_uridnsbl('URIBL_SBL_A')
    describe        URIBL_SBL_A    Contains URL's A record listed in the
SBL blocklist
    tflags          URIBL_SBL_A    net a
  endif
endif

> Spamhaus' FAQ is incorrect:
> 
> http://www.spamhaus.org/faq/section/Spamhaus%20SBL#270
> 
> I hear the SBL can also block domains, how? What is "URIBL_SBL"?
>     Yes, the SBL can also be used as a URI Blocklist and is particularly
> effective in this role. In tests, over 60% of spam was found to contain
> URIs (links to web sites) whose webserver IPs were listed on the SBL.
> SpamAssassin, for example, includes a feature called URIBL_SBL for this
> purpose. The technique involves resolving the URI's domain to and IP
> address and checking that against the SBL zone.
> 
> I'll try to get this corrected...
> 
> h2h

-- 
Stan



Re: Strange URIBL_SBL false positive?

Posted by Axb <ax...@gmail.com>.
On 10/17/2013 05:41 PM, Stan Hoeppner wrote:
> 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).
Stan,

Spamhaus did nothing other than publishinh an IP with a karma

elts get the termis right
SA did a a query using eval:check_uridnsbl, which means:

Is the domain's NS IP listed in SBL?
sbl.spamhaus.org replied with yes...
rule hit

Spamhaus' FAQ is incorrect:

http://www.spamhaus.org/faq/section/Spamhaus%20SBL#270

I hear the SBL can also block domains, how? What is "URIBL_SBL"?
	Yes, the SBL can also be used as a URI Blocklist and is particularly 
effective in this role. In tests, over 60% of spam was found to contain 
URIs (links to web sites) whose webserver IPs were listed on the SBL. 
SpamAssassin, for example, includes a feature called URIBL_SBL for this 
purpose. The technique involves resolving the URI's domain to and IP 
address and checking that against the SBL zone.

I'll try to get this corrected...

h2h






Re: Strange URIBL_SBL false positive?

Posted by Stan Hoeppner <st...@hardwarefreak.com>.
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

Re: Strange URIBL_SBL false positive?

Posted by Kai Schaetzl <ma...@conactive.com>.
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.

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

Kai

-- 
Get your web at Conactive Internet Services: http://www.conactive.com




Re: Strange URIBL_SBL false positive?

Posted by Axb <ax...@gmail.com>.
FTR:

describe        URIBL_SBL        Contains an URL's NS IP listed in the 
SBL blocklist


COMMIT/trunk/rules/25_uribl.cf
Committed revision 1533093.

Re: Strange URIBL_SBL false positive?

Posted by Axb <ax...@gmail.com>.
On 10/17/2013 04:01 PM, Neil Schwartzman wrote:
>
>
> On Oct 17, 2013, at 6:49 AM, Tom Hendrikx <to...@whyscream.net> wrote:
>
>>
>> Basicly the description "Contains an URL listed in the SBL
>> blocklist [URIs: example.com]" is false,
>
> 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.

not recently... rules has been there & active for many years.

not a NS listing either, it's a NS' IP which is listed.
As SBL is about IPs it shouldn't be hard.. but then
We'll look at changing this in compliance to the age of 160chars ;)


We also have

if (version >= 3.004000)
   ifplugin Mail::SpamAssassin::Plugin::URIDNSBL

     uridnsbl        URIBL_SBL_A    sbl.spamhaus.org.   A
     body            URIBL_SBL_A    eval:check_uridnsbl('URIBL_SBL_A')
     describe        URIBL_SBL_A    Contains URL's A record listed in 
the SBL blocklist
     tflags          URIBL_SBL_A    net a
   endif
endif

which states it clearly




> I personally feel it is a good thing, since the result is a positive
> one, but yes, the annotation in SA should be adjusted to indicate
> this aspect of the DNSBLs listings.
>
>
> On Oct 17, 2013, at 5:00 AM, Tom Hendrikx <to...@whyscream.net> wrote:
>
>> We had this too for one of our customers. Your problem is that one
>> of the nameservers of the domain is listed:
>>
>> http://www.spamhaus.org/query/ip/151.1.141.150
>>
>> I'm not really sure whether it's a feature or a bug that the
>> rule/plugin goes that deep while searching for possible wrongdoing
>> ip addresses...
>
>


Re: Strange URIBL_SBL false positive?

Posted by Neil Schwartzman <ne...@cauce.org>.

On Oct 17, 2013, at 6:49 AM, Tom Hendrikx <to...@whyscream.net> wrote:

> 
> Basicly the description "Contains an URL listed in the SBL blocklist
> [URIs: example.com]" is false,

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.

I personally feel it is a good thing, since the result is a positive one, but yes, the annotation in SA should be adjusted to indicate this aspect of the DNSBLs listings.


On Oct 17, 2013, at 5:00 AM, Tom Hendrikx <to...@whyscream.net> wrote:

> We had this too for one of our customers. Your problem is that one of
> the nameservers of the domain is listed:
> 
> http://www.spamhaus.org/query/ip/151.1.141.150
> 
> I'm not really sure whether it's a feature or a bug that the rule/plugin
> goes that deep while searching for possible wrongdoing ip addresses...


Re: Strange URIBL_SBL false positive?

Posted by Tom Hendrikx <to...@whyscream.net>.
On 10/17/2013 02:08 PM, Axb wrote:
> On 10/17/2013 02:00 PM, Tom Hendrikx wrote:
>> On 10/17/2013 12:25 PM, Marco wrote:
>>> Hello,
>>>
>>>   If I submit this to Spamassassin 3.3.2:
>>>
>>>    <div><b>Da:</b> &lt;<a
>>> href="mailto:ziopino@errebian.it">ziopino@errebian.it</a>&gt;<br>;
>>>     <b>Cc:</b> Alice &lt;<a
>>> href="mailto:alice@errebian.it">alice@errebian.it</a>&gt;,
>>>     Bob &lt;<a
>>> href="mailto:bob@errebian.it">bob@errebian.it</a>&gt;<br>;
>>>
>>> I see:
>>>
>>>   7.0 URIBL_SBL              Contains an URL listed in the SBL blocklist
>>>                              [URIs: errebian.it]
>>>
>>> ...but errebian.it IPs are not in SBL..!
>>>
>>> Could you help me to understand?
>>> Thank you very much!!
>>>
>>> Marco
>>>
>>
>> We had this too for one of our customers. Your problem is that one of
>> the nameservers of the domain is listed:
>>
>> http://www.spamhaus.org/query/ip/151.1.141.150
>>
>> I'm not really sure whether it's a feature or a bug that the rule/plugin
>> goes that deep while searching for possible wrongdoing ip addresses...
> 
> Why would this be a bug? The rule performs as expected.
> the original score is low enough not to push it over the top on its
> own.. and if you have your domain on a dirty NS or A  IP neighbourhood,
> you may want to move to a more adequate gate community :)

Basicly the description "Contains an URL listed in the SBL blocklist
[URIs: example.com]" is false, since the domain or any of the ip
addresses linked directly to it aren't listed.

Maybe it would be nice have a split between 'direct' hits (A/AAAA record
of hostname) and 'secondaries' (ip addresses extracted from DNS
'metadata' such as MX or NS records), so the rule description can be
more informative.

First time when I ran into this, we spent quite some time on finding
which ip was actually listed, and what relation it had to the customer
domain.

> 
> the unreal score this person is using "7.0 URIBL_SBL"
> means he's screaming for trouble

Totally agree.



Re: Strange URIBL_SBL false positive?

Posted by Axb <ax...@gmail.com>.
On 10/17/2013 02:00 PM, Tom Hendrikx wrote:
> On 10/17/2013 12:25 PM, Marco wrote:
>> Hello,
>>
>>   If I submit this to Spamassassin 3.3.2:
>>
>>    <div><b>Da:</b> &lt;<a
>> href="mailto:ziopino@errebian.it">ziopino@errebian.it</a>&gt;<br>;
>>     <b>Cc:</b> Alice &lt;<a
>> href="mailto:alice@errebian.it">alice@errebian.it</a>&gt;,
>>     Bob &lt;<a href="mailto:bob@errebian.it">bob@errebian.it</a>&gt;<br>;
>>
>> I see:
>>
>>   7.0 URIBL_SBL              Contains an URL listed in the SBL blocklist
>>                              [URIs: errebian.it]
>>
>> ...but errebian.it IPs are not in SBL..!
>>
>> Could you help me to understand?
>> Thank you very much!!
>>
>> Marco
>>
>
> We had this too for one of our customers. Your problem is that one of
> the nameservers of the domain is listed:
>
> http://www.spamhaus.org/query/ip/151.1.141.150
>
> I'm not really sure whether it's a feature or a bug that the rule/plugin
> goes that deep while searching for possible wrongdoing ip addresses...

Why would this be a bug? The rule performs as expected.
the original score is low enough not to push it over the top on its 
own.. and if you have your domain on a dirty NS or A  IP neighbourhood, 
you may want to move to a more adequate gate community :)

the unreal score this person is using "7.0 URIBL_SBL"
means he's screaming for trouble

definitely NOT an FP

Re: Strange URIBL_SBL false positive?

Posted by Tom Hendrikx <to...@whyscream.net>.
On 10/17/2013 12:25 PM, Marco wrote:
> Hello,
> 
>  If I submit this to Spamassassin 3.3.2:
> 
>   <div><b>Da:</b> &lt;<a
> href="mailto:ziopino@errebian.it">ziopino@errebian.it</a>&gt;<br>;
>    <b>Cc:</b> Alice &lt;<a
> href="mailto:alice@errebian.it">alice@errebian.it</a>&gt;,
>    Bob &lt;<a href="mailto:bob@errebian.it">bob@errebian.it</a>&gt;<br>;
> 
> I see:
> 
>  7.0 URIBL_SBL              Contains an URL listed in the SBL blocklist
>                             [URIs: errebian.it]
> 
> ...but errebian.it IPs are not in SBL..!
> 
> Could you help me to understand?
> Thank you very much!!
> 
> Marco
> 

We had this too for one of our customers. Your problem is that one of
the nameservers of the domain is listed:

http://www.spamhaus.org/query/ip/151.1.141.150

I'm not really sure whether it's a feature or a bug that the rule/plugin
goes that deep while searching for possible wrongdoing ip addresses...

Regards,
	Tom