You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@spamassassin.apache.org by Justin Mason <jm...@jmason.org> on 2004/11/01 18:52:34 UTC

Re: trusted_networks and ALL_TRUSTED

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Sean Doherty writes:
> I'm looking for some clarification on trusted_networks, the 
> ALL_TRUSTED rule, and in particular how trusted_networks are 
> inferred if not specified in local.cf.
> 
> Since upgrading to 3.0.1 I have seen an increase in false
> negatives, which would have otherwise been caught if not for
> the ALL_TRUSTED rule firing.
> 
> I don't have trusted_networks set in local.cf, so SpamAssassin
> will use the inference algorithm as specified in the docs:
> 
> - if the 'from' IP address is on the same /16 network as the top
>   Received line's 'by' host, it's trusted 
> - if the address of the 'from' host is in a reserved network range, 
>   then it's trusted 
> - if any addresses of the 'by' host is in a reserved network range, 
>   then it's trusted
> 
> My postfix mail server, that runs SpamAssasin is in a reserved
> network range (10.0.0.53) and processes only incoming mail. The
> following msg snippet (Received headers) results in the ALL_TRUSTED 
> rule firing:
> 
> Received: from 206.81.84.119 (unknown [206.81.84.119]) by
> marvin.copperfasten.com (Postfix) with SMTP id 127ACEBC7F for
> <xx...@copperfasten.com>; Mon,  1 Nov 2004 11:09:24 +0000 (GMT)
> Received: from 206.81.84.119 by mail003.datapropo.com; Mon, 01 Nov 2004
> 16:02:51 +0500
> 
> With trusted_networks unset I get the following with I debug
> the msg with Spamassassin:
> 
> debug: looking up PTR record for '206.81.84.119'
> debug: PTR for '206.81.84.119': '206-81-84-119.info-goals.com'
> debug: received-header: parsed as [ ip=206.81.84.119
> rdns=206-81-84-119.info-goals.com helo=206.81.84.119
> by=marvin.copperfasten.com ident= envfrom= intl=0 id=127ACEBC7F ]
> debug: looking up A records for 'marvin.copperfasten.com'
> debug: A records for 'marvin.copperfasten.com': 10.0.0.53
> debug: looking up A records for 'marvin.copperfasten.com'
> debug: A records for 'marvin.copperfasten.com': 10.0.0.53
> debug: received-header: 'by' marvin.copperfasten.com has reserved IP
> 10.0.0.53
> debug: received-header: 'by' marvin.copperfasten.com has no public IPs
> debug: received-header: relay 206.81.84.119 trusted? yes internal? no
> 
> I'm assuming that 206.81.84.119 is trusted since the following
> condition of the inference algorithm fires:
> 
> - if any addresses of the 'by' host is in a reserved network range, 
>   then it's trusted
> 
> However, I would have thought that this would imply that the 10.0.0.53
> host is trusted and not any servers connecting to it. 

