You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by tp...@terranovum.com on 2005/02/16 21:36:35 UTC
surbl not reporting on any incoming email
I have SA 3.0.0 on Mandrake 10.1 and I am running everything through
procmail and am not running spamd. I believe that is the default for
10.1. Anyhow, I am not seeing surbl reports in any of the spam I am
receiving and I can't imagine that is normal. I checked the tests and
they are indeed there. I have the newest version of Net::DNS. I read the
FAQ over at surbl.org with regards to this and nothing seems to apply.
Thanks,
Tom
local.cf (relevant entries)
skip_rbl_checks 0
dns_available yes
The email I ran lint on had a domain in it.
spamassassin --lint -D < /tmp/test_spam
debug: SpamAssassin version 3.0.0
debug: Score set 0 chosen.
debug: running in taint mode? no
debug: diag: module installed: DBI, version 1.43
debug: diag: module installed: DB_File, version 1.810
debug: diag: module installed: Digest::SHA1, version 2.10
debug: diag: module installed: IO::Socket::UNIX, version 1.21
debug: diag: module installed: MIME::Base64, version 3.03
debug: diag: module installed: Net::DNS, version 0.48
debug: diag: module not installed: Net::LDAP ('require' failed)
debug: diag: module not installed: Razor2::Client::Agent ('require' failed)
debug: diag: module installed: Storable, version 2.13
debug: diag: module installed: URI, version 1.31
debug: ignore: using a test message to lint rules
debug: using "/etc/mail/spamassassin/init.pre" for site rules init.pre
debug: config: read file /etc/mail/spamassassin/init.pre
debug: using "/usr/share/spamassassin" for default rules dir
debug: config: read file /usr/share/spamassassin/10_misc.cf
debug: config: read file /usr/share/spamassassin/20_anti_ratware.cf
debug: config: read file /usr/share/spamassassin/20_body_tests.cf
debug: config: read file /usr/share/spamassassin/20_compensate.cf
debug: config: read file /usr/share/spamassassin/20_dnsbl_tests.cf
debug: config: read file /usr/share/spamassassin/20_drugs.cf
debug: config: read file /usr/share/spamassassin/20_fake_helo_tests.cf
debug: config: read file /usr/share/spamassassin/20_head_tests.cf
debug: config: read file /usr/share/spamassassin/20_html_tests.cf
debug: config: read file /usr/share/spamassassin/20_meta_tests.cf
debug: config: read file /usr/share/spamassassin/20_phrases.cf
debug: config: read file /usr/share/spamassassin/20_porn.cf
debug: config: read file /usr/share/spamassassin/20_ratware.cf
debug: config: read file /usr/share/spamassassin/20_uri_tests.cf
debug: config: read file /usr/share/spamassassin/23_bayes.cf
debug: config: read file /usr/share/spamassassin/25_body_tests_es.cf
debug: config: read file /usr/share/spamassassin/25_hashcash.cf
debug: config: read file /usr/share/spamassassin/25_spf.cf
debug: config: read file /usr/share/spamassassin/25_uribl.cf
debug: config: read file /usr/share/spamassassin/30_text_de.cf
debug: config: read file /usr/share/spamassassin/30_text_fr.cf
debug: config: read file /usr/share/spamassassin/30_text_nl.cf
debug: config: read file /usr/share/spamassassin/30_text_pl.cf
debug: config: read file /usr/share/spamassassin/50_scores.cf
debug: config: read file /usr/share/spamassassin/60_whitelist.cf
debug: using "/etc/mail/spamassassin" for site rules dir
debug: config: read file /etc/mail/spamassassin/local.cf
debug: using "/root/.spamassassin" for user state dir
debug: using "/root/.spamassassin/user_prefs" for user prefs file
debug: config: read file /root/.spamassassin/user_prefs
debug: plugin: loading Mail::SpamAssassin::Plugin::URIDNSBL from @INC
debug: plugin: registered
Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x848a648)
debug: plugin: loading Mail::SpamAssassin::Plugin::Hashcash from @INC
debug: plugin: registered
Mail::SpamAssassin::Plugin::Hashcash=HASH(0x8c19074)
debug: plugin: loading Mail::SpamAssassin::Plugin::SPF from @INC
debug: plugin: registered Mail::SpamAssassin::Plugin::SPF=HASH(0x8bf66c8)
debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x848a648)
implements 'parse_config'
debug: plugin: Mail::SpamAssassin::Plugin::Hashcash=HASH(0x8c19074)
implements 'parse_config'
debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x848a648)
inhibited further callbacks
debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x848a648)
inhibited further callbacks
debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x848a648)
inhibited further callbacks
debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x848a648)
inhibited further callbacks
debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x848a648)
inhibited further callbacks
debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x848a648)
inhibited further callbacks
debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x848a648)
inhibited further callbacks
debug: bayes: Using username: root
debug: bayes: Database connection established
debug: bayes: found bayes db version 3
debug: bayes: Using userid: 10
debug: bayes: Not available for scanning, only 0 spam(s) in Bayes DB < 200
debug: Score set 1 chosen.
debug: ---- MIME PARSER START ----
debug: main message type: text/plain
debug: parsing normal part
debug: added part, type: text/plain
debug: ---- MIME PARSER END ----
debug: bayes: Database connection established
debug: bayes: found bayes db version 3
debug: bayes: Using userid: 10
debug: bayes: Not available for scanning, only 0 spam(s) in Bayes DB < 200
debug: metadata: X-Spam-Relays-Trusted:
debug: metadata: X-Spam-Relays-Untrusted:
debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x848a648)
implements 'parsed_metadata'
debug: dns_available set to yes in config file, skipping test
debug: decoding: no encoding detected
debug: URIDNSBL: domains to query:
debug: is Net::DNS::Resolver available? yes
debug: Net::DNS version: 0.48
debug: all '*From' addrs: ignore@compiling.spamassassin.taint.org
debug: Running tests for priority: 0
debug: running header regexp tests; score so far=0
debug: registering glue method for check_uridnsbl
(Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x848a648))
debug: registering glue method for check_hashcash_double_spend
(Mail::SpamAssassin::Plugin::Hashcash=HASH(0x8c19074))
debug: registering glue method for check_for_spf_helo_pass
(Mail::SpamAssassin::Plugin::SPF=HASH(0x8bf66c8))
debug: SPF: message was delivered entirely via trusted relays, not required
debug: registering glue method for check_hashcash_value
(Mail::SpamAssassin::Plugin::Hashcash=HASH(0x8c19074))
debug: all '*To' addrs:
debug: registering glue method for check_for_spf_softfail
(Mail::SpamAssassin::Plugin::SPF=HASH(0x8bf66c8))
debug: SPF: message was delivered entirely via trusted relays, not required
debug: registering glue method for check_for_spf_pass
(Mail::SpamAssassin::Plugin::SPF=HASH(0x8bf66c8))
debug: registering glue method for check_for_spf_helo_softfail
(Mail::SpamAssassin::Plugin::SPF=HASH(0x8bf66c8))
debug: registering glue method for check_for_spf_helo_fail
(Mail::SpamAssassin::Plugin::SPF=HASH(0x8bf66c8))
debug: running body-text per-line regexp tests; score so far=-2.623
debug: running uri tests; score so far=-2.623
debug: Razor2 is not available
debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x848a648)
implements 'check_tick'
debug: running raw-body-text per-line regexp tests; score so far=-2.623
debug: running full-text regexp tests; score so far=-2.623
debug: Razor2 is not available
debug: Current PATH is:
/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin
debug: Pyzor is not available: pyzor not found
debug: DCCifd is not available: no r/w dccifd socket found.
debug: DCC is not available: no executable dccproc found.
debug: Running tests for priority: 500
debug: RBL: success for 1 of 1 queries
debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x848a648)
implements 'check_post_dnsbl'
debug: running meta tests; score so far=-2.623
debug: running header regexp tests; score so far=-1.053
debug: running body-text per-line regexp tests; score so far=-1.053
debug: running uri tests; score so far=-1.053
debug: running raw-body-text per-line regexp tests; score so far=-1.053
debug: running full-text regexp tests; score so far=-1.053
debug: Running tests for priority: 1000
debug: running meta tests; score so far=-1.053
debug: running header regexp tests; score so far=-1.053
debug: lock: 13398 created /var/spool/spamassassin/auto-whitelist.mutex
debug: lock: 13398 trying to get lock on
/var/spool/spamassassin/auto-whitelist with 30 timeout
debug: lock: 13398 link to /var/spool/spamassassin/auto-whitelist.mutex:
link okdebug: Tie-ing to DB file R/W in
/var/spool/spamassassin/auto-whitelist
debug: auto-whitelist (db-based):
ignore@compiling.spamassassin.taint.org|ip=none scores 0/0
debug: AWL active, pre-score: -1.053, autolearn score: -1.053, mean:
undef, IP: undef
debug: DB addr list: untie-ing and unlocking.
debug: DB addr list: file locked, breaking lock.
debug: unlock: 13398 unlocked /var/spool/spamassassin/auto-whitelist.mutex
debug: Post AWL score: -1.053
debug: running body-text per-line regexp tests; score so far=-1.053
debug: running uri tests; score so far=-1.053
debug: running raw-body-text per-line regexp tests; score so far=-1.053
debug: running full-text regexp tests; score so far=-1.053
debug: is spam? score=-1.053 required=4
debug: tests=ALL_TRUSTED,MISSING_DATE,MISSING_SUBJECT,NO_REAL_NAME
debug:
subtests=__HAS_MSGID,__MSGID_OK_DIGITS,__MSGID_OK_HOST,__SANE_MSGID,__UNUSABLE_MSGID
Re: surbl not reporting on any incoming email
Posted by Thomas Bolioli <tp...@terranovum.com>.
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.0000]
Theo Van Dinter wrote:
>On Wed, Feb 16, 2005 at 03:58:18PM -0500, tpblists@terranovum.com 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]
>>
>>
>[...]
>
>
>
Re: Odd issue with a few mailing lists..
Posted by Evan Platt <ev...@espphotography.com>.
At 02:53 PM 2/16/2005, you wrote:
>Note: I use Eudora.
>
>Unfortunately, this is a design "feature" of Eudora.. It always extracts
>attachments, and has to, as it does not support leaving them in the
>message mailbox. This has lead to numerous security exploits against
>eudora in the past. Since the attachment extraction happens automatically
>when the message is downloaded, malicious encodings get decoded
>automatically...
>
>Your best bet is in Eudora options, under attachments, enable the "delete
>attachments when emptying trash". This will make eudora clean up a
>messages attachments when you empty it out of your trash.. Not perfect,
>and you have to make sure to save attachments you want keep, but it's
>helpful and automated.
But it will only delete the attachment if I delete the message, correct? So
if I keep a message, it keeps the attachment. Delete the message,
attachment goes with it?
>You might also consider enabling 'put text attachments in body of
>message'... but that's a bit problematic if you really want a text
>attachment to be saved separately..
I think that's a better idea for now. :)
Thanks..
Evan
Re: Odd issue with a few mailing lists..
Posted by Matt Kettler <mk...@evi-inc.com>.
At 05:35 PM 2/16/2005, Evan Platt wrote:
>I only seem to have this problem on this list and the mrtg lists...
>however a number of messages come with attachments. Looking at them, they
>appear to generally be PGP keys. Not a major issue, but now I have dozens
>of them (well, more).
>
>Not to pick on people, but just in the last few days, I see it from Theo
>Van Dinter, Michael Parker, Thomas Bolioli, and that seems to be it for
>the past week or so.
>
>I'm using Eudora Windows 6.2.1.2. Any way to turn this off?
Note: I use Eudora.
Unfortunately, this is a design "feature" of Eudora.. It always extracts
attachments, and has to, as it does not support leaving them in the message
mailbox. This has lead to numerous security exploits against eudora in the
past. Since the attachment extraction happens automatically when the
message is downloaded, malicious encodings get decoded automatically...
Your best bet is in Eudora options, under attachments, enable the "delete
attachments when emptying trash". This will make eudora clean up a messages
attachments when you empty it out of your trash.. Not perfect, and you have
to make sure to save attachments you want keep, but it's helpful and automated.
You might also consider enabling 'put text attachments in body of
message'... but that's a bit problematic if you really want a text
attachment to be saved separately..
Re: Odd issue with a few mailing lists..
Posted by Thomas Bolioli <tp...@terranovum.com>.
They're S/MIME digital signatures. Eudora has a habit of automatically
extracting (and severing) attachments and plopping them on the drive
somewhere of the user's choosing, providing a link to it in the email.
Most of us use clients that behave radically different. Eudora should
probably not extract attachments at all or be more selective in what it
extracts. Note: I am not trashing Eudora, I used if for 6+ years on both
Windoze and Mac. Just that one thing always got to me. I wish they would
make an option to turn off that behavior since the attachments can
easily get lost and unlinked from the original email. Like when I moved
to Apple Mail, I have thousands of emails missing the attachments...
Tom
Evan Platt wrote:
> I only seem to have this problem on this list and the mrtg lists...
> however a number of messages come with attachments. Looking at them,
> they appear to generally be PGP keys. Not a major issue, but now I
> have dozens of them (well, more).
>
> Not to pick on people, but just in the last few days, I see it from
> Theo Van Dinter, Michael Parker, Thomas Bolioli, and that seems to be
> it for the past week or so.
>
> I'm using Eudora Windows 6.2.1.2. Any way to turn this off? The entire
> contents of the attached file appear as below: (This from Theo)
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFCE8iE0n2PaNPSwnMRAuOTAKCXsRD0TxFAFaj3+I4dx45u8RY92gCgtOI5
> qiTu8706EiipoyH+Rx5SXOU=
> =Xdgp
> -----END PGP SIGNATURE-----
>
>
> As a test, I e-mailed myself the contents of the attached file, and it
> did not convert it to an attachment.
>
> Any ideas?
>
> Thanks.
>
> Evan
Odd issue with a few mailing lists..
Posted by Evan Platt <ev...@espphotography.com>.
I only seem to have this problem on this list and the mrtg lists... however
a number of messages come with attachments. Looking at them, they appear
to generally be PGP keys. Not a major issue, but now I have dozens of them
(well, more).
Not to pick on people, but just in the last few days, I see it from Theo
Van Dinter, Michael Parker, Thomas Bolioli, and that seems to be it for the
past week or so.
I'm using Eudora Windows 6.2.1.2. Any way to turn this off? The entire
contents of the attached file appear as below: (This from Theo)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFCE8iE0n2PaNPSwnMRAuOTAKCXsRD0TxFAFaj3+I4dx45u8RY92gCgtOI5
qiTu8706EiipoyH+Rx5SXOU=
=Xdgp
-----END PGP SIGNATURE-----
As a test, I e-mailed myself the contents of the attached file, and it did
not convert it to an attachment.
Any ideas?
Thanks.
Evan
Re: surbl not reporting on any incoming email
Posted by Thomas Bolioli <tp...@terranovum.com>.
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.
>>>
>>>
Re: surbl not reporting on any incoming email
Posted by Thomas Bolioli <tp...@terranovum.com>.
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,
>>
>>
Re: surbl not reporting on any incoming email
Posted by Thomas Bolioli <tp...@terranovum.com>.
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,
>
>
Re: surbl not reporting on any incoming email
Posted by Thomas Bolioli <tp...@terranovum.com>.
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.
>>
>>
Re: surbl not reporting on any incoming email
Posted by Thomas Bolioli <tp...@terranovum.com>.
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.
>
>
Re: surbl not reporting on any incoming email
Posted by Jeff Chan <je...@surbl.org>.
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:jeffc@surbl.org
http://www.surbl.org/
Re: surbl not reporting on any incoming email
Posted by Thomas Bolioli <tp...@terranovum.com>.
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.
>
>
>
Re: surbl not reporting on any incoming email
Posted by Theo Van Dinter <fe...@kluge.net>.
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.
Re: surbl not reporting on any incoming email
Posted by Thomas Bolioli <tp...@terranovum.com>.
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, tpblists@terranovum.com 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]
>>
>>
>[...]
>
>
>
Re: surbl not reporting on any incoming email
Posted by Theo Van Dinter <fe...@kluge.net>.
On Wed, Feb 16, 2005 at 03:58:18PM -0500, tpblists@terranovum.com 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)
Re: surbl not reporting on any incoming email
Posted by Theo Van Dinter <fe...@kluge.net>.
On Wed, Feb 16, 2005 at 03:36:35PM -0500, tpblists@terranovum.com 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)