Re: [SAtalk] SpamAssassin checks on Received headers (and RBL's such as RCVD_IN_SORBS)
At 04:33 PM 1/20/04 +0100, Ralf Vitasek wrote: i tested many things with the trusted users settings and googled around but i had no luck so far. except that i stumbled on a posting from this lists archive that makes me think that something is broken and that it would be fixed in the upcoming 2.7 version of SA. i can't say i fully understand the concept of the trusted_networks and when it is supposed to perform the RBL checks. Theoreticaly trusted_networks should have nothing to do with it. It's an unrelated setting, with an unrelated behavior. However, this is a bug we are talking about, and bugs are strange at times. However most people afflicted with this bug are fixed by declaring a trusted_networks (note this is NOT just nated servers. Multi-IPed servers are affected sometimes too, and other non-simple setups) . As a work-around, just TRY it.. Just add this to your local.cf trusted_networks 1.1.1.1/32 Replace 1.1.1.1 with the IP address of your mailserver (yes, this IS going to be one of the IP addresses of one of the interfaces on the machine running SA in most cases) It's not a proper fix, as you shouldn't need to declare a trusted_networks unless you're using multiple hops in your own network. However it's not going to break your config, theoreticaly trusted_networks should contain this information automatically, you're just forcing it. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
Re: [SAtalk] SpamAssassin checks on Received headers (and RBL's such as RCVD_IN_SORBS)
At 09:02 PM 1/19/04 +0100, Anders Sveen wrote: I'm actually listed because it originates from a dynamic ip-range. Nothing more. It surprises me that they lists ip's for only beeing dynamic, but then I discovered the way RBLs are being used by mailservers and then it actually made sense. It doesn't make sense the way SA uses it. :) Actualy the way SA uses it does make perfect sense, but you've overlooked one detail. You believe that SA checks all IPs against ALL rbls.. That's not true.. It checks most RBLs against all IP addresses, but a few (ie: dynablock) are configured with notfirsthop, causing them to skip the first IP in the list. However, the root-rule, RCVD_IN_SORBS, must be run against them all, because some of the sub-tests are not based on dynamic listings. This is why RCVD_IN_SORBS has almost no score to it. RCVD_IN_DYNABLOCK (a sorbs-based-test) won't match when the mail is relayed properly. (note: all of the above assumes that spamassassin is configured properly. MANY mail system admins have problems with SA and have failed to insert their own server's IP address into trusted_networks when they need to. Note that this is their server, not the dialup ISP's server.. SA must trust itself for notfirsthop to work. SA tries, but some network configs (ie: nat) cause SA to fail to trust even localhost) --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
Re: [SAtalk] SpamAssassin checks on Received headers (and RBL's such as RCVD_IN_SORBS)
Matt Kettler wrote: At 09:02 PM 1/19/04 +0100, Anders Sveen wrote: I'm actually listed because it originates from a dynamic ip-range. Nothing more. It surprises me that they lists ip's for only beeing dynamic, but then I discovered the way RBLs are being used by mailservers and then it actually made sense. It doesn't make sense the way SA uses it. :) Actualy the way SA uses it does make perfect sense, but you've overlooked one detail. You believe that SA checks all IPs against ALL rbls.. That's not true.. It checks most RBLs against all IP addresses, but a few (ie: dynablock) are configured with notfirsthop, causing them to skip the first IP in the list. However, the root-rule, RCVD_IN_SORBS, must be run against them all, because some of the sub-tests are not based on dynamic listings. This is why RCVD_IN_SORBS has almost no score to it. RCVD_IN_DYNABLOCK (a sorbs-based-test) won't match when the mail is relayed properly. (note: all of the above assumes that spamassassin is configured properly. MANY mail system admins have problems with SA and have failed to insert their own server's IP address into trusted_networks when they need to. Note that this is their server, not the dialup ISP's server.. SA must trust itself for notfirsthop to work. SA tries, but some network configs (ie: nat) cause SA to fail to trust even localhost) i currently have trouble getting RBL checks to work on my mailserver too. whenever i activate those checks any mail that's sent from dialup ip's are marked with the DYNABLOCK rule. and i don't mean they we're sent from dialup-ip mailservers, no they we're properly relayed through either my own mailserver(s) or their ISP's legit servers. i tested many things with the trusted users settings and googled around but i had no luck so far. except that i stumbled on a posting from this lists archive that makes me think that something is broken and that it would be fixed in the upcoming 2.7 version of SA. i can't say i fully understand the concept of the trusted_networks and when it is supposed to perform the RBL checks. here's an excerpt SA output from one of my mails: debug: received-header: relay (my mailservers ip) trusted? yes debug: received-header: relay (users dialup ip) trusted? no all mailchecks had been performed on that mail so it was squashed by SA. but from what i've learned the ip from the first received line shouldn't have been checked which would have resulted that the mail came from a trusted network. is it ture that there is some problem with SA's code or do i just have broken config? thanks for your help ralf --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
RE: [SAtalk] SpamAssassin checks on Received headers (and RBL's such as RCVD_IN_SORBS)
Morning Ralf. Matt has a problem that I think is specifically caused because his server is Nated. He had to add the private network to his trusted networks list. I don't have that problem, and Theo acknowleges that there is a bug that should be fixed in 2.70. I haven't heard a definite schedule for that fix, but I see the same problem you have. In addition to that I had previously pointed out, that even first headers should be ignored if they are authenticated. An authenticated client on my server should be implicitly trusted reguardless of source IP, otherwise my own local mail to myself gets hit with dynablock as well. m/ i currently have trouble getting RBL checks to work on my mailserver too. whenever i activate those checks any mail that's sent from dialup ip's are marked with the DYNABLOCK rule. and i don't mean they we're sent from dialup-ip mailservers, no they we're properly relayed through either my own mailserver(s) or their ISP's legit servers. i tested many things with the trusted users settings and googled around but i had no luck so far. except that i stumbled on a posting from this lists archive that makes me think that something is broken and that it would be fixed in the upcoming 2.7 version of SA. i can't say i fully understand the concept of the trusted_networks and when it is supposed to perform the RBL checks. here's an excerpt SA output from one of my mails: debug: received-header: relay (my mailservers ip) trusted? yes debug: received-header: relay (users dialup ip) trusted? no all mailchecks had been performed on that mail so it was squashed by SA. but from what i've learned the ip from the first received line shouldn't have been checked which would have resulted that the mail came from a trusted network. is it ture that there is some problem with SA's code or do i just have broken config? thanks for your help ralf --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
Re: [SAtalk] SpamAssassin checks on Received headers (and RBL's such as RCVD_IN_SORBS)
I'm actually listed because it originates from a dynamic ip-range. Nothing more. It surprises me that they lists ip's for only beeing dynamic, but then I discovered the way RBLs are being used by mailservers and then it actually made sense. It doesn't make sense the way SA uses it. :) I'm aware it's not a bug or anything, but it can cause problems when SA uses the lists in other ways then they were intended to. Anders, Matt Kettler wrote: At 11:22 PM 1/18/04 +0100, PieterB wrote: However, listing in a single RBL really shouldn't cause you any significant problems communicating with people who use SA. The threshold is 5.0 and for example, the person you linked to was complaining about RCVD_IN_SORBS. SORBS is a very low collateral damage list. The person posting is likely listed because his/her source IP is a zombie (ie: stolen or transferred in an illegal manner) or it's a got an open proxy on it. If it's got an open proxy, they can fix it and submit the IP for retesting.. if the IP address is stolen and listed in the zombie block, they should be VERY wary of their ISP. They've obviously been buying IP blocks on the grey/black market. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
Re: [SAtalk] SpamAssassin checks on Received headers (and RBL's such as RCVD_IN_SORBS)
At 11:22 PM 1/18/04 +0100, PieterB wrote: What's the best practice preventing this? Changing SpamAssassin in some way, masquerading/munging Received-headers, or something else? 1) work with the RBL to get de-listed 2) change ISPs to move your IP to a different block. And that's about it.. The fact that SA notices that a source IP is listed, even though you use a legitimate mail relay, is NOT a bug. It's intentionally designed to do that. However, listing in a single RBL really shouldn't cause you any significant problems communicating with people who use SA. The threshold is 5.0 and for example, the person you linked to was complaining about RCVD_IN_SORBS. SORBS is a very low collateral damage list. The person posting is likely listed because his/her source IP is a zombie (ie: stolen or transferred in an illegal manner) or it's a got an open proxy on it. If it's got an open proxy, they can fix it and submit the IP for retesting.. if the IP address is stolen and listed in the zombie block, they should be VERY wary of their ISP. They've obviously been buying IP blocks on the grey/black market. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
Re: [SAtalk] SpamAssassin checks on Received headers (and RBL's such as RCVD_IN_SORBS)
On Sun, 18 Jan 2004, Matt Kettler wrote: snip.. 1) work with the RBL to get de-listed 2) change ISPs to move your IP to a different block. And that's about it.. The fact that SA notices that a source IP is listed, even though you use a legitimate mail relay, is NOT a bug. It's intentionally designed to do that. However, listing in a single RBL really shouldn't cause you any significant problems communicating with people who use SA. The threshold is 5.0 and for example, the person you linked to was complaining about RCVD_IN_SORBS. SORBS is a very low collateral damage list. The person posting is likely listed because his/her source IP is a zombie (ie: stolen or transferred in an illegal manner) or it's a got an open proxy on it. If it's got an open proxy, they can fix it and submit the IP for retesting.. if the IP address is stolen and listed in the zombie block, they should be VERY wary of their ISP. They've obviously been buying IP blocks on the grey/black market. My ip is listed in SORBS for the simple reason that it is in a dynamic block of addresses administered by my ISP. SORBS just states that I should use my ISP mail server which I already do. Since SORBS only adds 0.10 to the spamassassin total I'm not concerned. DynaBlock was adding 4.00 and if I remember correctly spamassassin had a problem where it was ignoring the fact that I was using my ISP's server. -- Gerry The lyfe so short, the craft so long to learne Chaucer --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
Re: [SAtalk] SpamAssassin checks on Received headers (and RBL's such as RCVD_IN_SORBS)
At 08:23 PM 1/18/04 -0500, Gerry Doris wrote: My ip is listed in SORBS for the simple reason that it is in a dynamic block of addresses administered by my ISP. SORBS just states that I should use my ISP mail server which I already do. Since SORBS only adds 0.10 to the spamassassin total I'm not concerned. Aye, and it's a byproduct of the SORBS system now having a dynamic IP list as a part of their overall list (dynablock). RCVD_IN_SORBS just means your IP is listed in any one of the lists.. that's why the score is so low. The actual point-hit is supposed to come from a specific list rule. DynaBlock was adding 4.00 and if I remember correctly spamassassin had a problem where it was ignoring the fact that I was using my ISP's server. That is a bug. SA is supposed to skip dynablock checks on the first IP.. Anyone who's copy of SA is incorrectly checking dynablock against the originating hop needs to set a trusted_networks statement by hand to work around the issue. (From what I've read in bugzilla the actual bug has to do with SA's automatic assessment of trusted_networks getting confused and declaring that there are no trustable servers, not even the local IP. Typicaly happens for servers that are NATed or otherwise inside a private network with a 10.*, 192.168.* or other non-routable IP address) --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
RE: [SAtalk] SpamAssassin checks on Received headers (and RBL's such as RCVD_IN_SORBS)
DynaBlock was adding 4.00 and if I remember correctly spamassassin had a problem where it was ignoring the fact that I was using my ISP's server. That is a bug. SA is supposed to skip dynablock checks on the first IP.. Anyone who's copy of SA is incorrectly checking dynablock against the originating hop needs to set a trusted_networks statement by hand to work around the issue. (From what I've read in bugzilla the actual bug has to do with SA's automatic assessment of trusted_networks getting confused and declaring that there are no trustable servers, not even the local IP. Typicaly happens for servers that are NATed or otherwise inside a private network with a 10.*, 192.168.* or other non-routable IP address) Problem with this fix is it only fixes things for my users locally - when my users send mail to someone else, they would have to set the same networks as trusted. If this isn't fixed soon, it will probably result in people lowering the score, which will make the test less effective when it is fixed. Just my 2 pennies. m/ --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
RE: [SAtalk] SpamAssassin checks on Received headers (and RBL's such as RCVD_IN_SORBS)
You remember correctly. I posted this bug report and Theo said a fix is pending in 2.70 - I don't know how many messages that will cause to go missing in the meantime - not sure how big a problem it is OR how they prioritize those things... Personally I'm with you - I think it's a BIG problem with the default threshold being 5, a 4.0 goes a long way towards spam: Theo said this at 4:42 On Sat, Jan 17, 2004 at 04:39:00PM -0800, Mitch (WebCob) wrote: Hey Theo - does this fix this bug as well? Don't see it updated in the bug list, so thought I'd check. http://bugzilla.spamassassin.org/show_bug.cgi?id=2906 Nope, that's a 2.70 milestone bug currently. no one else had really responded much to my conern, maybe once a few more people notice the problem it will be given more attention. m/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Gerry Doris Sent: Sunday, January 18, 2004 5:24 PM To: Matt Kettler Cc: [EMAIL PROTECTED] Subject: Re: [SAtalk] SpamAssassin checks on Received headers (and RBL's such as RCVD_IN_SORBS) On Sun, 18 Jan 2004, Matt Kettler wrote: snip.. 1) work with the RBL to get de-listed 2) change ISPs to move your IP to a different block. And that's about it.. The fact that SA notices that a source IP is listed, even though you use a legitimate mail relay, is NOT a bug. It's intentionally designed to do that. However, listing in a single RBL really shouldn't cause you any significant problems communicating with people who use SA. The threshold is 5.0 and for example, the person you linked to was complaining about RCVD_IN_SORBS. SORBS is a very low collateral damage list. The person posting is likely listed because his/her source IP is a zombie (ie: stolen or transferred in an illegal manner) or it's a got an open proxy on it. If it's got an open proxy, they can fix it and submit the IP for retesting.. if the IP address is stolen and listed in the zombie block, they should be VERY wary of their ISP. They've obviously been buying IP blocks on the grey/black market. My ip is listed in SORBS for the simple reason that it is in a dynamic block of addresses administered by my ISP. SORBS just states that I should use my ISP mail server which I already do. Since SORBS only adds 0.10 to the spamassassin total I'm not concerned. DynaBlock was adding 4.00 and if I remember correctly spamassassin had a problem where it was ignoring the fact that I was using my ISP's server. -- Gerry The lyfe so short, the craft so long to learne Chaucer --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
RE: [SAtalk] SpamAssassin checks on Received headers (and RBL's such as RCVD_IN_SORBS)
At 05:49 PM 1/18/04 -0800, Mitch \(WebCob\) wrote: Problem with this fix is it only fixes things for my users locally - when my users send mail to someone else, they would have to set the same networks as trusted. This is untrue.. What ALL affected admins must do is set trusted_networks to is _their own_ server.. not having anything to do with the source. Of course, you can't fix other people's broken servers, but they do NOT need to enter your IP to fix the dynablock mislisting bug. ie: at my work xanadu.evi-inc.com was tripping dynablock on messages from my comcast account.. xanadu is a NAT'ed server. I had to add the following line to xanadu's local.cf to stop the misfire. (note here is 192.168.xx.xx is the IP address of xanadu's ethernet interface, which static maps to a public IP as it goes through a NAT router). trusted_networks 192.168.xx.xx/32 That's got nothing to do with trusting any of comcast's IPs.. and applying that one line fixed _all_ the mis-checked dynablocks. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
RE: [SAtalk] SpamAssassin checks on Received headers (and RBL's such as RCVD_IN_SORBS)
Your missing the case where the mail is not coming from a private network or a nated server. I experience this problem (as mentioned in the bug report) from roaming users who are connecting through authenticated SMTP to their mail server, and relaying to me. I'd have to trust all the IP pools of every dynamic user - or the network of every SMTP server of every trusted network. This would potentially be hundreds of networks... None of these servers are nated - the IP causing the problem is the IP of the original message submitter - not the relaying server, but even if trusting the IP of the relaying server works I'd still have to track all of them down - yes? Or am I missing something? m/ -Original Message- From: Matt Kettler [mailto:[EMAIL PROTECTED] Sent: Sunday, January 18, 2004 7:54 PM To: Mitch (WebCob); Gerry Doris Cc: [EMAIL PROTECTED] Subject: RE: [SAtalk] SpamAssassin checks on Received headers (and RBL's such as RCVD_IN_SORBS) At 05:49 PM 1/18/04 -0800, Mitch \(WebCob\) wrote: Problem with this fix is it only fixes things for my users locally - when my users send mail to someone else, they would have to set the same networks as trusted. This is untrue.. What ALL affected admins must do is set trusted_networks to is _their own_ server.. not having anything to do with the source. Of course, you can't fix other people's broken servers, but they do NOT need to enter your IP to fix the dynablock mislisting bug. ie: at my work xanadu.evi-inc.com was tripping dynablock on messages from my comcast account.. xanadu is a NAT'ed server. I had to add the following line to xanadu's local.cf to stop the misfire. (note here is 192.168.xx.xx is the IP address of xanadu's ethernet interface, which static maps to a public IP as it goes through a NAT router). trusted_networks 192.168.xx.xx/32 That's got nothing to do with trusting any of comcast's IPs.. and applying that one line fixed _all_ the mis-checked dynablocks. --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
Re: [SAtalk] SpamAssassin checks on Received headers (and RBL's such as RCVD_IN_SORBS)
Mitch (WebCob) wrote: Your missing the case where the mail is not coming from a private network or a nated server. I experience this problem (as mentioned in the bug report) from roaming users who are connecting through authenticated SMTP to their mail server, and relaying to me. I'd have to trust all the IP pools of every dynamic user - or the network of every SMTP server of every trusted network. This would potentially be hundreds of networks... None of these servers are nated - the IP causing the problem is the IP of the original message submitter - not the relaying server, but even if trusting the IP of the relaying server works I'd still have to track all of them down - yes? Or am I missing something? m/ Please don't top post. No, you're not missing anything. This is a known bug in SA 2.6X. People saying to add your IP to trusted_networks are not getting it. It's a bug, it's been proven, the only way around it is to disable or severly lower the test score at this time. 2.7X is supposed to fix the problem. I also experience this problem on a non-natted machine. Adding the machines IP to trusted networks has absolutely no bearing on this test triggering. It hits on the first received header, and unless there is only 1 received header, that is NOT supposed to happen. Hopefully 2.7X is close to being finished. Chris --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
