RE: RBL Rules Misfiring

2006-09-07 Thread Bowie Bailey 
Daryl C. W. O'Shea wrote:
> [sent to just me, BTW]

Must have hit the wrong reply button...

> Bowie Bailey wrote:
> > Daryl C. W. O'Shea wrote:
> > > Bowie Bailey wrote:
> > > 
> > > > You should also list any other mail servers that accept mail for
> > > > your domain.  This includes email gateways and relays under your
> > > > control. This can also include your ISP's mailservers, but if
> > > > you do that, make sure to specify internal_networks separately
> > > > and leave the ISP's servers out of that one.
> > > Your ISP's mail servers, if they are accepting mail on your
> > > behalf, need to be included in your internal_networks too.
> > > 
> > > ANY server from an MX accepting mail on your behalf all the way to
> > > your SA machine need to be both trusted and internal.
> > 
> > An ISP's mailserver frequently also accepts direct connections from
> > their user's dialup systems.  You can only put them in the internal
> > list if you are sure they don't do this or if they include the
> > authentication info in the received header.  Otherwise, you will get
> > RBL hits (from the dialup IP lists) on any email from the ISP's
> > other customers.
> 
> Nope, you still need to include them in internal_networks, otherwise
> tests that rely on knowing exactly where the hand off from the sender
> to the receiver is won't work (like SPF based whitelists) and will
> probably trigger FPs (like SPF_FAIL).
> 
> If an ISP is small enough that is uses the same server for MSA and MX
> functions then they're most certainly small enough that you can easily
> include their entire netblocks in trusted/internal networks too.
> 
> Again, if you want SA to function (the most) correctly, you need to
> include all hosts from your MX to the SA machine in trusted and
> internal networks.

>From the man page:
Trusted relays that accept mail directly from dial-up connections
should not be listed in "internal_networks". List them only in
"trusted_networks".

And the caveat that is not in the man page:
... unless all MSA traffic is authenticated and the authentication
information is in the headers.

My point was simply that you need to be careful.  Since that server is
not under your control, you need to make sure you know what it is
doing so you know the right place to list it.

-- 
Bowie

Re: RBL Rules Misfiring

2006-09-05 Thread Daryl C. W. O'Shea 

Bowie Bailey wrote:


You should also list any other mail servers that accept mail for your
domain.  This includes email gateways and relays under your control.
This can also include your ISP's mailservers, but if you do that, make
sure to specify internal_networks separately and leave the ISP's
servers out of that one.


Your ISP's mail servers, if they are accepting mail on your behalf, need 
to be included in your internal_networks too.


ANY server from an MX accepting mail on your behalf all the way to your 
SA machine need to be both trusted and internal.



Daryl

RE: RBL Rules Misfiring

2006-09-05 Thread Bowie Bailey 
D.J. wrote:
> D.J. wrote:
> > OK, after Googling around for a bit, I may have stumbled on
> > something... specifically this trust path thing.  I had my
> > trusted_networks and internal_networks set as my SMTP's and MX's
> > class C network.  Because of that, is that causing SA to look at the
> > relay beyond the trusted network as the agent to compare the RBL to? 
> > Come to think of it, this didn't appear (or at least wasn't reported
> > to me) before I set those values.  At any rate, I've completely
> > removed the internal_networks value, and changed the trusted values
> > variable to 127.0.0.1.  Eventually this will be behind a NAT machine,
> > so I have to set *something*.  If anyone thinks I'm on the right
> > path, let me know.  I'm also going to continue monitoring for this
> > problem, so if it goes away now, I'll let the list know for
> > posterity's sake.  Thanks!
> > 
> > 
> > - D.J.
> 
> The problem has indeed ceased since changing the setting.  At first
> it didn't quite make sense to me as to why it was working the way it
> was, but I guess it makes perfect sense if you sit and think about
> it.  A lesson for those who don't know, you never want your MX server
> to be a "trusted server" or you may have rules firing that shouldn't
> ;-) 

That doesn't sound quite right, but it may just be differing terminology.

The mailserver doing the SA checks should have all of its IP addresses
(internal and external) listed in trusted_networks.  Otherwise, it may
do RBL checks against itself, which is obviously not desired behavior
and can cause major problems if it does get listed.

You should also list any other mail servers that accept mail for your
domain.  This includes email gateways and relays under your control.
This can also include your ISP's mailservers, but if you do that, make
sure to specify internal_networks separately and leave the ISP's
servers out of that one.

