RE: RBL Rules Misfiring
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
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
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 http://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
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
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
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 namedescription -- --1.4 MSGID_FROM_MTA_IDMessage-Id for external message added locally -0.0 SPF_PASS SPF: sender matches SPF record0.0 HTML_MESSAGE BODY: HTML included in message0.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 http://24.140.8.46 listed in dnsbl.sorbs.net http://dnsbl.sorbs.net]2.0 RCVD_IN_SORBS_DULRBL: SORBS: sent directly from dynamic IP address [24.140.8.46 http://24.140.8.46 listed in dnsbl.sorbs.net http://dnsbl.sorbs.net]2.6 RCVD_IN_DSBL RBL: Received via a relay in list.dsbl.org http://list.dsbl.org [http://dsbl.org/listing?24.140.8.46 ]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_DULRBL: NJABL: dialup sender did non-local SMTP [24.140.8.46 http://24.140.8.46 listed in combined.njabl.org http://combined.njabl.org] 1.8 MISSING_SUBJECTMissing Subject: header -1.8 AWLAWL: From: address is in the auto white-list Return-Path: protected Received: from smtp-1.sssnet.com http://smtp-1.sssnet.com ( nat-147.sssnet.com http://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 protected; 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 protected, 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 http://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 http://24.140.8.46]) (envelope-sender protected) by 0 ( qmail-ldap-1.03) with SMTP for protected; 23 Aug 2006 18:58:41 - From: Sue Repp protected To: 'Mary Richardson' protected 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] mailto: [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] mailto: [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
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.
RBL Rules Misfiring
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_SOCKS RBL: 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 [http://dsbl.org/listing?24.140.8.46] 0.7 RCVD_IN_NJABL_PROXY RBL: 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_SUBJECT Missing Subject: header -1.8 AWL AWL: From: address is in the auto white-list Return-Path: protected Received: from smtp-1.sssnet.com (nat-147.sssnet.com [24.140.1.147]) by test.sssnet.com (Postfix) with ESMTP id 663292B803E for protected; 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 protected, 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 protected) by 0 (qmail-ldap-1.03) with SMTP for protected; 23 Aug 2006 18:58:41 - From: Sue Repp protected To: 'Mary Richardson' protected 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]
Re: RBL Rules Misfiring
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 http://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 http://dnsbl.sorbs.net] 2.6 RCVD_IN_DSBL RBL: Received via a relay in list.dsbl.org http://list.dsbl.org [http://dsbl.org/listing?24.140.8.46] 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 http://24.140.8.46 listed in combined.njabl.org http://combined.njabl.org] 1.8 MISSING_SUBJECTMissing Subject: header -1.8 AWLAWL: From: address is in the auto white-list Return-Path: protected Received: from smtp-1.sssnet.com http://smtp-1.sssnet.com (nat-147.sssnet.com http://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 protected; 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 protected, 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 http://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 http://24.140.8.46]) (envelope-sender protected) by 0 (qmail-ldap-1.03) with SMTP for protected; 23 Aug 2006 18:58:41 - From: Sue Repp protected To: 'Mary Richardson' protected 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] mailto:[EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
