Strange URIBL_SBL false positive?

[Marco]

Hello,

 If I submit this to Spamassassin 3.3.2:

  Da: ziop...@errebian.it>;
   Cc: Alice al...@errebian.it>,
   Bob b...@errebian.it>;

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?

[Axb]

On 10/17/2013 12:25 PM, Marco wrote:

Hello,

  If I submit this to Spamassassin 3.3.2:

   Da: ziop...@errebian.it>;
Cc: Alice al...@errebian.it>,
Bob b...@errebian.it>;

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?

[Tom Hendrikx]

On 10/17/2013 12:25 PM, Marco wrote:
> Hello,
> 
>  If I submit this to Spamassassin 3.3.2:
> 
>   Da: < href="mailto:ziop...@errebian.it";>ziop...@errebian.it>;
>Cc: Alice < href="mailto:al...@errebian.it";>al...@errebian.it>,
>Bob b...@errebian.it>;
> 
> 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



signature.asc
Description: OpenPGP digital signature

Re: Strange URIBL_SBL false positive?

[Axb]

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:

   Da: ziop...@errebian.it>;
Cc: Alice al...@errebian.it>,
Bob b...@errebian.it>;

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?

[Marco]

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?

[Tom Hendrikx]

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:
>>>
>>>Da: <>> href="mailto:ziop...@errebian.it";>ziop...@errebian.it>;
>>> Cc: Alice <>> href="mailto:al...@errebian.it";>al...@errebian.it>,
>>> Bob <>> href="mailto:b...@errebian.it";>b...@errebian.it>;
>>>
>>> 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/ 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.




signature.asc
Description: OpenPGP digital signature

Re: Strange URIBL_SBL false positive?

[Axb]

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?

[Neil Schwartzman]

On Oct 17, 2013, at 6:49 AM, Tom Hendrikx  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  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?

[Axb]

On 10/17/2013 04:01 PM, Neil Schwartzman wrote:



On Oct 17, 2013, at 6:49 AM, Tom Hendrikx  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

uridnsblURIBL_SBL_Asbl.spamhaus.org.   A
bodyURIBL_SBL_Aeval:check_uridnsbl('URIBL_SBL_A')
describeURIBL_SBL_AContains URL's A record listed in 
the SBL blocklist

tflags  URIBL_SBL_Anet 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  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?

[Axb]

FTR:

describeURIBL_SBLContains 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?

[Kai Schaetzl]

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?

[Axb]

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: FSL_HELO_BARE_IP_2 & RCVD_NUMERIC_HELO

[Stan Hoeppner]

On 10/16/2013 3:01 AM, Jonas Eckerman wrote:
>> Operators of newsgroups which mirror/archive mailing
>> lists, and allow posting from a web interface, are adding forged
>> Received: headers before sending an email to the respective list
>> server.
> 
> In what way are they forged?

I'm to this list.  Before I waste my time replying to what seems to be
trolling, or pedantry, I'd like to know.  I laid out the case with all
the evidence, half of which you cut in your reply.

Do you honestly not get it, or are you being a troll or pedant?  If the
former, I'll politely attempt to explain it so you can understand it.
Or, if you simply re-read my msg maybe it will become clear.

Regards.

-- 
Stan

Re: Strange URIBL_SBL false positive?

[Stan Hoeppner]

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?

[Axb]

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: Email in Russian not triggering UNWANTED_LANGUAGE_BODY

[John Hardin]

On Thu, 17 Oct 2013, Mauricio Tavares wrote:


On Wed, Oct 16, 2013 at 1:44 PM, John Hardin  wrote:

On Wed, 16 Oct 2013, Mauricio Tavares wrote:


)  Email in question is at http://pastie.org/8403863; I put it
there so it would not harm anyone with its HTTP-Posting-URI header.

In my local.cf I have

ok_languages en
ok_locales en
add_header all Languages _LANGUAGES_

And have textcat enabled. Many emails, most recently in Chinese and
Spanish, have been flagged. But the one mentioned above did not
trigger the language check. How come?



Perhaps:
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6364


 Quite possibly. Reading
http://www.mail-archive.com/spamassassin-talk@lists.sourceforge.net/msg23962.html
I was wondering where those .lm files are (vi.lm, en.lm, etc). I could
not find them in the ubuntu box I have spamassassin installed on.


That I don't know, apart from assuming they're somewhere under the SA 
install directory since they're being shipped as part of a SA plugin.