Also, any server that receives mail from end-users on dialup/DSL/Cable
connections should be listed only in trusted_networks, and not in
internal_networks.

Check the wiki, if you haven't already.  Most of the good stuff is
under the heading "How can I optimize the trusted_networks setting?"
http://wiki.apache.org/spamassassin/TrustPath

Also, keep in mind that you are not trusting these servers not to
forward spam, you are simply trusting them not to put false
information in the mail headers.

-- 
Bowie

Re: RBL Rules Misfiring

2006-09-05 Thread Daryl C. W. O'Shea 

D.J. wrote:

OK, after Googling around for a bit, I may have stumbled on
something... specifically this trust path thing.  I had my
trusted_networks and internal_networks set as my SMTP's and MX's
class C network.  Because of that, is that causing SA to look at the
relay beyond the trusted network as the agent to compare the RBL
to?  Come to think of it, this didn't appear (or at least wasn't
reported to me) before I set those values.  At any rate, I've
completely removed the internal_networks value, and changed the
trusted values variable to 127.0.0.1 .  Eventually
this will be behind a NAT machine, so I have to set *something*.  If
anyone thinks I'm on the right path, let me know.  I'm also going to
continue monitoring for this problem, so if it goes away now, I'll
let the list know for posterity's sake.  Thanks!

- D.J.



The problem has indeed ceased since changing the setting.  At first it 
didn't quite make sense to me as to why it was working the way it was, 
but I guess it makes perfect sense if you sit and think about it.  A 
lesson for those who don't know, you never want your MX server to be a 
"trusted server" or you may have rules firing that shouldn't ;-)


That's incorrect.  You always want your MX to be trusted.  SA will then 
check the IP that connects to your MX against most RBLs.  Regardless, 
there are a few RBLs that SA will check all IPs against.  Debug info 
makes it clear what exactly is being checked.


Daryl

Re: RBL Rules Misfiring

2006-09-05 Thread D . J . 
OK, after Googling around for a bit, I may have stumbled on something... specifically this trust path thing.  I had my trusted_networks and internal_networks set as my SMTP's and MX's class C network.  Because of that, is that causing SA to look at the relay beyond the trusted network as the agent to compare the RBL to?  Come to think of it, this didn't appear (or at least wasn't reported to me) before I set those values.  At any rate, I've completely removed the internal_networks value, and changed the trusted values variable to 
127.0.0.1.  Eventually this will be behind a NAT machine, so I have to set *something*.  If anyone thinks I'm on the right path, let me know.  I'm also going to continue monitoring for this problem, so if it goes away now, I'll let the list know for posterity's sake.  Thanks!
- D.J.

The problem has indeed ceased since changing the setting.  At first it didn't quite make sense to me as to why it was working the way it was, but I guess it makes perfect sense if you sit and think about it.  A lesson for those who don't know, you never want your MX server to be a "trusted server" or you may have rules firing that shouldn't ;-)

Re: RBL Rules Misfiring

2006-08-24 Thread D . J . 
On 8/23/06, 
Stuart Johnston <[EMAIL PROTECTED]> wrote:
As a quick guess, you probably need to fix your Trust Path:http://wiki.apache.org/spamassassin/TrustPath
No, I've got that set properly, as I didn't trust the autodiscovery.  So I've already entered the class C for my MX's and SMTP's there for both trusted_networks and internal_networks.


OK, after Googling around for a bit, I may have stumbled on something... specifically this trust path thing.  I had my trusted_networks and internal_networks set as my SMTP's and MX's class C network.  Because of that, is that causing SA to look at the relay beyond the trusted network as the agent to compare the RBL to?  Come to think of it, this didn't appear (or at least wasn't reported to me) before I set those values.  At any rate, I've completely removed the internal_networks value, and changed the trusted values variable to 
127.0.0.1.  Eventually this will be behind a NAT machine, so I have to set *something*.  If anyone thinks I'm on the right path, let me know.  I'm also going to continue monitoring for this problem, so if it goes away now, I'll let the list know for posterity's sake.  Thanks!
- D.J.

Re: RBL Rules Misfiring

2006-08-24 Thread D . J . 
On 8/24/06, D. J. <[EMAIL PROTECTED]> wrote:

D.J. wrote:> Hello all.>> I searched my archive of the list, and couldn't find a similar issue.
> This is probably something I've misconfigured, but here goes.  Running> SA 3.14 via the Mail::SpamAssassin Perl plugin from amavisd-new.  Have> been running into a problem where some dynamic RBL lists are firing just
> because the IP is in the headers, not necessarily because it's the IP> talking to my MTA.  They are indeed IPs in the list but shouldn't be> firing because they're really using their ISP's mail servers as you can
> see later in the headers.  I'm *really* hoping this isn't intended> operation and it's just something I've blundered somehow.  Below is a> piece of one of the message notifications I receive.  I've been watching
> this on a couple small domains I own before putting it on our main one,> and it's a good thing!>> Thanks in advance for the help.>> - D.J.>>> Content analysis details:   (
10.9 points, 5.0 required)>>  pts rule name  description>  --> -->  1.4 MSGID_FROM_MTA_ID  Message-Id for external message added locally
> -0.0 SPF_PASS   SPF: sender matches SPF record>  0.0 HTML_MESSAGE   BODY: HTML included in message>  0.0 BAYES_50   BODY: Bayesian spam probability is 40 to 60%> [score: 
0.4964]>  2.2 RCVD_IN_SORBS_SOCKSRBL: SORBS: sender is open SOCKS proxy server> [
24.140.8.46  listed in> dnsbl.sorbs.net <
http://dnsbl.sorbs.net>]>  2.0 RCVD_IN_SORBS_DUL  RBL: SORBS: sent directly from dynamic IP
> address> [24.140.8.46 <
http://24.140.8.46> listed in> dnsbl.sorbs.net
 ]>  2.6 RCVD_IN_DSBL   RBL: Received via a relay in 
list.dsbl.org> <
http://list.dsbl.org>> []>  0.7 RCVD_IN_NJABL_PROXYRBL: NJABL: sender is an open proxy
> [24.140.8.46 <
http://24.140.8.46> listed in> combined.njabl.org <
http://combined.njabl.org>]>  1.9 RCVD_IN_NJABL_DUL  RBL: NJABL: dialup sender did non-local SMTP
> [24.140.8.46
  listed in> 
combined.njabl.org ]>  
1.8 MISSING_SUBJECTMissing Subject: header> -1.8 AWLAWL: From: address is in the auto white-list>> Return-Path: > Received: from 

smtp-1.sssnet.com > (
nat-147.sssnet.com  [24.140.1.147> <
http://24.140.1.147>])> by test.sssnet.com <

http://test.sssnet.com> (Postfix) with ESMTP> id 663292B803E> for ; Wed, 23 Aug 2006 14:58:41 -0400 (EDT)> Received: (qmail 11376 invoked by uid 507); 23 Aug 2006 18:58:42 -
> Received: from 24.140.8.46 <
http://24.140.8.46> by smtp-1.sssnet.com> <

http://smtp-1.sssnet.com> (envelope-from , uid 501) with> qmail-scanner-1.25st>  (clamdscan: 0.88.2/1715. spamassassin: 3.0.3. perlscan: 1.25st.>  Clear:RC:1(

24.140.8.46 ):SA:0(1.2/14.0):.>  Processed in 0.727458 secs); 23 Aug 2006 18:58:42 -
> X-Spam-Status: No, hits=1.2 required=14.0> X-Spam-Level: +
> Received: from cable-8-46.sssnet.com <
http://cable-8-46.sssnet.com>> (HELO SERVER) ([
24.140.8.46 ])>   (envelope-sender )>   by 0 (
qmail-ldap-1.03) with SMTP>   for ; 23 Aug 2006 18:58:41 -
> From: "Sue Repp" > To: "'Mary Richardson'" > Subject:> Date: Wed, 23 Aug 2006 14:58:53 -0400> MIME-Version: 1.0> Content-Type: multipart/alternative;
> boundary="=_NextPart_000__01C6C6C4.ABD60F20"> X-Mailer: Microsoft Office Outlook, Build 11.0.5510> Thread-Index: AcbG5izxOwnp3dUpR7iOx6AZ33ceQQ==> X-MimeOLE: Produced By Microsoft MimeOLE 
V6.00.2900.2962> X-Qmail-Scanner-Message-ID: <[EMAIL PROTECTED]
> 
[EMAIL PROTECTED]>>> Message-Id: <[EMAIL PROTECTED]
> 
[EMAIL PROTECTED]>>On 8/23/06, Stuart Johnston <
[EMAIL PROTECTED]> wrote:
As a quick guess, you probably need to fix your Trust Path:http://wiki.apache.org/spamassassin/TrustPath
No, I've got that set properly, as I didn't trust the autodiscovery.  So I've already entered the class C for my MX's and SMTP's there for both trusted_networks and internal_networks.