The problem is that 10.x is a private net, therefore SpamAssassin infers
it cannot possibly be the external MX sitting out there on the internet.
(for a host to be sitting on the public internet accepting SMTP
connections, it'd obviously need a public IP addr.)

so the *next* step must be the external MX.

> Can someone please clarify this for me? Also should I be specifying
> 10.0.0.53 in trusted_networks in local.cf?

Yep, that's right -- and trusted_networks will fix it.

- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFBhnfiMJF5cimLx9ARAtXlAJ9oN9SVWC4dC8FE2dKP/IEIORdDUgCeJ/GY
DjAorX+fCBwLoq0HMcgYr4g=
=WyEy
-----END PGP SIGNATURE-----

Re: trusted_networks and ALL_TRUSTED

Posted by Jim Maul <jm...@elih.org>.

Sean Doherty wrote:
> Justin,
> 
> 
>>>- if any addresses of the 'by' host is in a reserved network range, 
>>>  then it's trusted
>>>
>>>However, I would have thought that this would imply that the 10.0.0.53
>>>host is trusted and not any servers connecting to it. 
>>
>>The problem is that 10.x is a private net, therefore SpamAssassin infers
>>it cannot possibly be the external MX sitting out there on the internet.
>>(for a host to be sitting on the public internet accepting SMTP
>>connections, it'd obviously need a public IP addr.)
>>
>>so the *next* step must be the external MX.
> 
> 
> My 10.x server is inside a firewall which NATs port 25 so this
> conclusion is not correct. I imagine that my setup isn't all 
> that different from a lot of other peoples. 
> 
> 

This is exactly how i have my system setup.  I have a 192.168 IP 
assigned to my server.  It has no public IP assigned to it.  However, i 
have a router/firewall in front of it which has a public ip assigned to 
its wan interface which then does NAT/port forwarding to my qmail 
server.  It works extremely well for our purposes.  It sounds to me that 
if i upgraded to 3.0 (still running 2.64) i would then have the same 
issue with the trusted networks.  It doesnt really sound correct.  Just 
because my machine doesnt have a public ip does NOT mean that mail 
passes through a trusted source first..unless you are calling my little 
SMC barricade a trusted source.

-Jim

Re: AWL and ABL Re: trusted_networks and ALL_TRUSTED

Posted by George Georgalis <ge...@galis.org>.

On Tue, Nov 02, 2004 at 09:46:55AM -0800, Justin Mason wrote:
>George Georgalis writes:
>> On Tue, Nov 02, 2004 at 01:03:02PM +0000, Sean Doherty wrote:
>> >On Tue, 2004-11-02 at 12:50, George Georgalis wrote: 
>> >> >Do you mean -0.001? Why would you want to penalise mail
>> >> >coming thru a trusted path?
>> >> 
>> >> It really doesn't matter to me what the score is, I just want to disable
>> >> the test.
>> >> http://bugzilla.spamassassin.org/show_bug.cgi?id=3406
>> >> 
>> >> My /etc/spamassassin is the reference I replicate out to my other
>> >> systems, and systems of my clients, which may or may not be on nat and
>> >> certainly are on different networks.
>> >> 
>> >> The setup I use routes mail at the tcp level, it's basically impossible
>> >> for a message to reach spam assassin if it's from a trusted network.
>> >So why not set trusted_networks to 127.0.0.1. That way you can
>> >be certain that the rule will never fire. You'll also get the
>> >benefit of the DNS blocklists been checked for the addresses in
>> >the Received headers - with your current setup, its possible 
>> >that some of these will be marked as trusted, and as such you'll
>> >lose the benefit of the RBL check.
>> 
>> There is lots of reasons not to do something. What I'm not seeing
>> is a reason why I can't stop trusted_networks from using cpu/dns.
>> 
>> your idea sounds okay for some applications (and I'm changing from
>> 192.168 to 127.0.0.1 as a matter of course), but I don't want every
>> address in headers looked up. I don't want any of them looked up.
>> I hope it's okay for me to be that way.
>
>Use -L.

I had until I recently integrated SURBL, which is not compatable with -L.

// George

-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:george@galis.org

Re: AWL and ABL Re: trusted_networks and ALL_TRUSTED

Posted by George Georgalis <ge...@galis.org>.

On Tue, Nov 02, 2004 at 03:40:02PM +0000, Sean Doherty wrote:
>On Tue, 2004-11-02 at 15:16, George Georgalis wrote:
>
>> >> The setup I use routes mail at the tcp level, it's basically impossible
>> >> for a message to reach spam assassin if it's from a trusted network.
>
>> >So why not set trusted_networks to 127.0.0.1. That way you can
>> >be certain that the rule will never fire. You'll also get the
>> >benefit of the DNS blocklists been checked for the addresses in
>> >the Received headers - with your current setup, its possible 
>> >that some of these will be marked as trusted, and as such you'll
>> >lose the benefit of the RBL check.
>> 
>> There is lots of reasons not to do something. What I'm not seeing
>> is a reason why I can't stop trusted_networks from using cpu/dns.
>
>> your idea sounds okay for some applications (and I'm changing from
>> 192.168 to 127.0.0.1 as a matter of course), but I don't want every
>> address in headers looked up. I don't want any of them looked up.
>> I hope it's okay for me to be that way.
>> 
>> I am concerned about the IP a message is coming from, but in my setup,
>> that is dealt with before SA ever sees the message.
>
>You can stop dns lookups by setting "dns_available no" which 
>results in the following if trusted_networks is unset.
>
>debug: received-header: cannot use DNS, do not trust any hosts from here
>on
>
>However, this also disables SURBLs - which you probably still want!
>I don't think its possible to disable DNS lookups for trusted networks
>without also disabling it for the SURBLs.

Thanks, indeed I do use SURBLs. and am quite pleased with those!

// George


-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:george@galis.org

Re: AWL and ABL Re: trusted_networks and ALL_TRUSTED

Posted by Sean Doherty <se...@copperfasten.com>.

On Tue, 2004-11-02 at 15:16, George Georgalis wrote:

> >> The setup I use routes mail at the tcp level, it's basically impossible
> >> for a message to reach spam assassin if it's from a trusted network.

> >So why not set trusted_networks to 127.0.0.1. That way you can
> >be certain that the rule will never fire. You'll also get the
> >benefit of the DNS blocklists been checked for the addresses in
> >the Received headers - with your current setup, its possible 
> >that some of these will be marked as trusted, and as such you'll
> >lose the benefit of the RBL check.
> 
> There is lots of reasons not to do something. What I'm not seeing
> is a reason why I can't stop trusted_networks from using cpu/dns.

> your idea sounds okay for some applications (and I'm changing from
> 192.168 to 127.0.0.1 as a matter of course), but I don't want every
> address in headers looked up. I don't want any of them looked up.
> I hope it's okay for me to be that way.
> 
> I am concerned about the IP a message is coming from, but in my setup,
> that is dealt with before SA ever sees the message.

You can stop dns lookups by setting "dns_available no" which 
results in the following if trusted_networks is unset.

debug: received-header: cannot use DNS, do not trust any hosts from here
on

However, this also disables SURBLs - which you probably still want!
I don't think its possible to disable DNS lookups for trusted networks
without also disabling it for the SURBLs.

		- Sean

Re: AWL and ABL Re: trusted_networks and ALL_TRUSTED

Posted by George Georgalis <ge...@galis.org>.

On Tue, Nov 02, 2004 at 01:03:02PM +0000, Sean Doherty wrote:
>On Tue, 2004-11-02 at 12:50, George Georgalis wrote: 
>> >Do you mean -0.001? Why would you want to penalise mail
>> >coming thru a trusted path?
>> 
>> It really doesn't matter to me what the score is, I just want to disable
>> the test.
>> http://bugzilla.spamassassin.org/show_bug.cgi?id=3406
>> 
>> My /etc/spamassassin is the reference I replicate out to my other
>> systems, and systems of my clients, which may or may not be on nat and
>> certainly are on different networks.
>> 
>> The setup I use routes mail at the tcp level, it's basically impossible
>> for a message to reach spam assassin if it's from a trusted network.
>So why not set trusted_networks to 127.0.0.1. That way you can
>be certain that the rule will never fire. You'll also get the
>benefit of the DNS blocklists been checked for the addresses in
>the Received headers - with your current setup, its possible 
>that some of these will be marked as trusted, and as such you'll
>lose the benefit of the RBL check.

There is lots of reasons not to do something. What I'm not seeing
is a reason why I can't stop trusted_networks from using cpu/dns.

your idea sounds okay for some applications (and I'm changing from
192.168 to 127.0.0.1 as a matter of course), but I don't want every
address in headers looked up. I don't want any of them looked up.
I hope it's okay for me to be that way.

I am concerned about the IP a message is coming from, but in my setup,
that is dealt with before SA ever sees the message.

// George

-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:george@galis.org

Re: AWL and ABL Re: trusted_networks and ALL_TRUSTED

Posted by Sean Doherty <se...@copperfasten.com>.

On Tue, 2004-11-02 at 12:50, George Georgalis wrote: 
> >Do you mean -0.001? Why would you want to penalise mail
> >coming thru a trusted path?
> 
> It really doesn't matter to me what the score is, I just want to disable
> the test.
> http://bugzilla.spamassassin.org/show_bug.cgi?id=3406
> 
> My /etc/spamassassin is the reference I replicate out to my other
> systems, and systems of my clients, which may or may not be on nat and
> certainly are on different networks.
> 
> The setup I use routes mail at the tcp level, it's basically impossible
> for a message to reach spam assassin if it's from a trusted network.
So why not set trusted_networks to 127.0.0.1. That way you can
be certain that the rule will never fire. You'll also get the
benefit of the DNS blocklists been checked for the addresses in
the Received headers - with your current setup, its possible 
that some of these will be marked as trusted, and as such you'll
lose the benefit of the RBL check.

> I had scored ALL_TRUSTED to 0 but then decided I needed to know in
> test reports what was happening. I don't know how much cpu this test
> uses, but I'd like it to go away completely, or at have the option of
> disabling it.
> 
> // George

Re: AWL and ABL Re: trusted_networks and ALL_TRUSTED

Posted by George Georgalis <ge...@galis.org>.

On Tue, Nov 02, 2004 at 10:24:57AM +0000, Sean Doherty wrote:
>On Mon, 2004-11-01 at 20:37, George Georgalis wrote:
>
>> skip_rbl_checks 1
>> use_bayes 0
>> 
>> noautolearn 1
>> use_auto_whitelist 0
>> score AWL 0.001
>> 
>> trusted_networks 192.168.
>> score ALL_TRUSTED 0.001
>
>Do you mean -0.001? Why would you want to penalise mail
>coming thru a trusted path?

It really doesn't matter to me what the score is, I just want to disable
the test.

http://bugzilla.spamassassin.org/show_bug.cgi?id=3406

My /etc/spamassassin is the reference I replicate out to my other
systems, and systems of my clients, which may or may not be on nat and
certainly are on different networks.

The setup I use routes mail at the tcp level, it's basically impossible
for a message to reach spam assassin if it's from a trusted network.

I had scored ALL_TRUSTED to 0 but then decided I needed to know in
test reports what was happening. I don't know how much cpu this test
uses, but I'd like it to go away completely, or at have the option of
disabling it.

// George

-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:george@galis.org

Re: AWL and ABL Re: trusted_networks and ALL_TRUSTED

Posted by Sean Doherty <se...@copperfasten.com>.

On Mon, 2004-11-01 at 20:37, George Georgalis wrote:

> skip_rbl_checks 1
> use_bayes 0
> 
> noautolearn 1
> use_auto_whitelist 0
> score AWL 0.001
> 
> trusted_networks 192.168.
> score ALL_TRUSTED 0.001

Do you mean -0.001? Why would you want to penalise mail
coming thru a trusted path?

		- Sean

Re: AWL and ABL (use of score AWL statements)

Posted by Matt Kettler <mk...@evi-inc.com>.

At 03:37 PM 11/1/2004, George Georgalis wrote:
>Thanks, I've added that:
>
>skip_rbl_checks 1
>use_bayes 0
>
>noautolearn 1
>use_auto_whitelist 0
>score AWL 0.001

I've seen lots of people using the score statement on AWL. However, I 
myself have serious doubts about the validity of doing that. The AWL 
doesn't normally have a score statement, because it's a no-rule system 
implemented entirely in the code.

Any devs who might know for sure care to comment?

Re: AWL and ABL Re: trusted_networks and ALL_TRUSTED

Posted by George Georgalis <ge...@galis.org>.

On Mon, Nov 01, 2004 at 03:13:50PM -0500, Matt Kettler wrote:
>At 02:11 PM 11/1/2004, George Georgalis wrote:
>>those false negatives are also growing an AWL, which I also don't want.
>>
>>-1.4 AWL                    AWL: From: address is in the auto white-list
>>
>>how do I disable and purge any AWL and ABL generation, too?
>
>Well, there is no "ABL" just one system called AWL which works as both 
>white and black.
>
>Disable it with:
>        use_auto_whitelist 0
>
>You can purge it by removing the database files with rm -f. They should be 
>in ~/.spamassassin/. Be sure SA isn't running when you delete them.

Thanks, I've added that:

skip_rbl_checks 1
use_bayes 0

noautolearn 1
use_auto_whitelist 0
score AWL 0.001

trusted_networks 192.168.
score ALL_TRUSTED 0.001


// George


-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:george@galis.org

Re: AWL and ABL Re: trusted_networks and ALL_TRUSTED

Posted by Matt Kettler <mk...@evi-inc.com>.

At 02:11 PM 11/1/2004, George Georgalis wrote:
>those false negatives are also growing an AWL, which I also don't want.
>
>-1.4 AWL                    AWL: From: address is in the auto white-list
>
>how do I disable and purge any AWL and ABL generation, too?

Well, there is no "ABL" just one system called AWL which works as both 
white and black.

Disable it with:
         use_auto_whitelist 0

You can purge it by removing the database files with rm -f. They should be 
in ~/.spamassassin/. Be sure SA isn't running when you delete them.

AWL and ABL Re: trusted_networks and ALL_TRUSTED

Posted by George Georgalis <ge...@galis.org>.

On Mon, Nov 01, 2004 at 02:03:36PM -0500, George Georgalis wrote:

>In any event, how is it disabled? I'm getting false negatives...
>
>-2.8 ALL_TRUSTED            Did not pass through any untrusted hosts
>
>In my setup SA doesn't get _any_ trusted network connections, those
>connections are routed beforehand, so my quick fix is to "score
>ALL_TRUSTED 0"

those false negatives are also growing an AWL, which I also don't want.

-1.4 AWL                    AWL: From: address is in the auto white-list

how do I disable and purge any AWL and ABL generation, too?

// George


-- 
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:george@galis.org