Please keep responses on-list so that others can help and can benefit from 
a solution to this problem.


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  Mine eyes have seen the horror of the voting of the horde;
  They've looted the fromagerie where guv'ment cheese is stored;
  If war's not won before the break they grow so quickly bored;
  Their vote counts as much as yours.  -- Tam
---
 504 days since the first successful private support mission to ISS (SpaceX)

Re: Strange URIBL_SBL false positive?

[Kai Schaetzl]

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?

[Stan Hoeppner]

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_SBLzen.spamhaus.org.   A   127.0.0.2
bodyURIBL_SBLeval:check_uridnsbl('URIBL_SBL')
describeURIBL_SBLContains an URL's NS IP listed in the
SBL blocklist
tflags  URIBL_SBLnet
reuse   URIBL_SBL

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

uridnsblURIBL_SBL_Asbl.spamhaus.org.   A
bodyURIBL_SBL_Aeval:check_uridnsbl('URIBL_SBL_A')
describeURIBL_SBL_AContains URL's A record listed in the
SBL blocklist
tflags  URIBL_SBL_Anet 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?

[Axb]

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?

[Axb]

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_SBLzen.spamhaus.org.   A   127.0.0.2
bodyURIBL_SBLeval:check_uridnsbl('URIBL_SBL')
describeURIBL_SBLContains an URL's NS IP listed in the
SBL blocklist
tflags  URIBL_SBLnet
reuse   URIBL_SBL

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

 uridnsblURIBL_SBL_Asbl.spamhaus.org.   A
 bodyURIBL_SBL_Aeval:check_uridnsbl('URIBL_SBL_A')
 describeURIBL_SBL_AContains URL's A record listed in the
SBL blocklist
 tflags  URIBL_SBL_Anet 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: Email in Russian not triggering UNWANTED_LANGUAGE_BODY

[Karsten Bräckelmann]

On Thu, 2013-10-17 at 09:13 -0700, John Hardin wrote:
> On Thu, 17 Oct 2013, Mauricio Tavares wrote:

> > Reading
> > http://www.mail-archive.com/spamassassin-talk@lists.sourceforge.net/msg23962.html
> > I was wondering where those .lm files are (vi.lm, en.lm, etc). I could
> > not find them in the ubuntu box I have spamassassin installed on.

They are in the SA sources lm/ directory and (mostly) taken directly
from the original TextCat program.

> That I don't know, apart from assuming they're somewhere under the SA 
> install directory since they're being shipped as part of a SA plugin.

They aren't. The 'languages' file generated from these *.lm files is
shipped with SA. The source files are only needed for modification of
existing or adding of new languages -- which is what the above archive
link is about.


-- 
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

Re: FSL_HELO_BARE_IP_2 & RCVD_NUMERIC_HELO

[Stan Hoeppner]

On 10/17/2013 2:09 PM, Jonas Eckerman wrote:
> I answer privately since this really isn't about SpamAssassin any more, and 
> SpamAssassin isn't about RFC conformance.

Oh, but it does directly relate to the above two rules.  And I believe
this is a healthy discussion.  It will educate others as to exactly why
these rules break when analyzing some list mail, lists which are the
backbone of the FLOSS community.  Before now the maintainers were making
decisions about applying these rules to list mail based solely on
statistics.  This discussion has fleshed out the 'why'.  The resulting
knowledge may be helpful in writing better, more intelligent rules in
the future.  So I hope it's ok with you that I'm copying this back to
the list.

>>> In what way are they forged?
> 
>> Do you honestly not get it, or are you being a troll or pedant?
> 
> I honestly didn't get it, and I'm not a troll. Whether I'm a pedant or not 
> would be a matter of opinion (where you're free to hold one different from 
> mine).

I hope I didn't sound accusatory here Jonas.  I've been around the
'interwebs' long enough to know that now and then people try to suck you
into an argument over minutia for the sake of arguing.  I thought there
was a chance that was the case here, so I simply asked.

>> Or, if you simply re-read my msg maybe it will become clear.
> 
> I've re-read the message. I can see that I might have quoted badly (I read 
> and replied with my mobile phone, which I know think was a bad idea), and I 
> apologize for that.

No problem.

> It still seems that you're saying the received headers are forged when they 
> were inserted for transfers not involving SMTP though, even if you also 
> pointed to other errors in the headers in question.