Re: RBL Rules Misfiring

2006-08-23 Thread Stuart Johnston 

As a quick guess, you probably need to fix your Trust Path:

http://wiki.apache.org/spamassassin/TrustPath

D.J. wrote:

Hello all.

I searched my archive of the list, and couldn't find a similar issue.  
This is probably something I've misconfigured, but here goes.  Running 
SA 3.14 via the Mail::SpamAssassin Perl plugin from amavisd-new.  Have 
been running into a problem where some dynamic RBL lists are firing just 
because the IP is in the headers, not necessarily because it's the IP 
talking to my MTA.  They are indeed IPs in the list but shouldn't be 
firing because they're really using their ISP's mail servers as you can 
see later in the headers.  I'm *really* hoping this isn't intended 
operation and it's just something I've blundered somehow.  Below is a 
piece of one of the message notifications I receive.  I've been watching 
this on a couple small domains I own before putting it on our main one, 
and it's a good thing!


Thanks in advance for the help.

- D.J.


Content analysis details:   (10.9 points, 5.0 required)

 pts rule name  description
 -- 
--

 1.4 MSGID_FROM_MTA_ID  Message-Id for external message added locally
-0.0 SPF_PASS   SPF: sender matches SPF record
 0.0 HTML_MESSAGE   BODY: HTML included in message
 0.0 BAYES_50   BODY: Bayesian spam probability is 40 to 60%
[score: 0.4964]
 2.2 RCVD_IN_SORBS_SOCKSRBL: SORBS: sender is open SOCKS proxy server
[24.140.8.46  listed in 
dnsbl.sorbs.net ]
 2.0 RCVD_IN_SORBS_DUL  RBL: SORBS: sent directly from dynamic IP 
address
[24.140.8.46  listed in 
dnsbl.sorbs.net ]
 2.6 RCVD_IN_DSBL   RBL: Received via a relay in list.dsbl.org 


[]
 0.7 RCVD_IN_NJABL_PROXYRBL: NJABL: sender is an open proxy
[24.140.8.46  listed in 
combined.njabl.org ]

 1.9 RCVD_IN_NJABL_DUL  RBL: NJABL: dialup sender did non-local SMTP
[24.140.8.46  listed in 
combined.njabl.org ]

 1.8 MISSING_SUBJECTMissing Subject: header
-1.8 AWLAWL: From: address is in the auto white-list

Return-Path: 
Received: from smtp-1.sssnet.com  
(nat-147.sssnet.com  [24.140.1.147 
])
by test.sssnet.com  (Postfix) with ESMTP 
id 663292B803E

for ; Wed, 23 Aug 2006 14:58:41 -0400 (EDT)
Received: (qmail 11376 invoked by uid 507); 23 Aug 2006 18:58:42 -
Received: from 24.140.8.46  by smtp-1.sssnet.com 
 (envelope-from , uid 501) with 
qmail-scanner-1.25st
 (clamdscan: 0.88.2/1715. spamassassin: 3.0.3. perlscan: 1.25st. 
 Clear:RC:1(24.140.8.46 ):SA:0(1.2/14.0):.

 Processed in 0.727458 secs); 23 Aug 2006 18:58:42 -
X-Spam-Status: No, hits=1.2 required=14.0
X-Spam-Level: +
Received: from cable-8-46.sssnet.com  
(HELO SERVER) ([24.140.8.46 ])

  (envelope-sender )
  by 0 (qmail-ldap-1.03) with SMTP
  for ; 23 Aug 2006 18:58:41 -
From: "Sue Repp" 
To: "'Mary Richardson'" 
Subject:
Date: Wed, 23 Aug 2006 14:58:53 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="=_NextPart_000__01C6C6C4.ABD60F20"
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
Thread-Index: AcbG5izxOwnp3dUpR7iOx6AZ33ceQQ==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Qmail-Scanner-Message-ID: <[EMAIL PROTECTED] 
>
Message-Id: <[EMAIL PROTECTED] 
>