RE: trusted_networks use

[Bowie Bailey]

From: NFN Smith [mailto:[EMAIL PROTECTED]
> 
> From the beginning of the thread, I noted that I was running 2.6x,
> but that may have gotten missed.

It was probably just overlooked as it is easy to forget which options
were supported on which versions.  I just didn't take into account
that the options to do what you want may not be available in your
version.  And then the version gets forgotten completely during the
ensuing conversation.

> I have one production server that's running 3.0.3, and I ran a
> couple of quick tests there, and things are behaving as I would
> expect in this area.
> 
> Thus, I upgraded the test server to 3.0.3 (yes, I know that 3.0.4
> and 3.1 are out, but I stuck with 3.0.3 for consistency).
> 
> It did take one more tweak to add trust to the originating IP
> address, in local.cf, but from there, an identical message is coming
> out being not tagged as spam, and ALL_TRUSTED is definitely showing
> up.
> 
> Thus, the real "one small thing" I was missing was in running a
> version that's consistent with supporting what I want to do.

Glad it's working for you now.

> At this point, I think I pretty much have the mechanics down.  From
> here, what's necessary is getting all my production servers updated
> to 3.0x, then getting the various combinations of acceptable return
> addresses matched with server names.
> 
> Many thanks to all, especially Bowie, who patiently walked me
> through this one.  I really appreciate it.

No problem.  I'm always glad to help out.

Bowie

Re: trusted_networks use

[NFN Smith]

Bowie Bailey wrote:

 > Good catch Alan, I hadn't noticed that.  I think you're right about

the ALL_TRUSTED rule -- and, based on the debug output, right about
the internal_networks rule as well.

My comments have been based on settings for 3.04.  I'm not sure if
your version wasn't mentioned before or if I just didn't catch it.  I
would suggest that you upgrade at least to 3.04 in order to get the
benefit of all the new changes.  You would probably want to upgrade
all the way to 3.1 since it has been out for a week or so now without
any major issues being reported.


That would definitely be an issue.

From the beginning of the thread, I noted that I was running 2.6x, but 
that may have gotten missed.


I have one production server that's running 3.0.3, and I ran a couple of 
quick tests there, and things are behaving as I would expect in this area.


Thus, I upgraded the test server to 3.0.3 (yes, I know that 3.0.4 and 
3.1 are out, but I stuck with 3.0.3 for consistency).


It did take one more tweak to add trust to the originating IP address, 
in local.cf, but from there, an identical message is coming out being 
not tagged as spam, and ALL_TRUSTED is definitely showing up.


Thus, the real "one small thing" I was missing was in running a version 
that's consistent with supporting what I want to do.


At this point, I think I pretty much have the mechanics down.  From 
here, what's necessary is getting all my production servers updated to 
3.0x, then getting the various combinations of acceptable return 
addresses matched with server names.


Many thanks to all, especially Bowie, who patiently walked me through 
this one.  I really appreciate it.


Smith

RE: trusted_networks use

[Bowie Bailey]

From: alan premselaar [mailto:[EMAIL PROTECTED]
> 
> NFN Smith wrote:
> > Thanks for the ongoing feedback
> > 
> > Bowie Bailey wrote:
> >>
> >> Also, you may want to save your email into a file and manually
> >> run it through SA to see what happens.  Just add '-t -D' to the
> >> option list
> > 
> > 
> > I did that, and found a couple of things.  I'm closer, but not there
yet.
> > 
> > In reading the debugging output, I realized that I was putting my work 
> > in /etc/mail/sa-mimedefang.cf, and all my other local config settings 
> > are in /etc/mail/spamassassin/local.cf.  When I moved this work to 
> > local.cf, debug showed me getting further.
> > 
> > I also found that Net::DNS wasn't installed -- up until now, I haven't 
> > needed it, because I haven't been doing stuff that requires DNS queries.

> >  I installed that, and am making further progress.
> > 
> > With the two changes, I'm getting correct designation of which hosts are

> > trusted or not (which I wasn't getting before), but still not getting 
> > the ALL_TRUSTED rule.
> > 
> > By the way, I've also made sure that the $HOME/.spamassassin/user_prefs 
> > doesn't have any user-specific settings that may be interfering.
> > 
> > Debug output shows:
> > 
> >> debug: using "/usr/share/spamassassin" for default rules dir
> >> debug: using "/etc/mail/spamassassin" for site rules dir
> >> debug: using "/home/test-user/.spamassassin" for user state dir
> >> debug: using "/home/test-user/.spamassassin/user_prefs" for user prefs 
> >> file
> >> debug: Failed to parse line in SpamAssassin configuration, skipping: 
> >> internal_networks 64.65.180.91
> >> debug: Failed to parse line in SpamAssassin configuration, skipping: 
> >> internal_networks 10.10.10.141
> >> debug: Score set 1 chosen.
> >> debug: Initialising learner
> >> debug: received-header: parsed as [ ip=68.99.120.79 
> >> rdns=lakecmmtao05.coxmail.com helo=lakecmmtao05.coxmail.com 
> >> by=pulsar.lfa.com ident= ]
> >> debug: received-header: parsed as [ ip=24.249.175.20 rdns=really 
> >> helo=!192.168.1.100! by=lakecmmtao05.coxmail.com ident= ]
> >> debug: received-header: relay 68.99.120.79 trusted? yes
> >> debug: received-header: relay 24.249.175.20 trusted? no
> >> debug: running header regexp tests; score so far=0
> >> debug: running body-text per-line regexp tests; score so far=0
> >> debug: running raw-body-text per-line regexp tests; score so far=5.733
> >> debug: running uri tests; score so far=6.536
> >> debug: uri tests: Done uriRE
> >> debug: running full-text regexp tests; score so far=6.573
> >> debug: Current PATH is: 
> >> /usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin
> >> debug: all '*From' addrs: [EMAIL PROTECTED]
> >> debug: all '*To' addrs: [EMAIL PROTECTED] [EMAIL PROTECTED]
> >> debug: is Net::DNS::Resolver available? yes
> >> debug: trying (3) kernel.org...
> >> debug: looking up MX for 'kernel.org'
> >> debug: MX for 'kernel.org' exists? 1
> >> debug: MX lookup of kernel.org succeeded => Dns available (set 
> >> dns_available to hardcode)
> >> debug: is DNS available? 1
> >> debug: DNS MX records found: 1
> >> debug: forged-HELO: from=really helo=!192.168.1.100! by=coxmail.com
> >> debug: running meta tests; score so far=6.573
> >> debug: is spam? score=7.673 required=4 
> >> tests=CLICK_BELOW,EXCUSE_3,FREE_CONSULTATION,MAILTO_TO_REMOVE,
> >>   MIME_MISSING_BOUNDARY,NO_OBLIGATION,ONE_TIME_MAILING,
> >>   REMOVE_IN_QUOTES,REMOVE_SUBJ,RISK_FREE 
> >>
> >> From [EMAIL PROTECTED]  Tue Sep 27 15:22:19 2005
> >> Received: from localhost by pulsar.lfa.com
> >> with SpamAssassin (2.64 2004-01-11);
> >> Tue, 27 Sep 2005 15:24:16 -0700
> >> From: NFN Smith <[EMAIL PROTECTED]
> >> To: [EMAIL PROTECTED]
> >> Subject: *SPAM* Sequential test #12a
> >> Date: Tue, 27 Sep 2005 15:21:15 -0700
> >> Message-Id: <[EMAIL PROTECTED]>
> >> X-Spam-Flag: YES
> >> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on
pulsar.lfa.com
> >> X-Spam-Level: ***
> >> X-Spam-Status: Yes, hits=7.7 required=4.0 tests=CLICK_BELOW,EXCUSE_3,
> >> FREE_CONSULTATION,MAILTO_TO_REMOVE,MIME_MISSING_BOUNDARY,
> >>
NO_OBLIGATION,ONE_TIME_MAILING,REMOVE_IN_QUOTES,REMOVE_SUBJ,RISK_FREE 
> >> autolearn=no version=2.64
> >> MIME-Version: 1.0
> > 
> > 
> > Anything else obvious that I might be missing?  I think I'm close
> 
> If I'm not mistaken (and I could be, it's been awhile since I've
> used the 2.6x series), the ALL_TRUSTED rule wasn't introduced until
> the 3.0x series.  your headers show you're using 2.64.  also your
> debug output shows that spamassassin wasn't able to parse the
> "internal_network" settings (which also weren't introduced until the
> 3.0x series).
> 
> So, you either have some misconceptions about 2.64's capabilities,
> or you have 2 copies of spamassassin running in 2 different
> locations on your machine and the one in your path is 2.64, and
> causing you headaches.

Good catch Alan, I hadn't noticed that.  I think y

Re: trusted_networks use

[alan premselaar]

NFN Smith wrote:

Thanks for the ongoing feedback

Bowie Bailey wrote:



Now that you've made those changes, post the headers from another
example email so we can see if anything changed.



See below.



Also, you may want to save your email into a file and manually run it
through SA to see what happens.  Just add '-t -D' to the option list



I did that, and found a couple of things.  I'm closer, but not there yet.

In reading the debugging output, I realized that I was putting my work 
in /etc/mail/sa-mimedefang.cf, and all my other local config settings 
are in /etc/mail/spamassassin/local.cf.  When I moved this work to 
local.cf, debug showed me getting further.


I also found that Net::DNS wasn't installed -- up until now, I haven't 
needed it, because I haven't been doing stuff that requires DNS queries. 
 I installed that, and am making further progress.


With the two changes, I'm getting correct designation of which hosts are 
trusted or not (which I wasn't getting before), but still not getting 
the ALL_TRUSTED rule.


By the way, I've also made sure that the $HOME/.spamassassin/user_prefs 
doesn't have any user-specific settings that may be interfering.


Debug output shows:


debug: using "/usr/share/spamassassin" for default rules dir
debug: using "/etc/mail/spamassassin" for site rules dir
debug: using "/home/test-user/.spamassassin" for user state dir
debug: using "/home/test-user/.spamassassin/user_prefs" for user prefs 
file
debug: Failed to parse line in SpamAssassin configuration, skipping: 
internal_networks 64.65.180.91
debug: Failed to parse line in SpamAssassin configuration, skipping: 
internal_networks 10.10.10.141

debug: Score set 1 chosen.
debug: Initialising learner
debug: received-header: parsed as [ ip=68.99.120.79 
rdns=lakecmmtao05.coxmail.com helo=lakecmmtao05.coxmail.com 
by=pulsar.lfa.com ident= ]
debug: received-header: parsed as [ ip=24.249.175.20 rdns=really 
helo=!192.168.1.100! by=lakecmmtao05.coxmail.com ident= ]

debug: received-header: relay 68.99.120.79 trusted? yes
debug: received-header: relay 24.249.175.20 trusted? no
debug: running header regexp tests; score so far=0
debug: running body-text per-line regexp tests; score so far=0
debug: running raw-body-text per-line regexp tests; score so far=5.733
debug: running uri tests; score so far=6.536
debug: uri tests: Done uriRE
debug: running full-text regexp tests; score so far=6.573
debug: Current PATH is: 
/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin

debug: all '*From' addrs: [EMAIL PROTECTED]
debug: all '*To' addrs: [EMAIL PROTECTED] [EMAIL PROTECTED]
debug: is Net::DNS::Resolver available? yes
debug: trying (3) kernel.org...
debug: looking up MX for 'kernel.org'
debug: MX for 'kernel.org' exists? 1
debug: MX lookup of kernel.org succeeded => Dns available (set 
dns_available to hardcode)

debug: is DNS available? 1
debug: DNS MX records found: 1
debug: forged-HELO: from=really helo=!192.168.1.100! by=coxmail.com
debug: running meta tests; score so far=6.573
debug: is spam? score=7.673 required=4 
tests=CLICK_BELOW,EXCUSE_3,FREE_CONSULTATION,MAILTO_TO_REMOVE,MIME_MISSING_BOUNDARY,NO_OBLIGATION,ONE_TIME_MAILING,REMOVE_IN_QUOTES,REMOVE_SUBJ,RISK_FREE 


From [EMAIL PROTECTED]  Tue Sep 27 15:22:19 2005
Received: from localhost by pulsar.lfa.com
with SpamAssassin (2.64 2004-01-11);
Tue, 27 Sep 2005 15:24:16 -0700
From: NFN Smith <[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: *SPAM* Sequential test #12a
Date: Tue, 27 Sep 2005 15:21:15 -0700
Message-Id: <[EMAIL PROTECTED]>
X-Spam-Flag: YES
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on pulsar.lfa.com
X-Spam-Level: ***
X-Spam-Status: Yes, hits=7.7 required=4.0 tests=CLICK_BELOW,EXCUSE_3,
FREE_CONSULTATION,MAILTO_TO_REMOVE,MIME_MISSING_BOUNDARY,
NO_OBLIGATION,ONE_TIME_MAILING,REMOVE_IN_QUOTES,REMOVE_SUBJ,RISK_FREE 
autolearn=no version=2.64

MIME-Version: 1.0



Anything else obvious that I might be missing?  I think I'm close

Smith



If I'm not mistaken (and I could be, it's been awhile since I've used 
the 2.6x series), the ALL_TRUSTED rule wasn't introduced until the 3.0x 
series.  your headers show you're using 2.64.  also your debug output 
shows that spamassassin wasn't able to parse the "internal_network" 
settings (which also weren't introduced until the 3.0x series).


So, you either have some misconceptions about 2.64's capabilities, or 
you have 2 copies of spamassassin running in 2 different locations on 
your machine and the one in your path is 2.64, and causing you headaches.


HTH

alan

Re: trusted_networks use

[NFN Smith]

Thanks for the ongoing feedback

Bowie Bailey wrote:



Now that you've made those changes, post the headers from another
example email so we can see if anything changed.


See below.


Also, you may want to save your email into a file and manually run it
through SA to see what happens.  Just add '-t -D' to the option list


I did that, and found a couple of things.  I'm closer, but not there yet.

In reading the debugging output, I realized that I was putting my work 
in /etc/mail/sa-mimedefang.cf, and all my other local config settings 
are in /etc/mail/spamassassin/local.cf.  When I moved this work to 
local.cf, debug showed me getting further.


I also found that Net::DNS wasn't installed -- up until now, I haven't 
needed it, because I haven't been doing stuff that requires DNS queries. 
 I installed that, and am making further progress.


With the two changes, I'm getting correct designation of which hosts are 
trusted or not (which I wasn't getting before), but still not getting 
the ALL_TRUSTED rule.


By the way, I've also made sure that the $HOME/.spamassassin/user_prefs 
doesn't have any user-specific settings that may be interfering.


Debug output shows:


debug: using "/usr/share/spamassassin" for default rules dir
debug: using "/etc/mail/spamassassin" for site rules dir
debug: using "/home/test-user/.spamassassin" for user state dir
debug: using "/home/test-user/.spamassassin/user_prefs" for user prefs file
debug: Failed to parse line in SpamAssassin configuration, skipping: 
internal_networks   64.65.180.91
debug: Failed to parse line in SpamAssassin configuration, skipping: 
internal_networks   10.10.10.141
debug: Score set 1 chosen.
debug: Initialising learner
debug: received-header: parsed as [ ip=68.99.120.79 
rdns=lakecmmtao05.coxmail.com helo=lakecmmtao05.coxmail.com by=pulsar.lfa.com 
ident= ]
debug: received-header: parsed as [ ip=24.249.175.20 rdns=really 
helo=!192.168.1.100! by=lakecmmtao05.coxmail.com ident= ]
debug: received-header: relay 68.99.120.79 trusted? yes
debug: received-header: relay 24.249.175.20 trusted? no
debug: running header regexp tests; score so far=0
debug: running body-text per-line regexp tests; score so far=0
debug: running raw-body-text per-line regexp tests; score so far=5.733
debug: running uri tests; score so far=6.536
debug: uri tests: Done uriRE
debug: running full-text regexp tests; score so far=6.573
debug: Current PATH is: 
/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin
debug: all '*From' addrs: [EMAIL PROTECTED]
debug: all '*To' addrs: [EMAIL PROTECTED] [EMAIL PROTECTED]
debug: is Net::DNS::Resolver available? yes
debug: trying (3) kernel.org...
debug: looking up MX for 'kernel.org'
debug: MX for 'kernel.org' exists? 1
debug: MX lookup of kernel.org succeeded => Dns available (set dns_available to 
hardcode)
debug: is DNS available? 1
debug: DNS MX records found: 1
debug: forged-HELO: from=really helo=!192.168.1.100! by=coxmail.com
debug: running meta tests; score so far=6.573
debug: is spam? score=7.673 required=4 
tests=CLICK_BELOW,EXCUSE_3,FREE_CONSULTATION,MAILTO_TO_REMOVE,MIME_MISSING_BOUNDARY,NO_OBLIGATION,ONE_TIME_MAILING,REMOVE_IN_QUOTES,REMOVE_SUBJ,RISK_FREE
From [EMAIL PROTECTED]  Tue Sep 27 15:22:19 2005
Received: from localhost by pulsar.lfa.com
with SpamAssassin (2.64 2004-01-11);
Tue, 27 Sep 2005 15:24:16 -0700
From: NFN Smith <[EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: *SPAM* Sequential test #12a
Date: Tue, 27 Sep 2005 15:21:15 -0700
Message-Id: <[EMAIL PROTECTED]>
X-Spam-Flag: YES
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on pulsar.lfa.com
X-Spam-Level: ***
X-Spam-Status: Yes, hits=7.7 required=4.0 tests=CLICK_BELOW,EXCUSE_3,
FREE_CONSULTATION,MAILTO_TO_REMOVE,MIME_MISSING_BOUNDARY,
	NO_OBLIGATION,ONE_TIME_MAILING,REMOVE_IN_QUOTES,REMOVE_SUBJ,RISK_FREE 
	autolearn=no version=2.64

MIME-Version: 1.0


Anything else obvious that I might be missing?  I think I'm close

Smith

Re: trusted_networks use

[NFN Smith]

Alan Premselaar wrote:


NFN Smith wrote:

Following up on my own post.  I'm still thrashing, and not getting any 
difference in results.



...snip...

Sorry, I just have to ask.  Since you're using MIMEDefang... you are 
remembering to restart (or reload) mimedefang after making your changes, 
right?  and you're making changes to the sa-mimedefang.cf file, right?


A question worth asking.  Yes, I'm making sure I'm restarting 
MIMEDefang.  That's an easy thing to miss, and I've gotten bitten on 
things of that nature before.


Thanks for the suggestion.

Smith

Re: trusted_networks use

[Alan Premselaar]

NFN Smith wrote:
Following up on my own post.  I'm still thrashing, and not getting any 
difference in results.



...snip...

Sorry, I just have to ask.  Since you're using MIMEDefang... you are 
remembering to restart (or reload) mimedefang after making your changes, 
right?  and you're making changes to the sa-mimedefang.cf file, right?


alan

RE: trusted_networks use

[Bowie Bailey]

From: NFN Smith [mailto:[EMAIL PROTECTED]
> 
> Following up on my own post.  I'm still thrashing, and not 
> getting any 
> difference in results.
> 
> NFN Smith wrote:
> > 
> > OK, I've expanded my settings, but I'm still not making any 
> > progress.
> > 
> > 
> >> trusted_networks64.65.180.91
> >> trusted_networks10.10.10.141 
> >> trusted_networks68.99.120.79
> >> trusted_networks24.249.175.230
> > 
> > 
> >> internal_networks   64.65.180.91
> >> internal_networks   10.10.10.141
> > 
> > 
> >> whitelist_from_rcvd  [EMAIL PROTECTED]pulsar.lfa.com
> >> whitelist_from_rcvd  [EMAIL PROTECTED]lakecmmtao05.coxmail.com
> >> whitelist_from_rcvd  [EMAIL PROTECTED]
wsip-24-249-175-230.ph.ph.cox.net
> > 
> > 
> > - pulsar.lfa.com has a public address of 64.65.180.141, and its
> > internal IP address is 10.10.10.91
> > 
> > - lacecmmtao05.coxmail.com is 68.99.120.79
> > 
> > - 24.249.175.230 (wsip-24-249-175-230.ph.ph.cox.net) is the
> > network that the message is originating from
> > 
> > What else am I missing?
> 
> Any chance that I'm missing something different, such as DNS checks
> not running, or some sort of blockage (i.e., firewall)?

Oops.  I was going to reply to you this morning and things just got a
bit busy...

Now that you've made those changes, post the headers from another
example email so we can see if anything changed.

Also, you may want to save your email into a file and manually run it
through SA to see what happens.  Just add '-t -D' to the option list
to get debugging output and force a spam report to be added.  This
should let you know if there are any problems running the network
checks.  This will generate quite a bit of output, just scan through
it for anything that looks like an error.

The command line would look like this:
spamassassin -t -D < message.txt

Bowie

Re: trusted_networks use

[NFN Smith]

Following up on my own post.  I'm still thrashing, and not getting any 
difference in results.


NFN Smith wrote:





You really do HAVE to trust all your own mail relays. Anything else is 
just broken.





Agreed.

OK, I've expanded my settings, but I'm still not making any progress.



trusted_networks64.65.180.91
trusted_networks10.10.10.141 
trusted_networks68.99.120.79

trusted_networks24.249.175.230




internal_networks   64.65.180.91
internal_networks   10.10.10.141




whitelist_from_rcvd  [EMAIL PROTECTED]pulsar.lfa.com
whitelist_from_rcvd  [EMAIL PROTECTED]lakecmmtao05.coxmail.com
whitelist_from_rcvd  [EMAIL PROTECTED]wsip-24-249-175-230.ph.ph.cox.net



- pulsar.lfa.com has a public address of 64.65.180.141, and its internal 
IP address is 10.10.10.91


- lacecmmtao05.coxmail.com is 68.99.120.79

- 24.249.175.230 (wsip-24-249-175-230.ph.ph.cox.net) is the network that 
the message is originating from


What else am I missing?


Any chance that I'm missing something different, such as DNS checks not 
running, or some sort of blockage (i.e., firewall)?


Smith

Re: trusted_networks use

[Matt Kettler]

Bowie Bailey wrote:
> 
> My only question there was whether SA will implicitly trust the
> machine it is running on.  After all, if you can't trust yourself, who
> can you trust? :)

If you explicitly set trusted_networks, then no, it won't SA will only trust the
hosts you tell it.

If you don't have a trusted_networks delcared, then the auto-trust algorithm
will trust the machine it runs on, and possibly others.

Re: trusted_networks use

[NFN Smith]

Matt Kettler wrote:


Bowie Bailey wrote:



Ok, so here is what I see as far as the mail path:

- Sent from 24.249.175.230 ... untrusted
- Received by 68.99.120.79 ... trusted
- Received by pulsar.lfa.com ... untrusted (unless SA defaults the
 local machine)





If pulsar.lfa.com is untrusted, all headers will be untrusted.

After all, an untrusted box is assumed to be able to forge headers, thus it
could have forged the 68.99.120.79 header. Since you can't prove it's not forged
by pulsar, you can't trust it.


You really do HAVE to trust all your own mail relays. Anything else is just 
broken.




Agreed.

OK, I've expanded my settings, but I'm still not making any progress.


> trusted_networks64.65.180.91
> trusted_networks10.10.10.141

trusted_networks68.99.120.79
trusted_networks24.249.175.230



internal_networks   64.65.180.91
internal_networks   10.10.10.141


> whitelist_from_rcvd  [EMAIL PROTECTED]pulsar.lfa.com

whitelist_from_rcvd  [EMAIL PROTECTED]lakecmmtao05.coxmail.com
whitelist_from_rcvd  [EMAIL PROTECTED]wsip-24-249-175-230.ph.ph.cox.net


- pulsar.lfa.com has a public address of 64.65.180.91, and its internal 
IP address is 10.10.10.91


- lacecmmtao05.coxmail.com is 68.99.120.79

- 24.249.175.230 (wsip-24-249-175-230.ph.ph.cox.net) is the network that 
I'm sending my mail from.


What else am I missing?

Smith

RE: trusted_networks use

[Bowie Bailey]

From: Matt Kettler [mailto:[EMAIL PROTECTED]
> 
> Bowie Bailey wrote:
> 
> > Ok, so here is what I see as far as the mail path:
> > 
> > - Sent from 24.249.175.230 ... untrusted
> > - Received by 68.99.120.79 ... trusted
> > - Received by pulsar.lfa.com ... untrusted (unless SA defaults the
> >   local machine)
> 
> If pulsar.lfa.com is untrusted, all headers will be untrusted.
> 
> After all, an untrusted box is assumed to be able to forge headers,
> thus it could have forged the 68.99.120.79 header. Since you can't
> prove it's not forged by pulsar, you can't trust it.

True, of course.  I was just reading each IP on it's own.

The first header (reading from the top) from an untrusted IP address
and all of the headers below it will not be trusted.

My only question there was whether SA will implicitly trust the
machine it is running on.  After all, if you can't trust yourself, who
can you trust? :)

Bowie

Re: trusted_networks use

[Matt Kettler]

Bowie Bailey wrote:

> Ok, so here is what I see as far as the mail path:
> 
> - Sent from 24.249.175.230 ... untrusted
> - Received by 68.99.120.79 ... trusted
> - Received by pulsar.lfa.com ... untrusted (unless SA defaults the
>   local machine)
> 


If pulsar.lfa.com is untrusted, all headers will be untrusted.

After all, an untrusted box is assumed to be able to forge headers, thus it
could have forged the 68.99.120.79 header. Since you can't prove it's not forged
by pulsar, you can't trust it.


You really do HAVE to trust all your own mail relays. Anything else is just 
broken.

RE: trusted_networks use

[Bowie Bailey]

From: NFN Smith [mailto:[EMAIL PROTECTED]
> 
> From there, I've done more tinkering, but still not getting the
> results I want.  Another try on raw data.
> 
> Starting with settings in sa-mimedefang.cf:
> 
> > # IP addresses of trusted hosts -- use these instead of whitelisting our
domains
> > trusted_networks68.99.120.79
> > internal_networks
> > whitelist_from_rcvd  [EMAIL PROTECTED]  lakecmmtao05.coxmail.com
> 
> I hadn't had a setting for internal_networks, but reading the man
> definition, it seems worth putting it there with a null definition.

Hmm... I'm not sure what effect that internal_networks line will have.
If you don't want to explicitly set it, just leave it out and let it
default to the trusted_networks setting.

>  From there, I generated a message that was delivered with the
>  following relevant headers:
> 
> > Received: from lakecmmtao05.coxmail.com (lakecmmtao05.coxmail.com
[68.99.120.79] )
> > by pulsar.lfa.com (8.13.1/8.13.1) with ESMTP id j8NJ4Oxs027324
> > for <[EMAIL PROTECTED]>; Fri, 23 Sep 2005 12:04:25 -0700
> > Received: from [192.168.1.100] (really [24.249.175.230])
> >   by lakecmmtao05.coxmail.com
> >   (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP
> >   id
<[EMAIL PROTECTED]>
> >   for <[EMAIL PROTECTED]>; Fri, 23 Sep 2005 15:04:19 -0400
> > Message-ID: <[EMAIL PROTECTED]>
> > Date: Fri, 23 Sep 2005 12:03:32 -0700
> > From: NFN Smith <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Subject: [SPAM: 7.737] Spam test #6
> > X-Spam-Status: Yes
> > X-Spam-Score: 7.737 (***) (required=4) 
> > tests=BLANK_LINES_70_80,CLICK_BELOW,EXCUSE_3,FREE_CONSULTATION,
> > MAILTO_TO_REMOVE,NO_OBLIGATION,ONE_TIME_MAILING,REMOVE_IN_QUOTES,
> > REMOVE_SUBJ,RISK_FREE
> > X-Scanned-By: MIMEDefang 2.44
> 
> Thus, I sent a message through a coxmail.com server, showing the
> sacbeemail.com address in the From: line (a combination I want to
> trust, at least for testing purposes), and addressed to
> [EMAIL PROTECTED]  The target machine is lfa.com.

Ok, so here is what I see as far as the mail path:

- Sent from 24.249.175.230 ... untrusted
- Received by 68.99.120.79 ... trusted
- Received by pulsar.lfa.com ... untrusted (unless SA defaults the
  local machine)

> Relevant log entries show:
> 
> > Sep 23 12:04:25 pulsar sendmail[27324]: j8NJ4Oxs027324: 
> from=<[EMAIL PROTECTED]>, size=1607, class=0, 
> nrcpts=1, msgid=<[EMAIL PROTECTED]>, 
> proto=ESMTP, daemon=MTA, relay=lakecmmtao05.coxmail.com [68.99.120.79]
> > Sep 23 12:04:26 pulsar mimedefang.pl[27269]: 
> MDLOG,j8NJ4Oxs027324,spam,7.737,68.99.120.79,<[EMAIL PROTECTED]
> beemail.com>,<[EMAIL PROTECTED]>,Spam test #6
> > Sep 23 12:04:26 pulsar sendmail[27324]: j8NJ4Oxs027324: 
> Milter change: header Subject: from Spam test #6 to [SPAM: 
> 7.737] Spam test #6
> > Sep 23 12:04:26 pulsar sendmail[27324]: j8NJ4Oxs027324: 
> Milter add: header: X-Scanned-By: MIMEDefang 2.44
> > Sep 23 12:04:26 pulsar sendmail[27328]: j8NJ4Oxs027324: 
> to=<[EMAIL PROTECTED]>, delay=00:00:01, xdelay=00:00:00, 
> mailer=local, pri=33885, dsn=2.0.0, stat=Sent
> 
> Thus, in the results that I'm getting, I don't have something quite
> right in the combination of definitions between trusted_networks and
> whitelist_from_rcvd.  From what I've figured out so far, I seem to
> be close, but I'm missing something small.

Ok...I just re-read the man page entry for whitelist_from_rcvd.  Now I
think I follow what is happening.

The IP that is checked is the one that sent mail to your internal
network (as defined by internal_networks).  So this is what happened:

lakecmmtao05.coxmail.com is part of your internal network, so the
check was pushed back to the previous server, 24.249.175.230, which
translates to wsip-24-249-175-230.ph.ph.cox.net and doesn't match the
whitelist_from_rcvd line.

What you probably want to do is this:

  internal_networks 64.65.180.91

  trusted_networks 64.65.180.91
  trusted_networks 68.99.120.79

So that pulsar.lfa.com is internal and trusted, while
lakecmmtao05.coxmail.com is trusted, but not internal.  That way, you
can use lakecmmtao05 in the whitelist_from_rcvd commands.

Whitelist_from_rcvd can only check domains outside of your
internal_networks.  So for what you want, only the local machine is
internal.  All others are simply trusted.

Try it that way and see what happens.

Can anyone else who is more knowledgeable about how internal_networks
and trusted_networks interact comment on this?  I think this will work
fine, but I want to make sure there aren't any side effects that I'm
not considering.

Bowie

Re: trusted_networks use

[Daryl C. W. O'Shea]

NFN Smith wrote:
Thus, in the results that I'm getting, I don't have something quite 
right in the combination of definitions between trusted_networks and 
whitelist_from_rcvd.  From what I've figured out so far, I seem to be 
close, but I'm missing something small.


Did you remember to restart your milter?

Re: trusted_networks use

[Daryl C. W. O'Shea]

Bowie Bailey wrote:

whitelist_from_rcvd
You can use this instead of whitelist_from.  It requires a bit
more setup, but it is immune to the forgery problems of
whitelist_from.  Use this to list each valid domainname/mailserver
combination.  Note that this requires a correct internal_networks
configuration to work properly.


For a less effort solution, you can use whitelist_from_spf in SA 3.1 if 
you've got SPF set up in SpamAssassin and the domain in question 
publishes SPF records.


Daryl

Re: trusted_networks use

[NFN Smith]

Bowie Bailey wrote:


It's definitely coming from an external network.





Yes, I understand that your servers are separated in different IP
blocks and in different facilities, but that is irrelevant.  When I
say that the email is coming from an external network, what I mean is
that it is originating from a server that is not in your
trusted_networks list.

All of the servers that you control should be listed in
trusted_networks.  This tell SA that it can trust the headers coming
from them and trust them not to originate spam.


OK.  Now we're on the same page.  I had misunderstood the definition of 
"local" as "the same IP block", rather than "the group of trusted servers".





I can understand not wanting to post email addresses, but IP addresses
are not private information in most cases.  


I can redo this with live data that shows real data that I'm comfortable 
with disclosing.  See below.




As noted by Matt Kettler, whitelist_from is very dangerous for exactly
that reason.  Don't use it.


Makes sense.  That's the point of the exercise.  Now I just need to get 
the mechanics working.





The solution to the problem depends on exactly what you want to
accomplish.

If you want the email to bypass scanning completely, then that needs
to be addressed outside of SA.  Once a message is passed to SA, it
WILL be scanned -- there is no method to prevent it.

If you want to avoid local mail being marked as spam, this can be done
in SA with a combination of settings.


For this, I don't need to bypass SA scanning, but it would be an 
alternate path.





trusted_networks



internal_networks



whitelist_from_rcvd




The bottom line is that there is no way to prevent an email from being
scanned once it gets to SA, but you can take steps to prevent it from
being marked as spam.


That's not a problem.  The real issue is making sure that we don't trust 
forged From: lines.




Also, SA doesn't care how widely scattered your MXs are as long as it
knows who they are.  Don't think of it as multiple separate networks
containing mailservers, think of it as a single logical network
containing all of the mailservers you control.


OK.  That's exactly where I want to go.

From there, I've done more tinkering, but still not getting the results 
I want.  Another try on raw data.


Starting with settings in sa-mimedefang.cf:


# IP addresses of trusted hosts -- use these instead of whitelisting our domains
trusted_networks68.99.120.79
internal_networks
whitelist_from_rcvd [EMAIL PROTECTED]lakecmmtao05.coxmail.com


I hadn't had a setting for internal_networks, but reading the man 
definition, it seems worth putting it there with a null definition.


From there, I generated a message that was delivered with the following 
relevant headers:



Received: from lakecmmtao05.coxmail.com (lakecmmtao05.coxmail.com 
[68.99.120.79] )
by pulsar.lfa.com (8.13.1/8.13.1) with ESMTP id j8NJ4Oxs027324
for <[EMAIL PROTECTED]>; Fri, 23 Sep 2005 12:04:25 -0700
Received: from [192.168.1.100] (really [24.249.175.230])
  by lakecmmtao05.coxmail.com
  (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP
  id <[EMAIL PROTECTED]>
  for <[EMAIL PROTECTED]>; Fri, 23 Sep 2005 15:04:19 -0400
Message-ID: <[EMAIL PROTECTED]>
Date: Fri, 23 Sep 2005 12:03:32 -0700
From: NFN Smith <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [SPAM: 7.737] Spam test #6
X-Spam-Status: Yes
X-Spam-Score: 7.737 (***) (required=4) tests=BLANK_LINES_70_80,CLICK_BELOW,E
XCUSE_3,FREE_CONSULTATION,MAILTO_TO_REMOVE,NO_OBLIGATION,ONE_TIME_MAILING,REMOVE
_IN_QUOTES,REMOVE_SUBJ,RISK_FREE
X-Scanned-By: MIMEDefang 2.44


Thus, I sent a message through a coxmail.com server, showing the 
sacbeemail.com address in the From: line (a combination I want to trust, 
at least for testing purposes), and addressed to [EMAIL PROTECTED]  The 
target machine is lfa.com.


Relevant log entries show:


Sep 23 12:04:25 pulsar sendmail[27324]: j8NJ4Oxs027324: from=<[EMAIL PROTECTED]>, 
size=1607, class=0, nrcpts=1, msgid=<[EMAIL PROTECTED]>, proto=ESMTP, daemon=MTA, 
relay=lakecmmtao05.coxmail.com [68.99.120.79]
Sep 23 12:04:26 pulsar mimedefang.pl[27269]: 
MDLOG,j8NJ4Oxs027324,spam,7.737,68.99.120.79,<[EMAIL PROTECTED]>,<[EMAIL 
PROTECTED]>,Spam test #6
Sep 23 12:04:26 pulsar sendmail[27324]: j8NJ4Oxs027324: Milter change: header 
Subject: from Spam test #6 to [SPAM: 7.737] Spam test #6
Sep 23 12:04:26 pulsar sendmail[27324]: j8NJ4Oxs027324: Milter add: header: 
X-Scanned-By: MIMEDefang 2.44
Sep 23 12:04:26 pulsar sendmail[27328]: j8NJ4Oxs027324: to=<[EMAIL PROTECTED]>, 
delay=00:00:01, xdelay=00:00:00, mailer=local, pri=33885, dsn=2.0.0, stat=Sent


Thus, in the results that I'm getting, I don't have something quite 
right in the combination of definitions between trusted_networks and 
whitelist_from_rcvd.  From what I've figured out so far, I seem to be 
close, but I'm missing something small.


Thanks for yo

RE: trusted_networks use

[Bowie Bailey]

From: NFN Smith [mailto:[EMAIL PROTECTED]
> 
> Bowie Bailey wrote:
> 
> 
> >>
> >>>X-Spam-Score: 6.87 (**) (required=4)
> >>>tests=CLICK_BELOW,EXCUSE_3,FREE_CONSULTATION,MAILTO_TO_REMOVE,
> >>>NO_OBLIGATION,ONE_TIME_MAILING,REMOVE_IN_QUOTES,REMOVE_SUBJ,RISK_FREE
> > 
> > I don't see ALL_TRUSTED, so apparently this email originated outside
> > of your network.  Otherwise, there are no tests listed here that would
> > be affected by your trusted_networks settings.
> 
> It's definitely coming from an external network.
> 
>  From the beginning, I've tried to emphasize that each of the
>  servers in question are hosted in different co-lo facilities, with
>  completely different blocks of IP addresses.  We control all the
>  servers, and they're definitely trusted, but they're not local to
>  each other.

Yes, I understand that your servers are separated in different IP
blocks and in different facilities, but that is irrelevant.  When I
say that the email is coming from an external network, what I mean is
that it is originating from a server that is not in your
trusted_networks list.

All of the servers that you control should be listed in
trusted_networks.  This tell SA that it can trust the headers coming
from them and trust them not to originate spam.

> > That looks like a faked header.  Is your server really called
> > "alpha.example.com"?
> 
> Real data redacted for security reasons. I don't have the freedom to
> be more detailed in a public discussion.  Yes, I know it makes
> troubleshooting more difficult this way.

I can understand not wanting to post email addresses, but IP addresses
are not private information in most cases.  They get published in DNS
records and broadcast to anyone the server communicates with.  If
we're dealing with internal network IPs, then I can understand.  It
does, however make troubleshooting more difficult.

In this case, I don't think we really need to go there yet.  At
the moment, we are mainly trying to establish how SA is supposed
to work.  Once we agree on what is supposed to happen, then if
there was an email that didn't seem to be scored properly, I would
need to see the headers in order to diagnose the scoring.

> > As I said above, this looks like a normal email coming from
> > outside of your network.  If it really originated inside your
> > network, then you need to fix your trusted_networks.  Beyond that,
> > everything looks normal as far as I can tell from the information
> > provided.
> 
> As noted, the message definitely originates in a different network.
> 
> Let me make sure I have the problem definition correct --
> 
> We have servers in several co-lo facilities, and each server hosts
> several domains, each with its own IP address.  As noted, the
> domains and the servers are trusted, but they're in separate
> networks.
> 
> The problem that we do have is that when we list our domains via
> whitelist_from, then incoming mail with forged From: lines that
> shows one of those domains (typically, the same domain as the
> addressee) is given a free pass.

As noted by Matt Kettler, whitelist_from is very dangerous for exactly
that reason.  Don't use it.

> For this, there's no reason to trust the From: line as being valid,
> because it's so easily forged.  However, if the message is coming
> from known trusted IP addresses, then that's reason to the message a
> pass, and either have SA give a low score, or not run SA at all.
> 
> In short, in the question of how the message is handled, we want to
> trust the server IP address, but assume that the From: line is
> probably forged.
> 
> From this discussion, I think I'm trying to do something outside the
> scope of what SA is designed to do, and the better way of getting
> there is the suggestion of doing it via MIMEDefang, and bypassing
> the call to SA altogether if the message is coming from a trusted
> (but non-local) server.

The solution to the problem depends on exactly what you want to
accomplish.

If you want the email to bypass scanning completely, then that needs
to be addressed outside of SA.  Once a message is passed to SA, it
WILL be scanned -- there is no method to prevent it.

If you want to avoid local mail being marked as spam, this can be done
in SA with a combination of settings.

trusted_networks
Every mailserver you control (no matter what network it is on)
should be listed here.  SA uses this list to determine from the
headers when the email entered your sphere of control.  Your
servers will not be checked for blacklisting and the spam score
for the email will be reduced on emails that originate within your
control.  This setting MUST be set correctly since it affects so
many other things in SA.

internal_networks
This should contain all of the mailservers listed in
trusted_networks except those that are expected to receive mail
directly from computers on dial-up connections.  If none of your
mailservers receive mail directly from dial-up conne

Re: trusted_networks use

[Matt Kettler]

NFN Smith wrote:

> The problem that we do have is that when we list our domains via
> whitelist_from, then incoming mail with forged From: lines that shows
> one of those domains (typically, the same domain as the addressee) is
> given a free pass.

Please don't use whitelist_from. Ever. For anything.

To quote the manpage:
---
whitelist_from [EMAIL PROTECTED]
Used to specify addresses which send mail that is often tagged (incorrectly)
as spam; it also helps if they are addresses of big companies with lots of
lawyers. This way, if spammers impersonate them, they'll get into big trouble,
so it doesn't provide a shortcut around SpamAssassin. If you want to whitelist
your own domain, be aware that spammers will often impersonate the domain of the
recipient. The recommended solution is to instead use whitelist_from_rcvd as
explained below.
---

Do it right, and use whitelist_from_rcvd.

Re: trusted_networks use

[NFN Smith]

Bowie Bailey wrote:





X-Spam-Score: 6.87 (**) (required=4)
tests=CLICK_BELOW,EXCUSE_3,FREE_CONSULTATION,MAILTO_TO_REMOVE,
NO_OBLIGATION,ONE_TIME_MAILING,REMOVE_IN_QUOTES,REMOVE_SUBJ,RISK_FREE



I don't see ALL_TRUSTED, so apparently this email originated outside
of your network.  Otherwise, there are no tests listed here that would
be affected by your trusted_networks settings.


It's definitely coming from an external network.

From the beginning, I've tried to emphasize that each of the servers in 
question are hosted in different co-lo facilities, with completely 
different blocks of IP addresses.  We control all the servers, and 
they're definitely trusted, but they're not local to each other.





That looks like a faked header.  Is your server really called
"alpha.example.com"?


Real data redacted for security reasons. I don't have the freedom to be 
more detailed in a public discussion.  Yes, I know it makes 
troubleshooting more difficult this way.



[ ... ]



As I said above, this looks like a normal email coming from outside of
your network.  If it really originated inside your network, then you
need to fix your trusted_networks.  Beyond that, everything looks
normal as far as I can tell from the information provided.


As noted, the message definitely originates in a different network.

Let me make sure I have the problem definition correct --

We have servers in several co-lo facilities, and each server hosts 
several domains, each with its own IP address.  As noted, the domains 
and the servers are trusted, but they're in separate networks.


The problem that we do have is that when we list our domains via 
whitelist_from, then incoming mail with forged From: lines that shows 
one of those domains (typically, the same domain as the addressee) is 
given a free pass.


For this, there's no reason to trust the From: line as being valid, 
because it's so easily forged.  However, if the message is coming from 
known trusted IP addresses, then that's reason to the message a pass, 
and either have SA give a low score, or not run SA at all.


In short, in the question of how the message is handled, we want to 
trust the server IP address, but assume that the From: line is probably 
forged.


From this discussion, I think I'm trying to do something outside the 
scope of what SA is designed to do, and the better way of getting there 
is the suggestion of doing it via MIMEDefang, and bypassing the call to 
SA altogether if the message is coming from a trusted (but non-local) 
server.


Thanks for taking the time to help on this one.  I really appreciate it.

Smith

RE: trusted_networks use

[Bowie Bailey]

From: NFN Smith [mailto:[EMAIL PROTECTED]
> 
> Bowie Bailey wrote:
> 
> >>Is there any way of tracing the behavior, to see what's expected and
> >>how things aren't matching when a message actually comes through?
> > 
> > 
> > It sounds to me like your setup is working as expected.  Mails
> > coming from servers in your trusted_networks list will still be
> > scanned for spam as normal.  The only difference is that they may
> > get the ALL_TRUSTED rule depending on exactly where the mail
> > originated.
> > 
> > Show us the X-Spam headers from one of your test emails so we can
> > see exactly which rules are hitting.
> 
> Thanks for the feedback. Here's what I have.
> 
> 
> 
> > X-Spam-Score: 6.87 (**) (required=4)
> > tests=CLICK_BELOW,EXCUSE_3,FREE_CONSULTATION,MAILTO_TO_REMOVE,
> > NO_OBLIGATION,ONE_TIME_MAILING,REMOVE_IN_QUOTES,REMOVE_SUBJ,RISK_FREE

I don't see ALL_TRUSTED, so apparently this email originated outside
of your network.  Otherwise, there are no tests listed here that would
be affected by your trusted_networks settings.

> 
> Top received header shows:
> 
> > Received: from foobar.com (foobar.com [1.2.3.4])
> > by alpha.example.com (8.13.1/8.13.1) with ESMTP id
j8MKvFC4019879
> > (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256
verify=FAIL)
> > for <[EMAIL PROTECTED]>; Thu, 22 Sep 2005 13:57:19 -0700

That looks like a faked header.  Is your server really called
"alpha.example.com"?

You need to show the real headers if you want any meaningful feedback.
Show the full list of received headers.  You can mask the email
addresses if you want, but leave the server names and IP addresses
alone.  And if you do change something, please say so or use # to
make it obvious what was changed or masked.

> Relevant sendmail log entries:

These aren't particularly useful.  What you need to show is this:

1. Your trusted_networks settings
2. ALL of the (unmunged) received headers from an email
3. All of the X-Spam headers from the same email
4. What is different from what you expected to see?

As I said above, this looks like a normal email coming from outside of
your network.  If it really originated inside your network, then you
need to fix your trusted_networks.  Beyond that, everything looks
normal as far as I can tell from the information provided.

Bowie

Re: trusted_networks use

[NFN Smith]

Bowie Bailey wrote:


Is there any way of tracing the behavior, to see what's expected and
how things aren't matching when a message actually comes through?



It sounds to me like your setup is working as expected.  Mails coming
from servers in your trusted_networks list will still be scanned for
spam as normal.  The only difference is that they may get the
ALL_TRUSTED rule depending on exactly where the mail originated.

Show us the X-Spam headers from one of your test emails so we can see
exactly which rules are hitting.

Bowie



Thanks for the feedback. Here's what I have.




X-Spam-Score: 6.87 (**) (required=4) tests=CLICK_BELOW,EXCUSE_3,FREE_CONSULT
ATION,MAILTO_TO_REMOVE,NO_OBLIGATION,ONE_TIME_MAILING,REMOVE_IN_QUOTES,REMOVE_SU
BJ,RISK_FREE


Top received header shows:


Received: from foobar.com (foobar.com [1.2.3.4])
by alpha.example.com (8.13.1/8.13.1) with ESMTP id j8MKvFC4019879
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
for <[EMAIL PROTECTED]>; Thu, 22 Sep 2005 13:57:19 -0700



Relevant sendmail log entries:


Sep 22 13:57:18 alpha sendmail[19879]: STARTTLS=server, relay=fubar.com 
[1.2.3.4], version=TLSv1/SSLv3, verify=FAIL, cipher=DHE-RSA-AES256-SHA, 
bits=256/256
Sep 22 13:57:20 alpha sendmail[19879]: j8MKvFC4019879: from=<[EMAIL PROTECTED]>, 
size=1769, class=0, nrcpts=1, msgid=<[EMAIL PROTECTED]>, proto=ESMTP, daemon=MTA, 
relay=fubar.com [1.2.3.4]
Sep 22 13:57:21 alpha mimedefang.pl[8048]: 
MDLOG,j8MKvFC4019879,spam,6.87,1.2.3.4,<[EMAIL PROTECTED]>,<[EMAIL 
PROTECTED]>,Spam test #4
Sep 22 13:57:21 alpha sendmail[19879]: j8MKvFC4019879: Milter change: header 
X-Spam-Status: from  to Yes
Sep 22 13:57:21 alpha sendmail[19879]: j8MKvFC4019879: Milter delete: header 
X-Spam-Score: -98.173 (required=6) 
tests=MAILTO_TO_REMOVE,NO_OBLIGATION,RISK_FREE,USER_IN_WHITELIST
Sep 22 13:57:21 alpha sendmail[19879]: j8MKvFC4019879: Milter change: header 
X-Spam-Score: from  to 6.87 (**) (required=4) 
tests=CLICK_BELOW,EXCUSE_3,FREE_CONSULTATION,MAILTO_TO_REMOVE,NO_OBLIGATION,ONE_TIME_MAILING,REMOVE_IN_QUOTES,REMOVE_SUBJ,RISK_FREE
Sep 22 13:57:21 alpha sendmail[19879]: j8MKvFC4019879: Milter change: header 
Subject: from Spam test #4 to [SPAM: 6.87] Spam test #4



Smith

RE: trusted_networks use

[Bowie Bailey]

From: NFN Smith [mailto:[EMAIL PROTECTED]
> 
> Bowie Bailey wrote:
> >>
> >>Thus, if I'm running SpamAssassin on server xx.yy.zz.ww, and I get
> >>a message from server aa.bb.cc.dd, I want both servers to trust
> >>each other, because I control both servers, and there's no
> >>intermediate relay between the two.
> > 
> > 
> > Then you just need to add one line to the config on each server.
> > 
> > On server "xx.yy.zz.ww":
> > trusted_networks aa.bb.cc.dd
> > 
> > On server "aa.bb.cc.dd"
> > trusted_networks xx.yy.zz.ww
> 
> This is exactly what I'm doing.  Yet when I send a spammy test
> message from a server whose IP address is one that's specified by
> trusted_networks, the message is getting a full SA score.  I have
> verified on the target server that IP address specified by
> trusted_networks is the same one shown by the sending server, both
> from a "relay=" line in the mail logs, and the top Received: line in
> the received message.
> 
> > 
> > With these settings, they will each see the other as trusted.
> > Take a look at the trusted_networks description on the
> > Mail::SpamAssassin::Conf man page for more details.
> 
> I've checked that one several times, but I don't see anything
> obvious over what I'm already doing.
> 
> Is there any way of tracing the behavior, to see what's expected and
> how things aren't matching when a message actually comes through?

It sounds to me like your setup is working as expected.  Mails coming
from servers in your trusted_networks list will still be scanned for
spam as normal.  The only difference is that they may get the
ALL_TRUSTED rule depending on exactly where the mail originated.

Show us the X-Spam headers from one of your test emails so we can see
exactly which rules are hitting.

Bowie

Re: trusted_networks use

[Daryl C. W. O'Shea]

Matt Kettler wrote:

NFN Smith wrote:


Bowie Bailey wrote:




Thus, if I'm running SpamAssassin on server xx.yy.zz.ww, and I get a
message from server aa.bb.cc.dd, I want both servers to trust each
other, because I control both servers, and there's no intermediate
relay between the two.




Then you just need to add one line to the config on each server.

On server "xx.yy.zz.ww":
trusted_networks aa.bb.cc.dd

On server "aa.bb.cc.dd"
trusted_networks xx.yy.zz.ww


Actually, you should include the IP of the actual server in the list 
too, so...


On server "xx.yy.zz.ww":
trusted_networks xx.yy.zz.ww
trusted_networks aa.bb.cc.dd

On server "aa.bb.cc.dd"
trusted_networks aa.bb.cc.dd
trusted_networks xx.yy.zz.ww



This is exactly what I'm doing.  Yet when I send a spammy test message
from a server whose IP address is one that's specified by
trusted_networks, the message is getting a full SA score. 



That's exactly what should happen.

trusted_networks is NOT a whitelist.

Trust here means trusted to not forge headers, it does not mean that trusted to
be spam free, and is not a "get out of spam scanning free" ticket.


Like Matt said, it's not in itself a whitelist (ALL_TRUSTED only gives 
you -4.1 or something like that), but it is absolutely necessary to have 
correct.  It's also the basis for whitelisting using 
"whitelist_from_rcvd" or "whitelist_from_spf".  Not to mention that it 
also affects most of the DNS blacklist checks.



Daryl

Re: trusted_networks use

[Matt Kettler]

NFN Smith wrote:
> Bowie Bailey wrote:
> 
> 
>>>
>>> Thus, if I'm running SpamAssassin on server xx.yy.zz.ww, and I get a
>>> message from server aa.bb.cc.dd, I want both servers to trust each
>>> other, because I control both servers, and there's no intermediate
>>> relay between the two.
>>
>>
>>
>> Then you just need to add one line to the config on each server.
>>
>> On server "xx.yy.zz.ww":
>> trusted_networks aa.bb.cc.dd
>>
>> On server "aa.bb.cc.dd"
>> trusted_networks xx.yy.zz.ww
> 
> 
> This is exactly what I'm doing.  Yet when I send a spammy test message
> from a server whose IP address is one that's specified by
> trusted_networks, the message is getting a full SA score. 

That's exactly what should happen.

trusted_networks is NOT a whitelist.

Trust here means trusted to not forge headers, it does not mean that trusted to
be spam free, and is not a "get out of spam scanning free" ticket.

Re: trusted_networks use

[NFN Smith]

Bowie Bailey wrote:




Thus, if I'm running SpamAssassin on server xx.yy.zz.ww, and I get a
message from server aa.bb.cc.dd, I want both servers to trust each
other, because I control both servers, and there's no intermediate
relay between the two.



Then you just need to add one line to the config on each server.

On server "xx.yy.zz.ww":
trusted_networks aa.bb.cc.dd

On server "aa.bb.cc.dd"
trusted_networks xx.yy.zz.ww


This is exactly what I'm doing.  Yet when I send a spammy test message 
from a server whose IP address is one that's specified by 
trusted_networks, the message is getting a full SA score.  I have 
verified on the target server that IP address specified by 
trusted_networks is the same one shown by the sending server, both from 
a "relay=" line in the mail logs, and the top Received: line in the 
received message.




With these settings, they will each see the other as trusted.  Take a
look at the trusted_networks description on the
Mail::SpamAssassin::Conf man page for more details.


I've checked that one several times, but I don't see anything obvious 
over what I'm already doing.


Is there any way of tracing the behavior, to see what's expected and how 
things aren't matching when a message actually comes through?







If that doesn't get me where I need to go, I'll see about what I can
do about bypassing SpamAssassin checks for known trusted servers in
MIMEDefang, as suggested by another poster in this thread.



That's another possibility if you really trust those servers not to
relay any spam.  The trusted_networks setting does not give quite that
level of trust.


Still something to consider.  In this case, the servers in question are 
really trusted.


Is there something else I might be missing?

Thanks for your help.

Smith

RE: trusted_networks use

[Bowie Bailey]

From: NFN Smith [mailto:[EMAIL PROTECTED]
> 
> Bowie Bailey wrote:
> > 
> > Trusted_networks has nothing to do with whether or not a message
> > is scanned for spam.  Trusted_networks is simply a list of the
> > servers and networks that you trust not to forge header
> > information.
> 
> OK.  On this particular situation, what I'm trying to do is
> designate several other server/network/IP addresses as trusted.
> Because the servers reside in several different co-lo facilities,
> the IP addresses are from unrelated external networks, not on a
> local subnet.
> 
> Thus, if I'm running SpamAssassin on server xx.yy.zz.ww, and I get a
> message from server aa.bb.cc.dd, I want both servers to trust each
> other, because I control both servers, and there's no intermediate
> relay between the two.

Then you just need to add one line to the config on each server.

On server "xx.yy.zz.ww":
trusted_networks aa.bb.cc.dd

On server "aa.bb.cc.dd"
trusted_networks xx.yy.zz.ww

With these settings, they will each see the other as trusted.  Take a
look at the trusted_networks description on the
Mail::SpamAssassin::Conf man page for more details.

> > If all of the servers a message passes through are in your
> > trusted_networks list, then the ALL_TRUSTED rule will fire and
> > lower the score.  Otherwise, it has no direct effect on the spam
> > score.  It does, however, take a large role in much of the header
> > processing that SA does, so it is in your best interest to keep it
> > accurate.
> 
> I'll take a look that the ALL_TRUSTED rule, and see how that behaves.

There's really nothing to look at.  It just checks the headers against
your trusted_networks and if all of the headers match, the rule fires.

> If that doesn't get me where I need to go, I'll see about what I can
> do about bypassing SpamAssassin checks for known trusted servers in
> MIMEDefang, as suggested by another poster in this thread.

That's another possibility if you really trust those servers not to
relay any spam.  The trusted_networks setting does not give quite that
level of trust.

This is what the man page says about the use of trusted_networks:

Trusted in this case means that relay hosts on these networks are
considered to not be potentially operated by spammers, open
relays, or open proxies.  A trusted host could conceivably relay
spam, but will not originate it, and will not forge header data.
DNS blacklist checks will never query for hosts on these networks.

MXes for your domain(s) and internal relays should also be
specified using the "internal_networks" setting. When there are
'trusted' hosts that are not MXes or internal relays for your
domain(s) they should only be specified in "trusted_networks".

Bowie

Re: trusted_networks use

[NFN Smith]

Bowie Bailey wrote:

From: NFN Smith [mailto:[EMAIL PROTECTED]




Trusted_networks has nothing to do with whether or not a message is
scanned for spam.  Trusted_networks is simply a list of the servers
and networks that you trust not to forge header information.


OK.  On this particular situation, what I'm trying to do is designate 
several other server/network/IP addresses as trusted.  Because the 
servers reside in several different co-lo facilities, the IP addresses 
are from unrelated external networks, not on a local subnet.


Thus, if I'm running SpamAssassin on server xx.yy.zz.ww, and I get a 
message from server aa.bb.cc.dd, I want both servers to trust each 
other, because I control both servers, and there's no intermediate relay 
between the two.




If all of the servers a message passes through are in your
trusted_networks list, then the ALL_TRUSTED rule will fire and lower
the score.  Otherwise, it has no direct effect on the spam score.  It
does, however, take a large role in much of the header processing that
SA does, so it is in your best interest to keep it accurate.


I'll take a look that the ALL_TRUSTED rule, and see how that behaves.

If that doesn't get me where I need to go, I'll see about what I can do 
about bypassing SpamAssassin checks for known trusted servers in 
MIMEDefang, as suggested by another poster in this thread.



Smith

RE: trusted_networks use

[Bowie Bailey]

From: NFN Smith [mailto:[EMAIL PROTECTED]
> 
> This might be one of those small "duh" things, but there's something
> I'm missing here.
> 
> I'm running SpamAssassin 2.6, being launched from MIMEDefang as a
> sendmail milter.
> 
> I have several servers and domains in a number of different IP
> blocks (i.e., hosted at different co-lo providers).  I want to make
> sure messages between our users aren't tagged by SA, and for the
> moment, I have whitelist_from directives, listing each of our
> domains.
> 
> The difficulty with this, of course, is incoming mail with forged
> return addresses that show our domains.
> 
> Since our users all send from known IP addresses, I prefer to trust
> by known server IP address, rather than named domain.
> 
> I've found the trusted_networks setting, but when I apply a block of
> IP addresses (and restart MIMEDefang), and then send a spammy test
> message from a server in the specified block, the message still is
> being evaluated by SA as spam.
> 
> Thus, it appears that SA is ignoring my designation of
> trusted_networks.  Is there something else that I have to make sure
> is enabled (such as skip_rbl_checks), is it something that's not
> functional when I'm running from MIMEDefang, or something else that
> I'm missing?

Trusted_networks has nothing to do with whether or not a message is
scanned for spam.  Trusted_networks is simply a list of the servers
and networks that you trust not to forge header information.

If all of the servers a message passes through are in your
trusted_networks list, then the ALL_TRUSTED rule will fire and lower
the score.  Otherwise, it has no direct effect on the spam score.  It
does, however, take a large role in much of the header processing that
SA does, so it is in your best interest to keep it accurate.

Bowie

RE: trusted_networks use

[Matthew.van.Eerde]

NFN Smith wrote:
> Since our users all send from known IP addresses, I prefer to trust by
> known server IP address, rather than named domain.
> 
> I've found the trusted_networks setting, but when I apply a block of
> IP addresses (and restart MIMEDefang), and then send a spammy test
> message from a server in the specified block, the message still is
> being evaluated by SA as spam.

That's not what trusted_networks is for.

If I were in your situation, I'd put code into mimedefang-filter's filter_end 
to bypass the SpamAssassin check if $RelayAddr eq "1.2.3.4" # substitute your 
IPs

-- 
Matthew.van.Eerde (at) hbinc.com   805.964.4554 x902
Hispanic Business Inc./HireDiversity.com   Software Engineer

Re: trusted_networks use

[Mike Beal]

My understanding is that trusted_networks only tells SA where the email
entered your control, and has nothing to do with categorizing email as
spam/ham. Wasn't there an email to this effect a couple of days ago? I
don't remember what that thread was about, however.

>>> NFN Smith <[EMAIL PROTECTED]> 9/16/2005 9:05 AM >>>
This might be one of those small "duh" things, but there's something
I'm
missing here.

I'm running SpamAssassin 2.6, being launched from MIMEDefang as a
sendmail milter.

I have several servers and domains in a number of different IP blocks
(i.e., hosted at different co-lo providers).  I want to make sure
messages between our users aren't tagged by SA, and for the moment, I
have whitelist_from directives, listing each of our domains.

The difficulty with this, of course, is incoming mail with forged
return
addresses that show our domains.

Since our users all send from known IP addresses, I prefer to trust by
known server IP address, rather than named domain.

I've found the trusted_networks setting, but when I apply a block of
IP
addresses (and restart MIMEDefang), and then send a spammy test
message
from a server in the specified block, the message still is being
evaluated by SA as spam.

Thus, it appears that SA is ignoring my designation of
trusted_networks.
  Is there something else that I have to make sure is enabled (such as
skip_rbl_checks), is it something that's not functional when I'm
running
from MIMEDefang, or something else that I'm missing?

TIA,

Smith

trusted_networks use

[NFN Smith]

This might be one of those small "duh" things, but there's something I'm
missing here.

I'm running SpamAssassin 2.6, being launched from MIMEDefang as a
sendmail milter.

I have several servers and domains in a number of different IP blocks
(i.e., hosted at different co-lo providers).  I want to make sure
messages between our users aren't tagged by SA, and for the moment, I
have whitelist_from directives, listing each of our domains.

The difficulty with this, of course, is incoming mail with forged return
addresses that show our domains.

Since our users all send from known IP addresses, I prefer to trust by
known server IP address, rather than named domain.

I've found the trusted_networks setting, but when I apply a block of IP
addresses (and restart MIMEDefang), and then send a spammy test message
from a server in the specified block, the message still is being
evaluated by SA as spam.

Thus, it appears that SA is ignoring my designation of trusted_networks.
 Is there something else that I have to make sure is enabled (such as
skip_rbl_checks), is it something that's not functional when I'm running
from MIMEDefang, or something else that I'm missing?

TIA,

Smith