another trusted network question

[John Goubeaux <go...@education.ucsb.edu>]

Ok so I am a little confused on the "trusted networks" concept. Here is 
my setup, or at least what I would like to accomplish:

MTA 128.111.24.40 ( which I trust)  relays some mail to my MTA that is 
running SA, I want my network tests to be run on the hosts that send to 
it in all cases, and NOT run any of the tests on it.

How do I accomplish this?  do I do it using the  trusted network line in 
my .cf file or do  I need to also use -firsttrusted individually for the 
DNSBL tests?

This should be a pretty simple case but I cannot seem to get SA to 
always run the network tests on the hop right before 128.111.24.40


Thanks !

-john

-- 
John Goubeaux
Systems Administrator
Gevirtz Graduate School of Education
UC Santa Barbara
Phelps Hall 3534
805 893-8190

Re: another trusted network question

[Matt Kettler <mk...@verizon.net>]

John Goubeaux wrote:
> Ok so I am a little confused on the "trusted networks" concept. Here
> is my setup, or at least what I would like to accomplish:
>
> MTA 128.111.24.40 ( which I trust)  relays some mail to my MTA that is
> running SA, I want my network tests to be run on the hosts that send
> to it in all cases, and NOT run any of the tests on it.
>
> How do I accomplish this?  do I do it using the  trusted network line
> in my .cf file 
Yes.. and if you decalare an internal_networks, be sure it's in
internal_networks too.. (most folks just declare trusted_networks, in
which case SA uses the same value for both).
> or do  I need to also use -firsttrusted individually for the DNSBL tests?
No. As long as it's trusted and internal, it won't be checked. And, the
DUL checks will apply against the hosts that deliver mail to 128.111.24.40.

>
> This should be a pretty simple case but I cannot seem to get SA to
> always run the network tests on the hop right before 128.111.24.40
>
>
> Thanks !
>
> -john
>

Re: another trusted network question

[John Goubeaux <go...@education.ucsb.edu>]

Ok,

So the debug output indicates that the host, in this case 85.176.21.159  
is not trusted nor internal would this (given my network tests do run 
properly and are configured) mean that it should be run against my 
tests? In this case it is not. Meaning I know the ip 85.176.21.159 to be 
in an RBL db test that I have running.



[5035] dbg: received-header: 'from' 128.111.24.40 is near to first 'by'
[5035] dbg: received-header: relay 128.111.24.40 trusted? yes internal? no
[5035] dbg: dns: looking up PTR record for '85.176.21.159'
[5035] dbg: dns: PTR for '85.176.21.159': 'e176021159.adsl.alicedsl.de'
[5035] dbg: received-header: parsed as [ ip=85.176.21.159 
rdns=e176021159.adsl.alicedsl.de helo=e176021159.adsl.alicedsl.de 
by=ucsb.edu ident= envfrom= intl=0 id=1GaKFK-0001ps-3Z auth= ]
[5035] dbg: dns: looking up A records for 'ucsb.edu'
[5035] dbg: dns: A records for 'ucsb.edu': 128.111.24.40
[5035] dbg: received-header: 'by' ucsb.edu has public IP 128.111.24.40
[5035] dbg: received-header: relay 85.176.21.159 trusted? no internal? no

Bob Proulx wrote:
> John Goubeaux wrote:
>   
>> This should be a pretty simple case but I cannot seem to get SA to 
>> always run the network tests on the hop right before 128.111.24.40
>>     
>
> Run SA in debug mode and trace through the output.
>
>   | spamassassin -tD 2>&1 | less +/relay
>
> You should see lines along the form of:
>
>   [21227] dbg: received-header: relay 192.168.1.3 trusted? yes internal? yes
>   [21227] dbg: received-header: relay 87.126.193.139 trusted? no internal? no
>
> You should be able to tell if it is configured properly or not.
>
> Bob
>   

-- 
John Goubeaux
Systems Administrator
Gevirtz Graduate School of Education
UC Santa Barbara
Phelps Hall 3534
805 893-8190

Re: another trusted network question

[Bob Proulx <bo...@proulx.com>]

John Goubeaux wrote:
> This should be a pretty simple case but I cannot seem to get SA to 
> always run the network tests on the hop right before 128.111.24.40

Run SA in debug mode and trace through the output.

  | spamassassin -tD 2>&1 | less +/relay

You should see lines along the form of:

  [21227] dbg: received-header: relay 192.168.1.3 trusted? yes internal? yes
  [21227] dbg: received-header: relay 87.126.193.139 trusted? no internal? no

You should be able to tell if it is configured properly or not.

Bob