Only one that is claimed to be "esmtp" is forged.  That's the 2nd
header.  The first is not, as it clearly stated "local" injection.
That's the PHP end of it.

>> To create a record apparently in case of abuse, Gmane in particular injects
>> the rDNS string of the HTTP client machine into the EHLO position of a
>> Received: header, using the bare IP upon NXDOMAIN or SERVFAIL.
> 
> I see two problems with calling that a forgery:

Yeah, scratch that.  I painted with an overly broad brush in my first
post.  Only the 2nd header is the problem, the first is fine.

> 1: The idea of a EHLO position is only relevant for protocols with a EHLO 
> command. When the message is received using HTTP, NNTP, UUCP, local pipes, 
> etc, there is no EHLO command.

Of course.

> 2: The Received headers have not always been as strictly defined as one might 
> wish. 

Absolutely agreed.  Not all MTAs use the same Received: header format.
But I assume this was taken into account in these two tests.  I've not
actually looked at the regexes yet.

> Even now putting in the EHLO parameter is a SHOULD, not a MUST, for SMTP.

Thankfully most serious MTA writers treat these directives the same.

> On to the first set of received headers, I'm commenting the first (in 
> insertion order) two headers.
> 
>> Received: from stan by mo-65-41-216-221.sta.embarqhsd.net with local (Gmexim 
>> 0.1 (Debian))
>>  id 1AlnuQ-0007hv-00
>>  for ; Tue, 15 Oct 2013 09:40:02 +0200
> 
> Was mo-65-41-216-221.sta.embarqhsd.net your RDNS when posting that? If it was 
> I agree that this header is a forgery. If, oth, 
> mo-65-41-216-221.sta.embarqhsd.net really was the machine receiving a locally 
> submitted message (possibly from a PHP script) from "stan" (wich I'd guess is 
> a user name since that is common to put in that position for locally 
> submitted mesages), it seems just fine.

Yes.  This is my PC's FCrDNS.  This injection stamping is warranted, and
wanted by receivers, and is clearly stated as 'local' injection.  This
is a good thing, absolutely.

>> Received: from mo-65-41-216-221.sta.embarqhsd.net ([65.41.216.221])
>>  by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
>>  id 1AlnuQ-0007hv-00
>>  for ; Tue, 15 Oct 2013 09:40:02 +0200
> 
> If the previous header was correctly listing it's own address in the "by" 
> clause, this seems just fine. If the address, 
> mo-65-41-216-221.sta.embarqhsd.net, was actually your address, this header is 
> of course incorrect as well.

Yes, this is the one that is forged.  There was no ESMTP transaction
between 65.41.216.221, my PC, and main.gmane.org, as this header above
clearly states there was.  Maybe "fabricated" or "manufactured" is a
better word.  They're not pretending it to be something it is not, but
merely creating it out of thin air.

Whether Gmane is violating RFC or not isn't my concern.  What is my
concern is that the way they create these headers is breaking the two
rules in the subject line.  Apparently a fix is already in place to
prevent these two rules from being applied to list mail.  Now that the
exact nature of the problem is known, maybe the test can be modified to
work with some list mail, but not this particular 'flavor'.

> If mo-65-41-216-221.sta.embarqhsd.net was 

Re: FSL_HELO_BARE_IP_2 & RCVD_NUMERIC_HELO

[John Hardin]

On Thu, 17 Oct 2013, Stan Hoeppner wrote:


Whether Gmane is violating RFC or not isn't my concern.  What is my
concern is that the way they create these headers is breaking the two
rules in the subject line.  Apparently a fix is already in place to
prevent these two rules from being applied to list mail.


I only adjusted FSL_HELO_BARE_IP_2, I didn't take a look at 
RCVD_NUMERIC_HELO.


Now that the exact nature of the problem is known, maybe the test can be 
modified to work with some list mail, but not this particular 'flavor'.


That's a possibility. Having Received: exceptions for certain cases may be 
justified, but that has to be weighed against the possibility of a spammer 
forging a Received: header that allows the message to bypass an effective 
rule.


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  If the rock of doom requires a gentle nudge away from Gaia to
  prevent a very bad day for Earthlings, NASA won’t be riding to the
  rescue. These days, NASA does dodgy weather research and outreach
  programs, not stuff in actual space with rockets piloted by
  flinty-eyed men called Buzz.   -- Daily Bayonet
---
 504 days since the first successful private support mission to ISS (SpaceX)