Re: surbl not reporting on any incoming email
Yup, this fixed it. There is something wrong with Mandrake dists where /usr/lib/perl5/site_perl gets chmod' to 700 and that is not the proper behavior. This is a v10 -> 10.1 upgraded machine with 5.8.3 upgraded to 5.8.5 in recent days as part of urpmi.update. It looks like the vendor package maintainer decided to chmod all of the 5.8.3 site_perl locations 700 to avoid clashes with 5.8.5 in lieu of deleting the directories outright. Good in theory but he/she just went one dir to high when they did it. That's what I get for patching... Tom Thomas Bolioli wrote: Thanks for the heads up but the problem is starting to look like perl. When I run perl as root I have the same @INC path as when I run non-privileged. However, only as root am I able to find most of the modules in site_perl. When I run as other than root, I can not get access to the modules I need. It appears some permission problems have crept up after doing an update a few days ago. I am in the process of fixing them right now and hopefully that will hold and not get automatically "fixed" by some bots Mandrake has to fixperms on an hourly basis. Thanks, Tom Bob McClure Jr wrote: On Thu, Feb 17, 2005 at 11:58:04AM -0500, Thomas Bolioli wrote: Ok. I created copies of the /etc/resolv.conf file in the user's home dirs and made sure the copies were owned by those users and no go. It is still not executing network tests for any user other than root. Can anybody confirm they are getting network tests performed on a 3.0.0 setup with procmail executing /usr/bin/spamassassin (not a spamc/spamd setup)? I know I have all the correct settings as other emails in this thread can show. Tom Don't know if this relates to your problem. About two weeks ago I started having a lot of spam slipping through, even the obvious C-drug ones. Following a recent posting (may have been yours), I ran the spam through "spamassassin -D" and it scored much higher, even enough to qualify for summary punting, mostly thanks to SURBL scores that weren't in the original scan by spamc/spamd. After some thought, I remembered recently fixing a problem in my /etc/resolv.conf in which a now-dead IP address had been at the top of the list. So I restarted spamd, and now things are once again wonderful. Apparently, spamd reads /etc/resolv.conf at startup and uses only the first entry. If that's busted, forget about all the SURBL stuff. Thomas Bolioli wrote: I had not upgraded from a 2.6x install with Spam Cop. It was a totally stock install and it is still 3.0.0. I have since discovered that when I run spamassassin as any user except root, the network tests do not work. When I run it as root, all the network tests work just fine. I have tried to run network based things as other users before and there does not appear to be any restrictions on network access for those users. I checked /etc/resolve.conf and it is read only to the world and is configured properly. Something may be wrong with Net::DNS::Resolver and it is not seeing the /etc/resolve.conf file when run as other users. This morning's chore is to create links to ~/.resolve.conf for a few users and get it owned by them and see what happens. Will advise. Tom Jeff Chan wrote: On Wednesday, February 16, 2005, 2:25:52 PM, Thomas Bolioli wrote: Hence my problem. >From my local.cf which is not overridden anywhere skip_rbl_checks 0 dns_available yes >From etc/procmailrc SPAMC="/usr/bin/spamassassin" :0f |$SPAMC but the surbl checks only occur when I do spamassassin -t < file_w_msg and not when procmail does the forwarding. I am at a loss. This has never worked since I install 10.1 (SA 3.0.0). SA 2.63/2.64 used a separate patch called SpamCopURI, and SA 3.x uses the built in program urirhssub for SURBL lookups. If you had SpamCopURI before, did you get rid of the it and the rules for it, as you should for 3.X? (3.X versions have SURBL rules set up by default). Did you perhaps upgrade from 3.0.0 to later versions? If so, did you remember to change the rule type from "header" to "body" as mentioned at: http://www.surbl.org/faq.html#body Jeff C. Cheers, smime.p7s Description: S/MIME Cryptographic Signature
Re: surbl not reporting on any incoming email
Thanks for the heads up but the problem is starting to look like perl. When I run perl as root I have the same @INC path as when I run non-privileged. However, only as root am I able to find most of the modules in site_perl. When I run as other than root, I can not get access to the modules I need. It appears some permission problems have crept up after doing an update a few days ago. I am in the process of fixing them right now and hopefully that will hold and not get automatically "fixed" by some bots Mandrake has to fixperms on an hourly basis. Thanks, Tom Bob McClure Jr wrote: On Thu, Feb 17, 2005 at 11:58:04AM -0500, Thomas Bolioli wrote: Ok. I created copies of the /etc/resolv.conf file in the user's home dirs and made sure the copies were owned by those users and no go. It is still not executing network tests for any user other than root. Can anybody confirm they are getting network tests performed on a 3.0.0 setup with procmail executing /usr/bin/spamassassin (not a spamc/spamd setup)? I know I have all the correct settings as other emails in this thread can show. Tom Don't know if this relates to your problem. About two weeks ago I started having a lot of spam slipping through, even the obvious C-drug ones. Following a recent posting (may have been yours), I ran the spam through "spamassassin -D" and it scored much higher, even enough to qualify for summary punting, mostly thanks to SURBL scores that weren't in the original scan by spamc/spamd. After some thought, I remembered recently fixing a problem in my /etc/resolv.conf in which a now-dead IP address had been at the top of the list. So I restarted spamd, and now things are once again wonderful. Apparently, spamd reads /etc/resolv.conf at startup and uses only the first entry. If that's busted, forget about all the SURBL stuff. Thomas Bolioli wrote: I had not upgraded from a 2.6x install with Spam Cop. It was a totally stock install and it is still 3.0.0. I have since discovered that when I run spamassassin as any user except root, the network tests do not work. When I run it as root, all the network tests work just fine. I have tried to run network based things as other users before and there does not appear to be any restrictions on network access for those users. I checked /etc/resolve.conf and it is read only to the world and is configured properly. Something may be wrong with Net::DNS::Resolver and it is not seeing the /etc/resolve.conf file when run as other users. This morning's chore is to create links to ~/.resolve.conf for a few users and get it owned by them and see what happens. Will advise. Tom Jeff Chan wrote: On Wednesday, February 16, 2005, 2:25:52 PM, Thomas Bolioli wrote: Hence my problem. >From my local.cf which is not overridden anywhere skip_rbl_checks 0 dns_available yes >From etc/procmailrc SPAMC="/usr/bin/spamassassin" :0f |$SPAMC but the surbl checks only occur when I do spamassassin -t < file_w_msg and not when procmail does the forwarding. I am at a loss. This has never worked since I install 10.1 (SA 3.0.0). SA 2.63/2.64 used a separate patch called SpamCopURI, and SA 3.x uses the built in program urirhssub for SURBL lookups. If you had SpamCopURI before, did you get rid of the it and the rules for it, as you should for 3.X? (3.X versions have SURBL rules set up by default). Did you perhaps upgrade from 3.0.0 to later versions? If so, did you remember to change the rule type from "header" to "body" as mentioned at: http://www.surbl.org/faq.html#body Jeff C. Cheers, smime.p7s Description: S/MIME Cryptographic Signature
Re: surbl not reporting on any incoming email
I have new info. I changed the dns_available setting to test and I got this. Failed to run DNS_FROM_AHBL_RHSBL RBL SpamAssassin test, skipping: (Can't call method "bgsend" on an undefined value at /usr/lib/perl5/vendor_perl/5.8.5/Mail/SpamAssassin/Dns.pm line 112. ) Failed to run NO_DNS_FOR_FROM RBL SpamAssassin test, skipping: (Can't call method "bgsend" on an undefined value at /usr/lib/perl5/vendor_perl/5.8.5/Mail/SpamAssassin/Dns.pm line 141. ) Failed to run __RFC_IGNORANT_ENVFROM RBL SpamAssassin test, skipping: (Can't call method "bgsend" on an undefined value at /usr/lib/perl5/vendor_perl/5.8.5/Mail/SpamAssassin/Dns.pm line 112. ) Any ideas? Tom Thomas Bolioli wrote: Ok. I created copies of the /etc/resolv.conf file in the user's home dirs and made sure the copies were owned by those users and no go. It is still not executing network tests for any user other than root. Can anybody confirm they are getting network tests performed on a 3.0.0 setup with procmail executing /usr/bin/spamassassin (not a spamc/spamd setup)? I know I have all the correct settings as other emails in this thread can show. Tom Thomas Bolioli wrote: I had not upgraded from a 2.6x install with Spam Cop. It was a totally stock install and it is still 3.0.0. I have since discovered that when I run spamassassin as any user except root, the network tests do not work. When I run it as root, all the network tests work just fine. I have tried to run network based things as other users before and there does not appear to be any restrictions on network access for those users. I checked /etc/resolve.conf and it is read only to the world and is configured properly. Something may be wrong with Net::DNS::Resolver and it is not seeing the /etc/resolve.conf file when run as other users. This morning's chore is to create links to ~/.resolve.conf for a few users and get it owned by them and see what happens. Will advise. Tom Jeff Chan wrote: On Wednesday, February 16, 2005, 2:25:52 PM, Thomas Bolioli wrote: Hence my problem. From my local.cf which is not overridden anywhere skip_rbl_checks 0 dns_available yes From etc/procmailrc SPAMC="/usr/bin/spamassassin" :0f |$SPAMC but the surbl checks only occur when I do spamassassin -t < file_w_msg and not when procmail does the forwarding. I am at a loss. This has never worked since I install 10.1 (SA 3.0.0). SA 2.63/2.64 used a separate patch called SpamCopURI, and SA 3.x uses the built in program urirhssub for SURBL lookups. If you had SpamCopURI before, did you get rid of the it and the rules for it, as you should for 3.X? (3.X versions have SURBL rules set up by default). Did you perhaps upgrade from 3.0.0 to later versions? If so, did you remember to change the rule type from "header" to "body" as mentioned at: http://www.surbl.org/faq.html#body Jeff C. smime.p7s Description: S/MIME Cryptographic Signature
Re: surbl not reporting on any incoming email
Ok. I created copies of the /etc/resolv.conf file in the user's home dirs and made sure the copies were owned by those users and no go. It is still not executing network tests for any user other than root. Can anybody confirm they are getting network tests performed on a 3.0.0 setup with procmail executing /usr/bin/spamassassin (not a spamc/spamd setup)? I know I have all the correct settings as other emails in this thread can show. Tom Thomas Bolioli wrote: I had not upgraded from a 2.6x install with Spam Cop. It was a totally stock install and it is still 3.0.0. I have since discovered that when I run spamassassin as any user except root, the network tests do not work. When I run it as root, all the network tests work just fine. I have tried to run network based things as other users before and there does not appear to be any restrictions on network access for those users. I checked /etc/resolve.conf and it is read only to the world and is configured properly. Something may be wrong with Net::DNS::Resolver and it is not seeing the /etc/resolve.conf file when run as other users. This morning's chore is to create links to ~/.resolve.conf for a few users and get it owned by them and see what happens. Will advise. Tom Jeff Chan wrote: On Wednesday, February 16, 2005, 2:25:52 PM, Thomas Bolioli wrote: Hence my problem. From my local.cf which is not overridden anywhere skip_rbl_checks 0 dns_available yes From etc/procmailrc SPAMC="/usr/bin/spamassassin" :0f |$SPAMC but the surbl checks only occur when I do spamassassin -t < file_w_msg and not when procmail does the forwarding. I am at a loss. This has never worked since I install 10.1 (SA 3.0.0). SA 2.63/2.64 used a separate patch called SpamCopURI, and SA 3.x uses the built in program urirhssub for SURBL lookups. If you had SpamCopURI before, did you get rid of the it and the rules for it, as you should for 3.X? (3.X versions have SURBL rules set up by default). Did you perhaps upgrade from 3.0.0 to later versions? If so, did you remember to change the rule type from "header" to "body" as mentioned at: http://www.surbl.org/faq.html#body Jeff C. smime.p7s Description: S/MIME Cryptographic Signature
Re: surbl not reporting on any incoming email
I had not upgraded from a 2.6x install with Spam Cop. It was a totally stock install and it is still 3.0.0. I have since discovered that when I run spamassassin as any user except root, the network tests do not work. When I run it as root, all the network tests work just fine. I have tried to run network based things as other users before and there does not appear to be any restrictions on network access for those users. I checked /etc/resolve.conf and it is read only to the world and is configured properly. Something may be wrong with Net::DNS::Resolver and it is not seeing the /etc/resolve.conf file when run as other users. This morning's chore is to create links to ~/.resolve.conf for a few users and get it owned by them and see what happens. Will advise. Tom Jeff Chan wrote: On Wednesday, February 16, 2005, 2:25:52 PM, Thomas Bolioli wrote: Hence my problem. From my local.cf which is not overridden anywhere skip_rbl_checks 0 dns_available yes From etc/procmailrc SPAMC="/usr/bin/spamassassin" :0f |$SPAMC but the surbl checks only occur when I do spamassassin -t < file_w_msg and not when procmail does the forwarding. I am at a loss. This has never worked since I install 10.1 (SA 3.0.0). SA 2.63/2.64 used a separate patch called SpamCopURI, and SA 3.x uses the built in program urirhssub for SURBL lookups. If you had SpamCopURI before, did you get rid of the it and the rules for it, as you should for 3.X? (3.X versions have SURBL rules set up by default). Did you perhaps upgrade from 3.0.0 to later versions? If so, did you remember to change the rule type from "header" to "body" as mentioned at: http://www.surbl.org/faq.html#body Jeff C. smime.p7s Description: S/MIME Cryptographic Signature
Re: surbl not reporting on any incoming email
On Wednesday, February 16, 2005, 2:25:52 PM, Thomas Bolioli wrote: > Hence my problem. > From my local.cf which is not overridden anywhere > skip_rbl_checks 0 > dns_available yes > From etc/procmailrc > SPAMC="/usr/bin/spamassassin" > :0f > |$SPAMC > but the surbl checks only occur when I do spamassassin -t < file_w_msg > and not when procmail does the forwarding. > I am at a loss. This has never worked since I install 10.1 (SA 3.0.0). SA 2.63/2.64 used a separate patch called SpamCopURI, and SA 3.x uses the built in program urirhssub for SURBL lookups. If you had SpamCopURI before, did you get rid of the it and the rules for it, as you should for 3.X? (3.X versions have SURBL rules set up by default). Did you perhaps upgrade from 3.0.0 to later versions? If so, did you remember to change the rule type from "header" to "body" as mentioned at: http://www.surbl.org/faq.html#body Jeff C. -- Jeff Chan mailto:[EMAIL PROTECTED] http://www.surbl.org/
Re: surbl not reporting on any incoming email
Hence my problem. >>From my local.cf which is not overridden anywhere skip_rbl_checks 0 dns_available yes >>From etc/procmailrc SPAMC="/usr/bin/spamassassin" :0f |$SPAMC but the surbl checks only occur when I do spamassassin -t < file_w_msg and not when procmail does the forwarding. I am at a loss. This has never worked since I install 10.1 (SA 3.0.0). However, I just noticed something. It only works from the cmd line when I am root. Any ideas there? Does anybody know what effect removing DROPPRIVS=YES and making it DROPPRIVS=NO would have on procmail? Tom Theo Van Dinter wrote: On Wed, Feb 16, 2005 at 04:50:52PM -0500, Thomas Bolioli wrote: Is there any way to reverse -L --local for the spam assassin binary. It seems to be on, despite the fact that I use a global procmailrc file and it clearly has /usr/bin/spamassassin as the inary to exec without any switches. First, "spamassassin" isn't a binary, it's just a perl script. Second, there's no way to "reverse" it -- just don't put it on the commandline. If you're not calling it with any flags, ala: :0fw |/usr/bin/spamassassin then it'll try, by default, to do network checks. Another option is a configuration somewhere which does "skip_rbl_checks 1" or "dns_available no". Also, if DNS tests fail w/out "dns_available yes", that would stop it as well. smime.p7s Description: S/MIME Cryptographic Signature
Re: surbl not reporting on any incoming email
On Wed, Feb 16, 2005 at 04:50:52PM -0500, Thomas Bolioli wrote: > Is there any way to reverse -L --local for the spam assassin binary. It > seems to be on, despite the fact that I use a global procmailrc file and > it clearly has /usr/bin/spamassassin as the inary to exec without any > switches. First, "spamassassin" isn't a binary, it's just a perl script. Second, there's no way to "reverse" it -- just don't put it on the commandline. If you're not calling it with any flags, ala: :0fw |/usr/bin/spamassassin then it'll try, by default, to do network checks. Another option is a configuration somewhere which does "skip_rbl_checks 1" or "dns_available no". Also, if DNS tests fail w/out "dns_available yes", that would stop it as well. -- Randomly Generated Tagline: And shun the frumious Bandersnatch. pgpg5Xq02lPO4.pgp Description: PGP signature
Re: surbl not reporting on any incoming email
Is there any way to reverse -L --local for the spam assassin binary. It seems to be on, despite the fact that I use a global procmailrc file and it clearly has /usr/bin/spamassassin as the inary to exec without any switches. Tom Theo Van Dinter wrote: On Wed, Feb 16, 2005 at 03:58:18PM -0500, [EMAIL PROTECTED] wrote: New output. Notice it worked this time. But that same email does not show the surbl report. What do you mean "the surbl report"? The hits showed up in the Report you listed just fine (I added -MUNGED to avoid hitting other's filters): [...] debug: uri found: http://www.lendx-MUNGED.biz/index2.php?refid=849 debug: URIDNSBL: domains to query: lendx.biz [...] debug: tests=BIZ_TLD,CONSOLIDATE_DEBT,GAPPY_SUBJECT,NO_OBLIGATION,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DSBL,RCVD_IN_NJABL_PROXY,RCVD_IN_XBL,URIBL_AB_SURBL,URIBL_OB_SURBL,URIBL_SBL,URIBL_SC_SURBL,URIBL_WS_SURBL [...] X-Spam-Report: [...] * 0.6 URIBL_SBL Contains an URL listed in the SBL blocklist * [URIs: lendx.biz] * 2.0 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: lendx.biz] * 0.5 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: lendx.biz] * 2.0 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: lendx.biz] * 3.9 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: lendx.biz] [...] smime.p7s Description: S/MIME Cryptographic Signature
Re: surbl not reporting on any incoming email
>>From the original email I used as seed for the test. Note, no surbl test hit. Tom X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on nova.terranovum.com X-Spam-Level: ** X-Spam-Status: Yes, score=6.6 required=4.0 tests=BAYES_99,BIZ_TLD, CONSOLIDATE_DEBT,GAPPY_SUBJECT,NO_OBLIGATION autolearn=no version=3.0.0 X-Spam-Report: * 1.3 GAPPY_SUBJECT Subject: contains G.a.p.p.y-T.e.x.t * 0.2 CONSOLIDATE_DEBT BODY: Consolidate debt, credit, or bills * 0.8 NO_OBLIGATION BODY: There is no obligation * 2.3 BIZ_TLD URI: Contains an URL in the BIZ top-level domain * 1.9 BAYES_99 BODY: Bayesian spam probability is 99 to 100% * [score: 1.] Theo Van Dinter wrote: On Wed, Feb 16, 2005 at 03:58:18PM -0500, [EMAIL PROTECTED] wrote: New output. Notice it worked this time. But that same email does not show the surbl report. What do you mean "the surbl report"? The hits showed up in the Report you listed just fine (I added -MUNGED to avoid hitting other's filters): [...] debug: uri found: http://www.lendx-MUNGED.biz/index2.php?refid=849 debug: URIDNSBL: domains to query: lendx.biz [...] debug: tests=BIZ_TLD,CONSOLIDATE_DEBT,GAPPY_SUBJECT,NO_OBLIGATION,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DSBL,RCVD_IN_NJABL_PROXY,RCVD_IN_XBL,URIBL_AB_SURBL,URIBL_OB_SURBL,URIBL_SBL,URIBL_SC_SURBL,URIBL_WS_SURBL [...] X-Spam-Report: [...] * 0.6 URIBL_SBL Contains an URL listed in the SBL blocklist * [URIs: lendx.biz] * 2.0 URIBL_AB_SURBL Contains an URL listed in the AB SURBL blocklist * [URIs: lendx.biz] * 0.5 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist * [URIs: lendx.biz] * 2.0 URIBL_OB_SURBL Contains an URL listed in the OB SURBL blocklist * [URIs: lendx.biz] * 3.9 URIBL_SC_SURBL Contains an URL listed in the SC SURBL blocklist * [URIs: lendx.biz] [...] smime.p7s Description: S/MIME Cryptographic Signature
Re: surbl not reporting on any incoming email
On Wed, Feb 16, 2005 at 03:58:18PM -0500, [EMAIL PROTECTED] wrote: > New output. Notice it worked this time. But that same email does not show > the > surbl report. What do you mean "the surbl report"? The hits showed up in the Report you listed just fine (I added -MUNGED to avoid hitting other's filters): [...] > debug: uri found: http://www.lendx-MUNGED.biz/index2.php?refid=849 > debug: URIDNSBL: domains to query: lendx.biz [...] > debug: > tests=BIZ_TLD,CONSOLIDATE_DEBT,GAPPY_SUBJECT,NO_OBLIGATION,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DSBL,RCVD_IN_NJABL_PROXY,RCVD_IN_XBL,URIBL_AB_SURBL,URIBL_OB_SURBL,URIBL_SBL,URIBL_SC_SURBL,URIBL_WS_SURBL [...] > X-Spam-Report: [...] > * 0.6 URIBL_SBL Contains an URL listed in the SBL blocklist > * [URIs: lendx.biz] > * 2.0 URIBL_AB_SURBL Contains an URL listed in the AB SURBL > blocklist > * [URIs: lendx.biz] > * 0.5 URIBL_WS_SURBL Contains an URL listed in the WS SURBL > blocklist > * [URIs: lendx.biz] > * 2.0 URIBL_OB_SURBL Contains an URL listed in the OB SURBL > blocklist > * [URIs: lendx.biz] > * 3.9 URIBL_SC_SURBL Contains an URL listed in the SC SURBL > blocklist > * [URIs: lendx.biz] [...] -- Randomly Generated Tagline: "When I grow up, I'm going to bovine university!" --Ralph Wiggum Lisa the Vegetarian (Episode 3F03) pgpTjiHSNVesu.pgp Description: PGP signature
Re: surbl not reporting on any incoming email
On Wed, Feb 16, 2005 at 03:36:35PM -0500, [EMAIL PROTECTED] wrote: > The email I ran lint on had a domain in it. > > spamassassin --lint -D < /tmp/test_spam You can't do that. --lint does a lint. Perhaps you want -t for test? -- Randomly Generated Tagline: "Look, Daddy, a whale egg!" --Ralph Wiggum Make Room for Lisa (Episode AABF12) pgpBwCjzD9lZG.pgp Description: PGP signature
