errors after upgrade to 3.1.7, now it doesn't work

[Brian S. Meehan]

I had a working setup of Courier-MTA, spamassassin 3.0.4, and maildrop,
but I upgraded spamassassin to 3.1.7 and now I have errors and mail
doesn't get delivered unless I remove the tie-in to spamassassin in the
courierd file.

Here are some of the errors:
Oct 20 14:10:20 mail spamd[5776]: configuration file
"/usr/share/spamassassin/20_net_tests.cf" requires version 3.001007 of
SpamAssassin, but this is code ve
rsion 3.04. Maybe you need to use the -C switch, or remove the old
config files? Skipping this file at
/usr/lib/perl5/vendor_perl/5.8.6/Mail/SpamAssassin
/Conf/Parser.pm line 332.
Oct 20 14:10:20 mail spamd[5776]: configuration file
"/usr/share/spamassassin/20_phrases.cf" requires version 3.001007 of
SpamAssassin, but this is code vers
ion 3.04. Maybe you need to use the -C switch, or remove the old
config files? Skipping this file at
/usr/lib/perl5/vendor_perl/5.8.6/Mail/SpamAssassin/C
onf/Parser.pm line 332.
Oct 20 14:10:21 mail spamd[5776]: configuration file
"/usr/share/spamassassin/20_porn.cf" requires version 3.001007 of
SpamAssassin, but this is code version
 3.04. Maybe you need to use the -C switch, or remove the old config
files? Skipping this file at
/usr/lib/perl5/vendor_perl/5.8.6/Mail/SpamAssassin/Conf
/Parser.pm line 332.
Oct 20 14:10:21 mail spamd[5776]: configuration file
"/usr/share/spamassassin/20_uri_tests.cf" requires version 3.001007 of
SpamAssassin, but this is code ve
rsion 3.04. Maybe you need to use the -C switch, or remove the old
config files? Skipping this file at
/usr/lib/perl5/vendor_perl/5.8.6/Mail/SpamAssassin
/Conf/Parser.pm line 332.
Oct 20 14:10:21 mail spamd[5776]: configuration file
"/usr/share/spamassassin/23_bayes.cf" requires version 3.001007 of
SpamAssassin, but this is code versio
n 3.04. Maybe you need to use the -C switch, or remove the old config
files? Skipping this file at
/usr/lib/perl5/vendor_perl/5.8.6/Mail/SpamAssassin/Con
f/Parser.pm line 332.
Oct 20 14:10:22 mail spamd[5776]: Failed to run __ENV_AND_HDR_FROM_MATCH
SpamAssassin test, skipping:__(Can't locate object method
"check_for_matching_env_an
d_hdr_from" via package "Mail::SpamAssassin::PerMsgStatus" at
/usr/lib/perl5/vendor_perl/5.8.6/Mail/SpamAssassin/PerMsgStatus.pm line
2340._)
Oct 20 14:10:22 mail spamd[5776]: Failed to run USER_IN_DEF_SPF_WL
SpamAssassin test, skipping:__(Can't locate object method
"check_for_def_spf_whitelist_fro
m" via package "Mail::SpamAssassin::PerMsgStatus" at
/usr/lib/perl5/vendor_perl/5.8.6/Mail/SpamAssassin/PerMsgStatus.pm line
2340._)
Oct 20 14:10:22 mail spamd[5776]: Failed to run RATWARE_EFROM SpamAssassin
test, skipping:__(Can't locate object method "check_ratware_envelope_from"
via pac
kage "Mail::SpamAssassin::PerMsgStatus" at
/usr/lib/perl5/vendor_perl/5.8.6/Mail/SpamAssassin/PerMsgStatus.pm line
2340._)
Oct 20 14:10:22 mail spamd[5776]: Failed to run __RATWARE_NAME_ID
SpamAssassin test, skipping:__(Can't locate object method
"check_ratware_name_id" via packa
ge "Mail::SpamAssassin::PerMsgStatus" at
/usr/lib/perl5/vendor_perl/5.8.6/Mail/SpamAssassin/PerMsgStatus.pm line
2340._)
Oct 20 14:10:22 mail spamd[5776]: Failed to run SPF_NEUTRAL SpamAssassin
test, skipping:__(Can't locate object method "check_for_spf_neutral" via
package "Ma
il::SpamAssassin::PerMsgStatus" at
/usr/lib/perl5/vendor_perl/5.8.6/Mail/SpamAssassin/PerMsgStatus.pm line
2340._)
Oct 20 14:10:22 mail spamd[5776]: Failed to run USER_IN_SPF_WHITELIST
SpamAssassin test, skipping:__(Can't locate object method
"check_for_spf_whitelist_from
" via package "Mail::SpamAssassin::PerMsgStatus" at
/usr/lib/perl5/vendor_perl/5.8.6/Mail/SpamAssassin/PerMsgStatus.pm line
2340._)


Reading the top errors indicates that I haven't removed something from the
old version, but without knowing for sure what I should remove, I am
hesitant to do so. The bottom errors indicate something didn't get
installed or configured correctly. Please advise.

Thanks,
Brian



-- 
"All people who think everything is either black or white are idiots."

RE: use of ram after upgrade

[R Lists06]

> From: Balzi Andrea
> 
> I've try it, but now I've the follow use:
> 
> Tasks:  83 total,   2 running,  81 sleeping,   0 stopped,   0 zombie
>  Cpu0 :   0.0% user,   1.3% system,   1.7% nice,  97.0% idle
>  Cpu1 :   0.0% user,   1.3% system,   0.0% nice,  98.7% idle
>  Cpu2 :   0.0% user,   0.0% system,   1.3% nice,  98.7% idle
>  Cpu3 :   0.0% user,   0.0% system,  98.7% nice,   1.3% idle
> Mem:   6206432k total,   909444k used,  5296988k free,   117224k buffers
> Swap:  284k total, 7856k used,  1992228k free,70724k cached
> 
>   PID  PPID  PR  NI S #C  RES  SHR SWAP   TIME COMMAND
> 15404 15386  15  10 S  1 354m  33m0   5:29 spamd child
> 15405 15386  19  10 R  2 176m  34m0   4:33 spamd child
> 15626 15386  14  10 S  0  88m  36m0   0:22 spamd child
> 15645 15386  15  10 S  3  85m  36m0   0:07 spamd child
> 15386 1  15  10 S  2  73m  36m0   0:03 /usr/sbin/spamd
> 

My engineers and I have determined that since this is a 4 way processor box
(hopefully with a lot of RAM and processor speed),  that you should box it
up and send it to us for extended testing...

...probably only a year or two and we will fix it and get it right back you
you...

if you cannot send this one, another 4 proc or 8 proc box will do.

;->

Thanks and kind regards!

 - rh

--
Robert - Abba Communications
   Computer & Internet Services
 (509) 624-7159 - www.abbacomm.net

RE: use of ram after upgrade

[Balzi Andrea]

I've try it, but now I've the follow use:

Tasks:  83 total,   2 running,  81 sleeping,   0 stopped,   0 zombie
 Cpu0 :   0.0% user,   1.3% system,   1.7% nice,  97.0% idle
 Cpu1 :   0.0% user,   1.3% system,   0.0% nice,  98.7% idle
 Cpu2 :   0.0% user,   0.0% system,   1.3% nice,  98.7% idle
 Cpu3 :   0.0% user,   0.0% system,  98.7% nice,   1.3% idle
Mem:   6206432k total,   909444k used,  5296988k free,   117224k buffers
Swap:  284k total, 7856k used,  1992228k free,70724k cached

  PID  PPID  PR  NI S #C  RES  SHR SWAP   TIME COMMAND
15404 15386  15  10 S  1 354m  33m0   5:29 spamd child
15405 15386  19  10 R  2 176m  34m0   4:33 spamd child
15626 15386  14  10 S  0  88m  36m0   0:22 spamd child
15645 15386  15  10 S  3  85m  36m0   0:07 spamd child
15386 1  15  10 S  2  73m  36m0   0:03 /usr/sbin/spamd

> -Original Message-
> From: Dave Pooser [mailto:[EMAIL PROTECTED] 
> Sent: martedì 10 ottobre 2006 18.09
> To: users@spamassassin.apache.org
> Subject: Re: use of ram after upgrade
> 
> >  4.7M Oct 10 03:00 blacklist-uri.cf
> 
> Remove this and use URI blacklists instead. Notice how this 
> rule's size is orders of magnitude greater than any of the 
> others you listed? Same goes for its RAM footprint.
> --
> Dave Pooser
> Cat-Herder-in-Chief, Pooserville.com
> "...Life is not a journey to the grave with the intention of 
> arriving safely in one pretty and well-preserved piece, but 
> to slide across the finish line broadside, thoroughly used 
> up, worn out, leaking oil, and shouting GERONIMO!!!" -- Bill McKenna
> 
> 
> 

Re: use of ram after upgrade

[Dave Pooser]

>  4.7M Oct 10 03:00 blacklist-uri.cf

Remove this and use URI blacklists instead. Notice how this rule's size is
orders of magnitude greater than any of the others you listed? Same goes for
its RAM footprint.
-- 
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com
"...Life is not a journey to the grave with the intention of arriving
safely in one pretty and well-preserved piece, but to slide across the
finish line broadside, thoroughly used up, worn out, leaking oil, and
shouting GERONIMO!!!" -- Bill McKenna

use of ram after upgrade

[Balzi Andrea]

Hi

I have upgraded my spamassassin to version 3.1.7 and after the restart
of the process I have saw an increment of the use of the ram.
I use the default rules of the spamassassin and the following rules:

  53K Apr 20 11:00 70_sare_adult.cf
 3.8K Jun  2  2005 70_sare_bayes_poison_nxm.cf
  24K Oct  5  2005 70_sare_evilnum0.cf
 1.6K Jun  2  2005 70_sare_evilnum1.cf
 6.9K Jun  2  2005 70_sare_evilnum2.cf
 184K Dec 27  2005 70_sare_genlsubj.cf
  32K Dec 27  2005 70_sare_genlsubj_eng.cf
 376K Oct 30  2005 70_sare_header.cf
 8.0K May 21 22:00 70_sare_header_eng.cf
 4.4K Jun  2  2005 70_sare_highrisk.cf
 105K Jun  4 07:00 70_sare_html.cf
  39K Jun  4 07:00 70_sare_html4.cf
 3.1K Jun  4 07:00 70_sare_html_eng.cf
 155K Oct  1  2005 70_sare_obfu.cf
 6.0K Oct  1  2005 70_sare_obfu2.cf
  14K Oct  1  2005 70_sare_obfu3.cf
  13K Dec 27  2005 70_sare_oem.cf
  18K Dec 12  2005 70_sare_random.cf
  96K May 28 05:00 70_sare_specific.cf
  20K Jul 25 18:00 70_sare_spoof.cf
  54K Sep 22 23:00 70_sare_stocks.cf
  25K Nov 12  2005 70_sare_unsub.cf
  18K Oct  5  2005 70_sare_uri0.cf
  24K Oct 11  2005 70_sare_uri1.cf
 8.4K Oct  5  2005 70_sare_uri3.cf
 5.0K Oct  5  2005 70_sare_uri_eng.cf
  49K May 16 05:00 70_sare_whitelist.cf
 8.8K Sep 25 19:00 70_sc_top200.cf
 104K Jul 31 00:50 70_zmi_german.cf
  13K Jun  2  2005 72_sare_bml_post25x.cf
  16K May 16 05:00 72_sare_redirect_post3.0.0.cf
  79K Sep 25 19:00 88_FVGT_body.cf
  50K Aug 27 12:34 88_FVGT_headers.cf
  16K Apr 25 17:00 88_FVGT_rawbody.cf
  57K Jul 31 20:00 88_FVGT_subject.cf
  18K Jul  6 18:00 88_FVGT_uri.cf
  55K Jun  2  2005 99_FVGT_Tripwire.cf
  12K Jun  2  2005 99_FVGT_meta.cf
  776 Sep 29 12:09 99_blacklist_arthis.cf
  26K Sep 14 14:19 99_jam.cf
 2.0K Sep 14 15:31 99_jam_virus.cf
  10K Jun  2  2005 99_sare_fraud_post25x.cf
 9.7K Oct  9 08:15 99_whitelist_arthis.cf
 5.3K Oct  4 21:54 FuzzyOcr.cf
  415 Oct  3 10:15 FuzzyOcr.words
 4.7M Oct 10 03:00 blacklist-uri.cf
 108K Dec 15  2005 bogus-virus-warnings.cf
  23K Jun  2  2005 chickenpox.cf
 4.6K Aug  6 03:57 imageinfo.cf
  946 Sep 15 07:50 init.pre
 1.5K Oct  1 10:39 local.cf
 2.2K Sep 21 11:26 mime_validate.cf
 4.8K May 25  2004 random.cf
  55K Jun  2  2005 tripwire.cf
 2.3K Oct  3 10:30 v310.pre
  806 Sep 15 09:29 v312.pre
 3.8K Jun  2  2005 weeds.cf

Bellow I've cut a part of top command on my server.

Tasks:  93 total,   1 running,  91 sleeping,   0 stopped,   1 zombie
 Cpu0 :   0.0% user,   0.3% system,   6.0% nice,  93.7% idle
 Cpu1 :   0.0% user,   0.0% system,   0.0% nice, 100.0% idle
 Cpu2 :   0.3% user,   1.3% system,  12.6% nice,  85.8% idle
 Cpu3 :   0.3% user,   0.7% system,   4.3% nice,  94.7% idle
Mem:   6206432k total,  1103800k used,  5102632k free,   108804k buffers
Swap:  284k total, 7856k used,  1992228k free,65000k cached

  PID  PPID  PR  NI S #C  RES  SHR SWAP   TIME COMMAND
12411  7632  15  10 S  0 335m  75m0   0:10 spamd child
 7719  7632  15  10 S  0 180m  76m0   0:38 spamd child
14332  7632  15  10 S  0 173m  77m0   0:33 spamd child
14365  7632  15  10 S  1 161m  78m0   0:19 spamd child
14665  7632  17  10 D  3 153m  78m0   0:02 spamd child
14684  7632  14  10 S  0 150m  95m0   0:00 spamd child
 7632 1  15  10 S  3 149m  95m0   0:12 /usr/sbin/spamd

It's a rules problem?

Andrea

Re: Problem after upgrade to Net::DNS 0.58

[Chris]

On Monday 18 September 2006 8:13 am, Sietse van Zanen wrote:
> Probably the writers of the module have decided to use strict references
> in their programming.
>
> You can do 1 of 2 things:
> 1. donwgrade back to 0.53.
> 2. edit the perl source for the new module and disable strict references.
> There should be a line that says 'use strict;'. Add a line 'no strict
> 'refs'; under that. Or something down that road. Look at
> http://perldoc.perl.org/strict.html for more information.
>
> -Sietse
>
I restarted SA last night on the off chance that may fix the problem and it 
appears that it has, I've not seen the error in my syslog for the past 
20hrs or so. I'll keep a watch out and if it comes back give your 
suggestion #2 a try.

Thanks again
Chris

-- 
Chris


pgpccGKSA0zT6.pgp
Description: PGP signature

RE: Problem after upgrade to Net::DNS 0.58

[Sietse van Zanen]

Probably the writers of the module have decided to use strict references in their programming.
 
You can do 1 of 2 things:
1. donwgrade back to 0.53. 
2. edit the perl source for the new module and disable strict references. There should be a line that says 'use strict;'. Add a line 'no strict 'refs'; under that. Or something down that road. Look at http://perldoc.perl.org/strict.html for more information.
 
-Sietse


From: ChrisSent: Mon 18-Sep-06 4:24To: users@spamassassin.apache.orgSubject: Problem after upgrade to Net::DNS 0.58
I'm running SA 3.1.5 and this evening upgraded to the above version of 
Net::DNS. Since then periodically I've been seeing this in my syslog:

Sep 17 20:27:04 localhost spamd[1126]: Can't use string ("Net::DNS::RR::MX") 
as a HASH ref while "strict refs" in use 
at /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/Net/DNS/RR.pm 
line 724. 
Sep 17 20:27:04 localhost spamd[1126]: Can't use string ("Net::DNS::RR::MX") 
as a HASH ref while "strict refs" in use 
at /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/Net/DNS/RR.pm 
line 724. 
Sep 17 20:27:04 localhost spamd[1126]: Compilation failed in require at 
(eval 1009) line 3. 
Sep 17 20:27:04 localhost spamd[1126]: Can't use string ("Net::DNS::RR::MX") 
as a HASH ref while "strict refs" in use 
at /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/Net/DNS/RR.pm 
line 724. 
Sep 17 20:27:04 localhost spamd[1126]: Compilation failed in require at 
(eval 1009) line 3. 
Sep 17 20:27:04 localhost spamd[1126]: plugin: eval failed: Can't use string 
("Net::DNS::RR::MX") as a HASH ref while "strict refs" in use 
at /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/Net/DNS/RR.pm 
line 724. 
Sep 17 20:27:04 localhost spamd[1126]: Compilation failed in require at 
(eval 1009) line 3. 

I upgraded via CPAN and there were no errors noted during the upgrade and 
according to the output the install was successfull.  All the required 
modules are already installed also. Ideas anyone?

-- 
Chris

Re: Problem after upgrade to Net::DNS 0.58

[Chris]

On Sunday 17 September 2006 9:24 pm, Chris wrote:
> I'm running SA 3.1.5 and this evening upgraded to the above version of
> Net::DNS. Since then periodically I've been seeing this in my syslog:

As another question to this, I did an upgrade to the module instead a 
removing the older version and then installing the newer. Should I have 
removed the 0.53 version first?

-- 
Chris


pgpSiaaQWu8eG.pgp
Description: PGP signature

Problem after upgrade to Net::DNS 0.58

[Chris]

I'm running SA 3.1.5 and this evening upgraded to the above version of 
Net::DNS. Since then periodically I've been seeing this in my syslog:

Sep 17 20:27:04 localhost spamd[1126]: Can't use string ("Net::DNS::RR::MX") 
as a HASH ref while "strict refs" in use 
at /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/Net/DNS/RR.pm 
line 724. 
Sep 17 20:27:04 localhost spamd[1126]: Can't use string ("Net::DNS::RR::MX") 
as a HASH ref while "strict refs" in use 
at /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/Net/DNS/RR.pm 
line 724. 
Sep 17 20:27:04 localhost spamd[1126]: Compilation failed in require at 
(eval 1009) line 3. 
Sep 17 20:27:04 localhost spamd[1126]: Can't use string ("Net::DNS::RR::MX") 
as a HASH ref while "strict refs" in use 
at /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/Net/DNS/RR.pm 
line 724. 
Sep 17 20:27:04 localhost spamd[1126]: Compilation failed in require at 
(eval 1009) line 3. 
Sep 17 20:27:04 localhost spamd[1126]: plugin: eval failed: Can't use string 
("Net::DNS::RR::MX") as a HASH ref while "strict refs" in use 
at /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/Net/DNS/RR.pm 
line 724. 
Sep 17 20:27:04 localhost spamd[1126]: Compilation failed in require at 
(eval 1009) line 3. 

I upgraded via CPAN and there were no errors noted during the upgrade and 
according to the output the install was successfull.  All the required 
modules are already installed also. Ideas anyone?

-- 
Chris


pgpSWlRXqpMh3.pgp
Description: PGP signature

Re: [Bump] No log to syslog after upgrade

[Thomas Ericsson]

Sorry I took so long to respond to this. Of course it was me who  
should RTFM :-P Since we are using CGPSA we are not using SPAMD if I  
understand it right. From the CGPSA website ( http:// 
www.tffenterprises.com/cgpsa/ ):


"The filter works efficiently, by directly using the SpamAssassin  
API. It does not rely on a daemon process such as spamd or on the  
execution of shell scripts (as the usual process for utilizing  
SpamAssassin with CommuniGate servers does)."


I guess what I saw in our old logs must have been from tests with  
SPAMD, unless something changed between versions (I upgraded CGPSA  
and SA at the same time).


Thanks for your help Theo and John, much appreciated. I also got to  
agree with Kurt about the possibility for SA to write to syslog. It  
would help to analyze and adjust SA if you could pull out some  
statistics (or is that possible another way?).


Thomas



7 sep 2006 kl. 18.33 skrev Theo Van Dinter:


On Thu, Sep 07, 2006 at 09:11:22AM -0700, John D. Hardin wrote:

[server]spamassassin --lint -D
[22110] dbg: logger: adding facilities: all
[22110] dbg: logger: logging level is DBG



Is your syslog daemon configured to discard debug-level messages?

[...]

At last check, spamassassin doesn't log to syslog.  spamd does.

--
Randomly Generated Tagline:
"... advise the users that although it can help, they are known  
problems ..."

- Stanislav Meduna




Here's our setup: OSX 10.3.9, Communigate 4.2.8, CGPSA 1.4, SA 3.1.3

RE: [Bump] No log to syslog after upgrade

[Kurt Buff]

This is news to me - I'll have to dig into the docs again, and see what I
can find.

Sigh.

I must be getting old or something.

| -Original Message-
| From: Stuart Johnston [mailto:[EMAIL PROTECTED]
| Sent: Thursday, September 07, 2006 15:27
| To: Kurt Buff; users@spamassassin.apache.org
| Subject: Re: [Bump] No log to syslog after upgrade
| 
| 
| Kurt Buff wrote:
| > I've requested an account, and am waiting for the password.
| > 
| > I understand about command line tools and their use, but SA 
| is a bit of a
| > special case, as it's used as more than simply a command line tool -
| > especially when you consider its use with Amavis, etc.
| 
| amavisd-new has its own logging facilities including the 
| option to log to syslog or a separate log 
| file.  There is also an option to log debugging output from 
| SA.  You should ask on the amavis list 
| if you need more details.
| 


  

Re: [Bump] No log to syslog after upgrade

[Stuart Johnston]

Kurt Buff wrote:

I've requested an account, and am waiting for the password.

I understand about command line tools and their use, but SA is a bit of a
special case, as it's used as more than simply a command line tool -
especially when you consider its use with Amavis, etc.


amavisd-new has its own logging facilities including the option to log to syslog or a separate log 
file.  There is also an option to log debugging output from SA.  You should ask on the amavis list 
if you need more details.

RE: [Bump] No log to syslog after upgrade

[Kurt Buff]

Entered as # 5093.

| -Original Message-
| From: Kurt Buff 
| Sent: Thursday, September 07, 2006 14:27
| To: users@spamassassin.apache.org
| Subject: RE: [Bump] No log to syslog after upgrade
| 
| 
| I've requested an account, and am waiting for the password.
| 
| I understand about command line tools and their use, but SA 
| is a bit of a
| special case, as it's used as more than simply a command line tool -
| especially when you consider its use with Amavis, etc.
| 
| Kurt
| 
| | -Original Message-
| | From: Theo Van Dinter [mailto:[EMAIL PROTECTED]
| | Sent: Thursday, September 07, 2006 13:32
| | To: users@spamassassin.apache.org
| | Subject: Re: [Bump] No log to syslog after upgrade
| | 
| | 
| | On Thu, Sep 07, 2006 at 01:26:08PM -0700, Kurt Buff wrote:
| | > Perhaps an invocation flag could be added?
| | 
| | You can feel free to open an enhancement BZ ticket if you like.
| | Generally speaking commandline tools don't log to syslog though.
| | 
| | -- 
| | Randomly Generated Tagline:
| | If ignorance is bliss, why aren't more people happy?


  

RE: [Bump] No log to syslog after upgrade

[Kurt Buff]

I've requested an account, and am waiting for the password.

I understand about command line tools and their use, but SA is a bit of a
special case, as it's used as more than simply a command line tool -
especially when you consider its use with Amavis, etc.

Kurt

| -Original Message-
| From: Theo Van Dinter [mailto:[EMAIL PROTECTED]
| Sent: Thursday, September 07, 2006 13:32
| To: users@spamassassin.apache.org
| Subject: Re: [Bump] No log to syslog after upgrade
| 
| 
| On Thu, Sep 07, 2006 at 01:26:08PM -0700, Kurt Buff wrote:
| > Perhaps an invocation flag could be added?
| 
| You can feel free to open an enhancement BZ ticket if you like.
| Generally speaking commandline tools don't log to syslog though.
| 
| -- 
| Randomly Generated Tagline:
| If ignorance is bliss, why aren't more people happy?
| 


  

Re: [Bump] No log to syslog after upgrade

[Theo Van Dinter]

On Thu, Sep 07, 2006 at 01:26:08PM -0700, Kurt Buff wrote:
> Perhaps an invocation flag could be added?

You can feel free to open an enhancement BZ ticket if you like.
Generally speaking commandline tools don't log to syslog though.

-- 
Randomly Generated Tagline:
If ignorance is bliss, why aren't more people happy?


pgp3obpzE1wDb.pgp
Description: PGP signature

RE: [Bump] No log to syslog after upgrade

[Kurt Buff]

| From: Theo Van Dinter [mailto:[EMAIL PROTECTED]
| On Thu, Sep 07, 2006 at 09:11:22AM -0700, John D. Hardin wrote:
| > > [server]spamassassin --lint -D
| > > [22110] dbg: logger: adding facilities: all
| > > [22110] dbg: logger: logging level is DBG
| > > 
| > 
| > Is your syslog daemon configured to discard debug-level messages?
| [...]
| 
| At last check, spamassassin doesn't log to syslog.  spamd does.

And that seems a bit silly, doesn't it? Or was there a good reason for that
decision?

Perhaps an invocation flag could be added?

Kurt


  

Re: [Bump] No log to syslog after upgrade

[Theo Van Dinter]

On Thu, Sep 07, 2006 at 09:11:22AM -0700, John D. Hardin wrote:
> > [server]spamassassin --lint -D
> > [22110] dbg: logger: adding facilities: all
> > [22110] dbg: logger: logging level is DBG
> > 
> 
> Is your syslog daemon configured to discard debug-level messages?
[...]

At last check, spamassassin doesn't log to syslog.  spamd does.

-- 
Randomly Generated Tagline:
"... advise the users that although it can help, they are known problems ..."
- Stanislav Meduna


pgpUOy6qk5iRG.pgp
Description: PGP signature

Re: [Bump] No log to syslog after upgrade

[John D. Hardin]

On Thu, 7 Sep 2006, Thomas Ericsson wrote:

> [server]spamassassin --lint -D
> [22110] dbg: logger: adding facilities: all
> [22110] dbg: logger: logging level is DBG
> 

Is your syslog daemon configured to discard debug-level messages?

Are the messages being logged to /var/log/message (or whatever your
default is) rather then mail.log?  

> > After our upgrade from SA 2.6.3 to SA 3.1.3 we do not get any logs  
> > written to /var/log/mail.log anymore. Any ideas why this could be?
> >
> > Here's our setup: OSX 10.3.9, Communigate 4.2.8, CGPSA 1.4, SA 3.1.3

--
 John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/
 [EMAIL PROTECTED]FALaholic #11174pgpk -a [EMAIL PROTECTED]
 key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  Liberals love sex ed because it teaches kids to be safe around their
  sex organs. Conservatives love gun education because it teaches kids
  to be safe around guns. However, both believe that the other's
  education goals lead to dangers too terrible to contemplate.
---
 10 days until The 219th anniversary of the signing of the U.S. Constitution

[Bump] No log to syslog after upgrade

[Thomas Ericsson]

Still not resolved. Any help appreciated.

Could this be of help?

[server]spamassassin --lint -D
[22110] dbg: logger: adding facilities: all
[22110] dbg: logger: logging level is DBG



TIA
Thomas


After our upgrade from SA 2.6.3 to SA 3.1.3 we do not get any logs  
written to /var/log/mail.log anymore. Any ideas why this could be?


Here's our setup: OSX 10.3.9, Communigate 4.2.8, CGPSA 1.4, SA 3.1.3

Thomas Ericsson

No log to syslog after upgrade

[Thomas Ericsson]

After our upgrade from SA 2.6.3 to SA 3.1.3 we do not get any logs  
written to /var/log/mail.log anymore. Any ideas why this could be?


Here's our setup: OSX 10.3.9, Communigate 4.2.8, CGPSA 1.4, SA 3.1.3

Thomas Ericsson

Re: new problem after upgrade perl modeul to 3.1.4(from 3.1.2)

[Theo Van Dinter]

On Sat, Sep 02, 2006 at 04:10:45AM -0700, Linda Walsh wrote:
> Am I missing some needed configuration somewhere, or is the
> above a problem? 
> 
> It seems to be happening with every message.

It's a bug in Text::Wrap.  See
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5056

-- 
Randomly Generated Tagline:
"Windows 95 is the only true Operating System -- it does whatever it wants.
 All others should be called Co-Operating Systems." - Unknown


pgpQ7BxpSiX0Q.pgp
Description: PGP signature

new problem after upgrade perl modeul to 3.1.4(from 3.1.2)

[Linda Walsh]

I just updated to a newer version of spamassin a few days ago.

Since then I'm getting regular error messages in my spamlog:
Sep  2 03:46:03 Ishtar spamd[13106]: (?:(?<=[\s,]))* matches null string 
many times in regex; marked by <-- HERE in m/\G(?:(?<=[\s,]))* <-- HERE 
\Z/ at /usr/lib/perl5/5.8.8/Text/Wrap.pm line 46.
Sep  2 03:49:04 Ishtar spamd[13087]: (?:(?<=[\s,]))* matches null string 
many times in regex; marked by <-- HERE in m/\G(?:(?<=[\s,]))* <-- HERE 
\Z/ at /usr/lib/perl5/5.8.8/Text/Wrap.pm line 46.
Sep  2 03:52:02 Ishtar spamd[13443]: (?:(?<=[\s,]))* matches null string 
many times in regex; marked by <-- HERE in m/\G(?:(?<=[\s,]))* <-- HERE 
\Z/ at /usr/lib/perl5/5.8.8/Text/Wrap.pm line 46.

...etc..etc...


Am I missing some needed configuration somewhere, or is the
above a problem? 


It seems to be happening with every message.

Um...is this like "unsolicited reporting of a bogus condition" and would 
it fall into syslog-spam? :-)


tnx,
Linda

Re: Problems after upgrade to 3.1.4

[jdow]

From: "Theo Van Dinter" <[EMAIL PROTECTED]>


Yes, basically.  However, all rules (ignoring test rules (starts with T_)) get a
score of 1 by default, so you don't need to specifically set a score for
__METARULE.  In the end, as long as __METARULE doesn't have a score of zero,
it runs.


So far that clarifies things well enough the SARE folks should have a
clear idea what to edit.

And for testing it could be _METARULE and once testing is complete
the lead "_" could make it into __METARULE.

One more thing - will __METARULE appear in the hit various hit reports
such as the maillog and the header or wrapper score reports? The header
version of the score reports is where it can cause potential problems
with header size exceeding some systems' limits. It might also cause a
problem with maillog entries. I don't know if there is a maximum size
for a maillog line or not. For the wrapper report it probably doesn't
much matter whether it shows or not, showing might be marginally
better.

{^_^}

Re: Problems after upgrade to 3.1.4

[Theo Van Dinter]

On Thu, Jul 27, 2006 at 06:20:57PM -0700, jdow wrote:
> Even that is not clear. The way I interpret that NOW is that the
> __METARULE needs a score of some sort or it will not ever contribute
> to a META rule except via a default score that is independent of the

Yes, a subrule (__) needs a score to run, and therefore contribute to
the meta rule.  Like every other rule, subrules have a default score of 1.

> PLUS the META rules in which it is used provide scores to the final
> results.

Nope.

It's really simple:

For a rule to be executed, it needs a non-zero score.  Subrules (those
starting with "__") *never* add to the message score.  If you set a
subrule's score to 0, it won't be executed.


This, by the way, is in the documentation:

   Setting a rule’s score to 0 will disable that rule from
   running.

   If no score is given for a test by the end of the
   configuration, a default score is assigned: a score of 1.0
   is used for all tests, except those who names begin with
   ’T_’ (this is used to indicate a rule in testing) which
   receive 0.01.

   Note that test names which begin with ’__’ are indirect
   rules used to compose meta-match rules and can also act as
   prerequisites to other rules.  They are not scored or listed
   in the ’tests hit’ reports, but assigning a score of 0
   to an indirect rule will disable it from running.

> Is that right? I had read that to indicate that __METARULE would
> only contribute a value to the META rules that use it and not ever
> to the final result. Or does __METARULE need to have a "score" line
> with a non-zero value to run?

Yes, basically.  However, all rules (ignoring test rules (starts with T_)) get a
score of 1 by default, so you don't need to specifically set a score for
__METARULE.  In the end, as long as __METARULE doesn't have a score of zero,
it runs.

-- 
Randomly Generated Tagline:
"'Don't NOT follow the directions' seems unnecessary to state."
  - Roger B.A. Klorese


pgpsxHl2juAXo.pgp
Description: PGP signature

Re: Problems after upgrade to 3.1.4

[jdow]

From: "Theo Van Dinter" <[EMAIL PROTECTED]>


If you want to define a meta-rule, but do not want its individual sub-rules to
count towards the final score unless the entire meta-rule matches, give the
sub-rules names that start with '__' (two underscores).  SpamAssassin will
ignore these for scoring.


Even that is not clear. The way I interpret that NOW is that the
__METARULE needs a score of some sort or it will not ever contribute
to a META rule except via a default score that is independent of the
content of __METARULE. And if I give __METARULE as score that score
PLUS the META rules in which it is used provide scores to the final
results.

Is that right? I had read that to indicate that __METARULE would
only contribute a value to the META rules that use it and not ever
to the final result. Or does __METARULE need to have a "score" line
with a non-zero value to run?

It was all vague enough I rather automatically accept the extra dross
of the rule score of 0.001 for rules supposed to only contribute to
META rules. So it doesn't affect me except in so far as it quite
apparently has left some important rules contributors confused enough
that they made an incorrect presumption.

For testing you want to see the __METARULE type contributions to the
final score. But once the testing is done the __METARULE report
printouts become dross. They apparently for some reason did not
apply the lead "__", their bad. But I still think something that
appears in a meta rule and has a score of zero should still be
run since it DOES have a value, a variable value depending on the
meta rule's results.

{^_^}

Re: Problems after upgrade to 3.1.4

[Theo Van Dinter]

On Thu, Jul 27, 2006 at 03:48:29PM -0700, jdow wrote:
> >If you disable a rule it doesn't run.  Period.  When your eval is run 
> >it'll use a false result in place of a disabled rule.  Thus is the rule is 
> >a required part of the meta (it's ANDed) then the meta will never fire.  
> >If it's an optional part of the meta (it's ORed) then the meta will fire 
> >if it goes on to evaluate true.
> 
> That is a bad thing. And it also seems to be different from the original

Not really.

> version of SA I started with which supported META. (I started back with
> 2.20 something.) The wording back then suggested you could write a META
> rule with components scored zero so that they would not report but the
> META would still work. That behavior is depended upon for some of the
> SARE rule sets, it appears.

meta rules came out in 2.40, and those docs clearly state:

If you want to define a meta-rule, but do not want its individual sub-rules to
count towards the final score unless the entire meta-rule matches, give the
sub-rules names that start with '__' (two underscores).  SpamAssassin will
ignore these for scoring.

That hasn't changed.


I'm not sure why everyone is going crazy about this.  Absolutely nothing has
changed wrt how meta rules work.  The only change is that now it's easier to
find out when there are "problems" with the meta rules.

-- 
Randomly Generated Tagline:
"Eighty percent of married men cheat in America.  The rest cheat in Europe."
  - Jackie Mason


pgpFJpbQgCpaO.pgp
Description: PGP signature

Re: Problems after upgrade to 3.1.4

[Theo Van Dinter]

On Thu, Jul 27, 2006 at 03:53:08PM -0700, jdow wrote:
> If the scores are printed out in header fields the scores field can very
> quickly exceed the 4k size limit. This is not a good thing.

Meta subrules (those that start with "__") aren't displayed as part of the
standard rules hits.

-- 
Randomly Generated Tagline:
Fry: What's with the eye?


pgpmV44ptkVgK.pgp
Description: PGP signature

Re: Problems after upgrade to 3.1.4

[Kelson]

jdow wrote:

The wording back then suggested you could write a META
rule with components scored zero so that they would not report but the
META would still work.


If I read the runes a-right, that's still how META rules work.  Create a 
rule like this:


body __CONDITION_1  /something/

...and don't assign it a score at all.  It'll execute, the META rules 
which rely on it will process the result, no problem.


HOWEVER, if you assign that rule a score of 0, as in:

score __CONDITION_1 0

...then the rule will be disabled, will not be processed, and any meta 
rule that relies on it will (a) throw this warning and (b) assume a 
value of false for that condition.


--
Kelson Vibber
SpeedGate Communications 

Re: Problems after upgrade to 3.1.4

[jdow]

From: "Theo Van Dinter" <[EMAIL PROTECTED]>


Don't confuse "the meta rule is executed" with "the meta rule works
as expected". 


Sorry, the bad conclusion was already made and depended upon for
proper operation without cluttering the header streams or the report
fields. So the question becomes, "What is the smallest change that
can be made to SpamAssassin to effect this expected behavior?" I
believe the proposal I just made in the message I sent to the group
just before this one should meet that criterion. Even the documentation
change to clarify the issue will be mininal.


My MTA integration only allows for 4K of headers to add and I'm already
exceeding it fairly often. Adding more insignificant rules to the list
will just make it that much worse...


I'm not sure what this has to do with anything.


If the scores are printed out in header fields the scores field can very
quickly exceed the 4k size limit. This is not a good thing.

{^_^}

Re: Problems after upgrade to 3.1.4

[jdow]

From: "Daryl C. W. O'Shea" <[EMAIL PROTECTED]>


Bret Miller wrote:


So what we're saying here is that if you create a META rule on a
disabled (scored 0) rule, the META rule doesn't work?


Disabled means disabled.  Disabled rules are never run.

Quoting the relevant score config info from M:SA:Conf POD:


score SYMBOLIC_TEST_NAME n.nn [ n.nn n.nn n.nn ]

Setting a ruleâs score to 0 will disable that rule from running.


Note that test names which begin with â__â are indirect rules used to compose 
meta-match rules and can also act as prerequisites to
other rules.  They are not scored or listed in the âtests hitâ reports, but 
assigning a score of 0 to an indirect rule will disable

it from running.





Didn't work before either?


There has been *zero* functionality change.



Or still works but generates an info debug message? Guess I
should go dig out the rest of this converation and go read the bug
discussion...

Having to score every component of a META rule seems like a bad thing...
My MTA integration only allows for 4K of headers to add and I'm already
exceeding it fairly often. Adding more insignificant rules to the list
will just make it that much worse...


If you disable a rule it doesn't run.  Period.  When your eval is run it'll use a false 
result in place of a disabled rule.  Thus is the rule is a required part of the meta 
(it's ANDed) then the meta will never fire.  If it's an optional part of the meta (it's 
ORed) then the meta will fire if it goes on to evaluate true.


That is a bad thing. And it also seems to be different from the original
version of SA I started with which supported META. (I started back with
2.20 something.) The wording back then suggested you could write a META
rule with components scored zero so that they would not report but the
META would still work. That behavior is depended upon for some of the
SARE rule sets, it appears.

Could it be possible to enhance SpamAssassin with an artificial score,
"META". Internally that would be interpreted as something like 0.0001
so that the rule would fire. Then make a second change so that any rule
with a score equal to or under META, 0.0001, does not print out in the
reports individually?

If so I can (grit my teeth and) file a bugzilla request for the change.
This should be a minimal change that would create the desired and user
expected behavior.

{^_^} 

Re: Problems after upgrade to 3.1.4

[Theo Van Dinter]

On Thu, Jul 27, 2006 at 02:48:06PM -0700, Bret Miller wrote:
> So what we're saying here is that if you create a META rule on a
> disabled (scored 0) rule, the META rule doesn't work? Didn't work before
> either?

It may have worked somewhat, but probably not as intended.  It really depends
on the meta rule.

> Or still works but generates an info debug message? Guess I
> should go dig out the rest of this converation and go read the bug
> discussion...

Don't confuse "the meta rule is executed" with "the meta rule works
as expected".  If the meta rule has a non-zero score, it's executed no
matter what the dependencies are doing.  However, the rule will like
not work correctly if subrules are disabled.

In 3.1.4, conditions where a meta rule's dependencies have an issue will
cause an info message to be generated.

> Having to score every component of a META rule seems like a bad thing...

You don't, but if a subrule/dependency is disabled, then ... well, it's
disabled.

> My MTA integration only allows for 4K of headers to add and I'm already
> exceeding it fairly often. Adding more insignificant rules to the list
> will just make it that much worse...

I'm not sure what this has to do with anything.

-- 
Randomly Generated Tagline:
"In case you're wondering why I mentioned 'My Fair Lady' and then sung 
 part of a song from 'West Side Story' ... it's because I'm stupid." - Pat Sajak


pgpMewFZ6o925.pgp
Description: PGP signature

Re: Problems after upgrade to 3.1.4

[Daryl C. W. O'Shea]

Bret Miller wrote:


So what we're saying here is that if you create a META rule on a
disabled (scored 0) rule, the META rule doesn't work?


Disabled means disabled.  Disabled rules are never run.

Quoting the relevant score config info from M:SA:Conf POD:


score SYMBOLIC_TEST_NAME n.nn [ n.nn n.nn n.nn ]

Setting a ruleâs score to 0 will disable that rule from running.



Note that test names which begin with â__â are indirect rules used to 
compose meta-match rules and can also act as prerequisites to
other rules.  They are not scored or listed in the âtests hitâ reports, but 
assigning a score of 0 to an indirect rule will disable
it from running.





Didn't work before either?


There has been *zero* functionality change.



Or still works but generates an info debug message? Guess I
should go dig out the rest of this converation and go read the bug
discussion...

Having to score every component of a META rule seems like a bad thing...
My MTA integration only allows for 4K of headers to add and I'm already
exceeding it fairly often. Adding more insignificant rules to the list
will just make it that much worse...


If you disable a rule it doesn't run.  Period.  When your eval is run 
it'll use a false result in place of a disabled rule.  Thus is the rule 
is a required part of the meta (it's ANDed) then the meta will never 
fire.  If it's an optional part of the meta (it's ORed) then the meta 
will fire if it goes on to evaluate true.



Daryl

RE: Problems after upgrade to 3.1.4

[Bret Miller]

> >> These occur with spamassassin -D --lint.  RDJ is up to date, as is
> >> sa-update.
> >>
> >> [6837] info: rules: meta test DIGEST_MULTIPLE has
> undefined dependency
> >> 'DCC_CHECK'
> >> [6837] info: rules: meta test SARE_SPEC_PROLEO_M2a has dependency
> >> 'MIME_QP_LONG_LINE' with a zero score
> >> [6837] info: rules: meta test SARE_HEAD_SUBJ_RAND has undefined
> >> dependency 'SARE_XMAIL_SUSP2'
> >> [6837] info: rules: meta test SARE_HEAD_SUBJ_RAND has undefined
> >> dependency 'SARE_HEAD_XAUTH_WARN'
> >> [6837] info: rules: meta test SARE_RD_SAFE has undefined dependency
> >> 'SARE_RD_SAFE_MKSHRT'
> >> [6837] info: rules: meta test SARE_RD_SAFE has undefined dependency
> >> 'SARE_RD_SAFE_GT'
> >> [6837] info: rules: meta test SARE_RD_SAFE has undefined dependency
> >> 'SARE_RD_SAFE_TINY'
> >> [6837] info: rules: meta test SARE_OBFU_CIALIS has
> undefined dependency
> >> 'SARE_OBFU_CIALIS2'
> >> [6837] info: rules: meta test FP_MIXED_PORN3 has undefined
> dependency
> >> 'FP_PENETRATION'
> >
> > It's just info.  Some of your rules have undefined
> dependencies or are
> > disabled via a zero score.
>
> If the rule is part of a meta a zero score on the rule should not
> matter. It should still be evaluated because ultimately it has an
> indirect score via the meta rule.
>
> I like to see the sub-rules of a meta rule hitting for tracking. So
> I always issue a 0.001 score or something like that which will not
> affect results materially.

So what we're saying here is that if you create a META rule on a
disabled (scored 0) rule, the META rule doesn't work? Didn't work before
either? Or still works but generates an info debug message? Guess I
should go dig out the rest of this converation and go read the bug
discussion...

Having to score every component of a META rule seems like a bad thing...
My MTA integration only allows for 4K of headers to add and I'm already
exceeding it fairly often. Adding more insignificant rules to the list
will just make it that much worse...

I guess it's time to write my own integration code... Ugh.

Bret

Re: Problems after upgrade to 3.1.4

[jdow]

From: "Daryl C. W. O'Shea" <[EMAIL PROTECTED]>


Steven Stern wrote:

These occur with spamassassin -D --lint.  RDJ is up to date, as is
sa-update.

[6837] info: rules: meta test DIGEST_MULTIPLE has undefined dependency
'DCC_CHECK'
[6837] info: rules: meta test SARE_SPEC_PROLEO_M2a has dependency
'MIME_QP_LONG_LINE' with a zero score
[6837] info: rules: meta test SARE_HEAD_SUBJ_RAND has undefined
dependency 'SARE_XMAIL_SUSP2'
[6837] info: rules: meta test SARE_HEAD_SUBJ_RAND has undefined
dependency 'SARE_HEAD_XAUTH_WARN'
[6837] info: rules: meta test SARE_RD_SAFE has undefined dependency
'SARE_RD_SAFE_MKSHRT'
[6837] info: rules: meta test SARE_RD_SAFE has undefined dependency
'SARE_RD_SAFE_GT'
[6837] info: rules: meta test SARE_RD_SAFE has undefined dependency
'SARE_RD_SAFE_TINY'
[6837] info: rules: meta test SARE_OBFU_CIALIS has undefined dependency
'SARE_OBFU_CIALIS2'
[6837] info: rules: meta test FP_MIXED_PORN3 has undefined dependency
'FP_PENETRATION'


It's just info.  Some of your rules have undefined dependencies or are 
disabled via a zero score.


If the rule is part of a meta a zero score on the rule should not
matter. It should still be evaluated because ultimately it has an
indirect score via the meta rule.

I like to see the sub-rules of a meta rule hitting for tracking. So
I always issue a 0.001 score or something like that which will not
affect results materially.

{^_^}

Re: Problems after upgrade to 3.1.4

[Logan Shaw]

On Fri, 28 Jul 2006, sokka wrote:

I am trying to upgrade using perl butit still shows Mail::SpamAssassin
isuptodate. Let me know whether the version 3.1.4 is released for perl
installation.


If you're using a CPAN shell, you may need to give the command
"reload index" for it to grab the latest index of what's
available from CPAN and thereby see that 3.1.4 is available.

Try this:

perl -MCPAN -e shell

cpan> reload index
# it should load latest stuff from CPAN

cpan> m /Mail::SpamAssassin/
# verify that CPAN has 3.1.4

  - Logan

Re: Problems after upgrade to 3.1.4

[Theo Van Dinter]

On Fri, Jul 28, 2006 at 12:52:42AM +0530, sokka wrote:
> I am trying to upgrade using perl butit still shows Mail::SpamAssassin
> isuptodate. Let me know whether the version 3.1.4 is released for perl
> installation.

It's not quite clear what you're asking.  I think you're
asking if 3.1.4 is available via CPAN yet.  The answer to
that is yes, though it may not be out at all the mirrors yet.
(http://cpan.org/modules/by-module/Mail/Mail-SpamAssassin-3.1.4.tar.gz)

-- 
Randomly Generated Tagline:
Living your life is a task so difficult, it has never been attempted before.


pgpY5OnC8tjJz.pgp
Description: PGP signature

Re: Problems after upgrade to 3.1.4

[sokka]

Dear Groupmembers,
 
 
I am trying to upgrade using perl butit still shows Mail::SpamAssassin isuptodate. Let me know whether the version 3.1.4 is released for perl installation.
 
 
regards

RE: Problems after upgrade to 3.1.4

[Bret Miller]

> > > Does the upgrade do something like change the default local rules
> > > path, such that the dependency rules can no longer be found? Etc.
> >
> > No, the rules would likely have had these issues for a while (I
> > can't really comment on non-official rules), but with 3.1.4
> > there's now info output showing that there's a problem.
>
> Ah! Okay, I was making the assumption that the rules in question
> *were* all working before the upgrade.
>
> My mistake (and an easy one to make, too)...

I figure the SARE guys will be working on their rules to fix them
soon...

Bret

Re: Problems after upgrade to 3.1.4

[John D. Hardin]

On Thu, 27 Jul 2006, Theo Van Dinter wrote:

> > Does the upgrade do something like change the default local rules
> > path, such that the dependency rules can no longer be found? Etc.
> 
> No, the rules would likely have had these issues for a while (I
> can't really comment on non-official rules), but with 3.1.4
> there's now info output showing that there's a problem.

Ah! Okay, I was making the assumption that the rules in question
*were* all working before the upgrade.

My mistake (and an easy one to make, too)...

--
 John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/
 [EMAIL PROTECTED]FALaholic #11174pgpk -a [EMAIL PROTECTED]
 key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  The first time I saw a bagpipe, I thought the player was torturing
  an octopus. I was amazed they could scream so loudly.
-- cat_herder_5263 on Y! SCOX
---

Re: Problems after upgrade to 3.1.4

[Raymond Dijkxhoorn]

Hi!


It's just info.  Some of your rules have undefined dependencies or are
disabled via a zero score.



That's fairly obvious from the warning message.

I think both OPs point is that a 3.1.3 -> 3.1.4 (i.e. minor version
bugfix) upgrade shouldn't suddenly make a bunch of previously-working
rules simply disappear...

Does the upgrade do something like change the default local rules
path, such that the dependency rules can no longer be found? Etc.


It warns you that some of your rules have missing elements. Go look at 
those rules and get it fixed at theirs sources ;)


Bye,
Raymond.

Re: Problems after upgrade to 3.1.4

[Theo Van Dinter]

On Thu, Jul 27, 2006 at 11:21:54AM -0700, John D. Hardin wrote:
> I think both OPs point is that a 3.1.3 -> 3.1.4 (i.e. minor version
> bugfix) upgrade shouldn't suddenly make a bunch of previously-working
> rules simply disappear...

This wouldn't make rules disappear.  It's informational output, but not a
lint error.  You can follow the discussion in
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4347 if you want. :)

> Does the upgrade do something like change the default local rules
> path, such that the dependency rules can no longer be found? Etc.

No, the rules would likely have had these issues for a while (I can't
really comment on non-official rules), but with 3.1.4 there's now info output
showing that there's a problem.  (before, people would have had to manually
figure out that meta dependencies have issues)

-- 
Randomly Generated Tagline:
"The random quantum fluctuations of my brain are historical accidents that
 happen to have decided that the concepts of dynamic scoping and lexical
 scoping are orthogonal and should remain that way." - Larry Wall


pgpefYDYI2xvo.pgp
Description: PGP signature

Re: Problems after upgrade to 3.1.4

[Daryl C. W. O'Shea]

John D. Hardin wrote:

On Thu, 27 Jul 2006, Daryl C. W. O'Shea wrote:


Steven Stern wrote:

These occur with spamassassin -D --lint.  RDJ is up to date, as is
sa-update.

[6837] info: rules: meta test DIGEST_MULTIPLE has undefined dependency
'DCC_CHECK'


...etc

It's just info.  Some of your rules have undefined dependencies or are 
disabled via a zero score.


That's fairly obvious from the warning message.


I thought so too, but a lot of people have asked.



I think both OPs point is that a 3.1.3 -> 3.1.4 (i.e. minor version
bugfix) upgrade shouldn't suddenly make a bunch of previously-working
rules simply disappear...


Who said the rules previously worked.  Who said they don't work now?



Does the upgrade do something like change the default local rules
path, such that the dependency rules can no longer be found? Etc.


Like I said, it's *just* info.  It's always been that way -- the rules 
have always had undefined or disabled dependencies.  We just let you 
know now -- see bug 4347.



Daryl

Re: Problems after upgrade to 3.1.4

[John D. Hardin]

On Thu, 27 Jul 2006, Daryl C. W. O'Shea wrote:

> Steven Stern wrote:
> > These occur with spamassassin -D --lint.  RDJ is up to date, as is
> > sa-update.
> > 
> > [6837] info: rules: meta test DIGEST_MULTIPLE has undefined dependency
> > 'DCC_CHECK'

...etc

> It's just info.  Some of your rules have undefined dependencies or are 
> disabled via a zero score.

That's fairly obvious from the warning message.

I think both OPs point is that a 3.1.3 -> 3.1.4 (i.e. minor version
bugfix) upgrade shouldn't suddenly make a bunch of previously-working
rules simply disappear...

Does the upgrade do something like change the default local rules
path, such that the dependency rules can no longer be found? Etc.

--
 John Hardin KA7OHZICQ#15735746http://www.impsec.org/~jhardin/
 [EMAIL PROTECTED]FALaholic #11174pgpk -a [EMAIL PROTECTED]
 key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  The first time I saw a bagpipe, I thought the player was torturing
  an octopus. I was amazed they could scream so loudly.
-- cat_herder_5263 on Y! SCOX
---

Re: Problems after upgrade to 3.1.4

[Daryl C. W. O'Shea]

Steven Stern wrote:

These occur with spamassassin -D --lint.  RDJ is up to date, as is
sa-update.

[6837] info: rules: meta test DIGEST_MULTIPLE has undefined dependency
'DCC_CHECK'
[6837] info: rules: meta test SARE_SPEC_PROLEO_M2a has dependency
'MIME_QP_LONG_LINE' with a zero score
[6837] info: rules: meta test SARE_HEAD_SUBJ_RAND has undefined
dependency 'SARE_XMAIL_SUSP2'
[6837] info: rules: meta test SARE_HEAD_SUBJ_RAND has undefined
dependency 'SARE_HEAD_XAUTH_WARN'
[6837] info: rules: meta test SARE_RD_SAFE has undefined dependency
'SARE_RD_SAFE_MKSHRT'
[6837] info: rules: meta test SARE_RD_SAFE has undefined dependency
'SARE_RD_SAFE_GT'
[6837] info: rules: meta test SARE_RD_SAFE has undefined dependency
'SARE_RD_SAFE_TINY'
[6837] info: rules: meta test SARE_OBFU_CIALIS has undefined dependency
'SARE_OBFU_CIALIS2'
[6837] info: rules: meta test FP_MIXED_PORN3 has undefined dependency
'FP_PENETRATION'


It's just info.  Some of your rules have undefined dependencies or are 
disabled via a zero score.


Daryl

Problems after upgrade to 3.1.4

[Steven Stern]

These occur with spamassassin -D --lint.  RDJ is up to date, as is
sa-update.

[6837] info: rules: meta test DIGEST_MULTIPLE has undefined dependency
'DCC_CHECK'
[6837] info: rules: meta test SARE_SPEC_PROLEO_M2a has dependency
'MIME_QP_LONG_LINE' with a zero score
[6837] info: rules: meta test SARE_HEAD_SUBJ_RAND has undefined
dependency 'SARE_XMAIL_SUSP2'
[6837] info: rules: meta test SARE_HEAD_SUBJ_RAND has undefined
dependency 'SARE_HEAD_XAUTH_WARN'
[6837] info: rules: meta test SARE_RD_SAFE has undefined dependency
'SARE_RD_SAFE_MKSHRT'
[6837] info: rules: meta test SARE_RD_SAFE has undefined dependency
'SARE_RD_SAFE_GT'
[6837] info: rules: meta test SARE_RD_SAFE has undefined dependency
'SARE_RD_SAFE_TINY'
[6837] info: rules: meta test SARE_OBFU_CIALIS has undefined dependency
'SARE_OBFU_CIALIS2'
[6837] info: rules: meta test FP_MIXED_PORN3 has undefined dependency
'FP_PENETRATION'

-- 

  Steve

Re: Problems after upgrade to SA 3.1.3: PerMsgStatus.pm can't locate object methods "check_for_spf_neutral"....

[Thomas Schlosser]

Thanks for the immediate answer!It seems that the old SA was under /usr/lib/perl5/vendor_perl/5.8.6/Mail/SpamAssassin/while the new one under /usr/lib/perl5/site_perl/5.8.6/Mail/SpamAssassin/rpm reported two packages spamassassin and perl-spamassassin.
I have deinstalled these using YAST (rpm reported dependencies, YAST too, but I am used to YAST more)Currently I am reinstalling via perl -MCPAN and hope, that the situation will change to the better ;-)
Thx for the momentThomas2006/6/10, Radoslaw Zielinski <[EMAIL PROTECTED]>:
Thomas Schlosser <[EMAIL PROTECTED]> [10-06-2006 15:38]:[...]> I updated it via perl -MCPAN - e shell -> force install Mail::SpamAssassin
> The output was too long to have a chance to see if any problems have been> reportet.New SA should have been installed somewhere around /usr/local (if yourperl is build with -Dvendorlib; probably is).  Locate and uninstall old
version of SA:  find `perl -le 'map print,grep/\//,@INC'` | grep SpamAssassinI guess the right way in your case would be 'rpm -qa|grep -i spamas' andrpm -e the output.  You might have to reinstall using 
CPAN.pm afterwards.--Radosław Zieliński <[EMAIL PROTECTED]>

Re: Problems after upgrade to SA 3.1.3: PerMsgStatus.pm can't locate object methods "check_for_spf_neutral"....

[Radoslaw Zielinski]

Thomas Schlosser <[EMAIL PROTECTED]> [10-06-2006 15:38]:
[...]
> I updated it via perl -MCPAN - e shell -> force install Mail::SpamAssassin
> The output was too long to have a chance to see if any problems have been
> reportet.

New SA should have been installed somewhere around /usr/local (if your
perl is build with -Dvendorlib; probably is).  Locate and uninstall old
version of SA:

  find `perl -le 'map print,grep/\//,@INC'` | grep SpamAssassin

I guess the right way in your case would be 'rpm -qa|grep -i spamas' and
rpm -e the output.  You might have to reinstall using CPAN.pm afterwards.

-- 
Radosław Zieliński <[EMAIL PROTECTED]>


pgp2zuDOSIs6J.pgp
Description: PGP signature

Problems after upgrade to SA 3.1.3: PerMsgStatus.pm can't locate object methods "check_for_spf_neutral"....

[Thomas Schlosser]

Hi,I have updated my SA installation yesterday. Most but not all seems to run well.In my mail.log I constantly find these errors all referring on some methods called from PerMsgStatus.pm:snip
Jun 10 12:21:54 homesrv spamd[6367]: Failed to run __ENV_AND_HDR_FROM_MATCH SpamAssassin test, skipping:__(Can't locate object method "check_for_matching_env_and_hdr_from" via package "Mail::SpamAssassin::PerMsgStatus" at /usr/lib/perl5/vendor_perl/5.8.6/Mail/SpamAssassin/PerMsgStatus.pm line 2340,  line 522._)
Jun 10 12:21:54 homesrv spamd[6367]: Failed to run USER_IN_DEF_SPF_WL SpamAssassin test, skipping:__(Can't locate object method "check_for_def_spf_whitelist_from" via package "Mail::SpamAssassin::PerMsgStatus" at /usr/lib/perl5/vendor_perl/5.8.6/Mail/SpamAssassin/PerMsgStatus.pm line 2340,  line 522._)
Jun 10 12:21:54 homesrv spamd[6367]: Failed to run RATWARE_EFROM SpamAssassin test, skipping:__(Can't locate object method "check_ratware_envelope_from" via package "Mail::SpamAssassin::PerMsgStatus" at /usr/lib/perl5/vendor_perl/5.8.6/Mail/SpamAssassin/PerMsgStatus.pm line 2340,  line 522._)
Jun 10 12:21:54 homesrv spamd[6367]: Failed to run __RATWARE_NAME_ID SpamAssassin test, skipping:__(Can't locate object method "check_ratware_name_id" via package "Mail::SpamAssassin::PerMsgStatus" at /usr/lib/perl5/vendor_perl/5.8.6/Mail/SpamAssassin/PerMsgStatus.pm line 2340,  line 522._)
Jun 10 12:21:54 homesrv spamd[6367]: Failed to run SPF_NEUTRAL SpamAssassin test, skipping:__(Can't locate object method "check_for_spf_neutral" via package "Mail::SpamAssassin::PerMsgStatus" at /usr/lib/perl5/vendor_perl/5.8.6/Mail/SpamAssassin/PerMsgStatus.pm line 2340,  line 522._)
Jun 10 12:21:54 homesrv spamd[6367]: Failed to run USER_IN_SPF_WHITELIST SpamAssassin test, skipping:__(Can't locate object method "check_for_spf_whitelist_from" via package "Mail::SpamAssassin::PerMsgStatus" at /usr/lib/perl5/vendor_perl/5.8.6/Mail/SpamAssassin/PerMsgStatus.pm line 2340,  line 522._)
snap---Some mails e received in the meanwhile where correctly identified as spam, so genereally it seems to work. Most of them qualified by "URIBL_xx_SURBL"-tests.I am running SA as spamd/spamc under a postfix on SUSE 
9.3homesrv:/etc/mail/spamassassin # spamassassin -VSpamAssassin version 3.1.3  running on Perl version 5.8.6I updated it via perl -MCPAN - e shell -> force install Mail::SpamAssassinThe output was too long to have a chance to see if any problems have been reportet.
THe install without force reported 99,xx% ok.Interestingly spamassassin -V report 3.1.3, but spam mails contain a "version=3.0.4" which was the previously run version.Is this ahint (on a now mixed installation)?
Any hints how I can debug the situation?I tried to use "spamassassin -V Thanks for any feedbackThomas

Re: lint errors after upgrade

[Doc Schneider]

Jean-Paul Natola wrote:

Hi all

After upgrading to 3.1.1

I'm getting a bunch of 



[36993] warn: config: SpamAssassin failed to parse line,
"SARE_RMML_Stock27_.166" is not valid for "score", skipping:
score_SARE_RMML_Stock27_.166

Is there something , or should I say, what step did I miss?





Upgrade 70_sare_stocks.cf

The leading 0 issue was taken care of in version 01.00.07 and it is 
currently on 01.00.16


--

 -Doc

 SA/SARE -- Ninja
   3:20pm  up 60 days, 12:40, 17 users,  load average: 0.79, 0.56, 0.44

 SARE HQ  http://www.rulesemporium.com/

Re: lint errors after upgrade

[Theo Van Dinter]

On Wed, Mar 22, 2006 at 02:56:22PM -0500, Matt Kettler wrote:
> score SARE_RMML_Stock27 .166

actually it should be "score SARE_RMML_Stock27 0.166".  not having a
leading 0 is invalid.

-- 
Randomly Generated Tagline:
"Is there a space between the wall and paint?"  - Bob Lazarus


pgp2A4wCXStMA.pgp
Description: PGP signature

Re: lint errors after upgrade

[Matt Kettler]

Jean-Paul Natola wrote:
> Hi all
> 
> After upgrading to 3.1.1
> 
> I'm getting a bunch of 
> 
> 
> [36993] warn: config: SpamAssassin failed to parse line,
> "SARE_RMML_Stock27_.166" is not valid for "score", skipping:
> score_SARE_RMML_Stock27_.166
> 
> Is there something , or should I say, what step did I miss?
> 

Looks like you're using sare_stocks.cf, and you have a corrupted version


It should be:

score SARE_RMML_Stock27 .166

Not:

score_SARE_RMML_Stock27_.166


Get a fresh copy and replace yours:

http://www.rulesemporium.com/rules/70_sare_stocks.cf

(And DO NOT copy-paste it, download it directly to your SA box with wget or curl
if you can)

lint errors after upgrade

[Jean-Paul Natola]

Hi all

After upgrading to 3.1.1

I'm getting a bunch of 


[36993] warn: config: SpamAssassin failed to parse line,
"SARE_RMML_Stock27_.166" is not valid for "score", skipping:
score_SARE_RMML_Stock27_.166

Is there something , or should I say, what step did I miss?







Jean-Paul Natola
Network Administrator
Information Technology
Family Care International
588 Broadway Suite 503
New York, NY 10012
Phone:212-941-5300 xt 36
Fax:  212-941-5563
Mailto: [EMAIL PROTECTED]

Re: FW: headers creeping into message body after upgrade to 3.1.1 - Patch

[Forrest Aldrich]

Paul,

Thanks for posting the patch.

This works, I just tested it.  I also forwarded it to Dan Nelson 
(spamass-milter).   I'm  not certain this is the "correct" way to fix 
it, though.   Will let you know if I hear more.



Thanks.



Paul Stavrides wrote:

version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on mail.forrie.com
X-Virus-Scanned: ClamAV 0.88/1346/Tue Mar 21 04:03:02 2006 on mail.forrie.com
X-Virus-Status: Clean


Got this patch from a FreeBSD user yesterday.  I tested it for a day and
all seems just fine.

  This backs out the 3.1.1 change and reverts to the 3.1.0 behavior.
This
leaves some 3.1.1 CRLF code in Message.pm, but it now has no effect.
Normal processing of the headers fixes any trouble I was having down
stream.

--paul

  Here is the patch:

*** lib/Mail/SpamAssassin/PerMsgStatus.pm_orig  Sat Mar 18 16:36:31 2006
--- lib/Mail/SpamAssassin/PerMsgStatus.pm   Sat Mar 18 16:41:41 2006
***
*** 684,704 
  sub rewrite_mail {
my ($self) = @_;
  
!   my $msg = $self->{msg}->get_mbox_separator() || '';
! 
if ($self->{is_spam} && $self->{conf}->{report_safe}) {

! $msg .= $self->rewrite_report_safe();
}
else {
! $msg .= $self->rewrite_no_report_safe();
!   }
! 
!   # Make the line endings appropriate for the situation

!   if ($self->{msg}->{line_ending} ne "\n") {
! $msg =~ s/\r?\n/$self->{msg}->{line_ending}/g;
}
- 
-   return $msg;

  }
  
  # rewrite the message in report_safe mode

--- 684,696 
  sub rewrite_mail {
my ($self) = @_;
  
!   my $mbox = $self->{msg}->get_mbox_separator() || '';

if ($self->{is_spam} && $self->{conf}->{report_safe}) {
! return $mbox.$self->rewrite_report_safe();
}
else {
! return $mbox.$self->rewrite_no_report_safe();
}
  }
  
  # rewrite the message in report_safe mode


  

FW: headers creeping into message body after upgrade to 3.1.1 - Patch

[Paul Stavrides]

Got this patch from a FreeBSD user yesterday.  I tested it for a day and
all seems just fine.

  This backs out the 3.1.1 change and reverts to the 3.1.0 behavior.
This
leaves some 3.1.1 CRLF code in Message.pm, but it now has no effect.
Normal processing of the headers fixes any trouble I was having down
stream.

--paul

  Here is the patch:

*** lib/Mail/SpamAssassin/PerMsgStatus.pm_orig  Sat Mar 18 16:36:31 2006
--- lib/Mail/SpamAssassin/PerMsgStatus.pm   Sat Mar 18 16:41:41 2006
***
*** 684,704 
  sub rewrite_mail {
my ($self) = @_;
  
!   my $msg = $self->{msg}->get_mbox_separator() || '';
! 
if ($self->{is_spam} && $self->{conf}->{report_safe}) {
! $msg .= $self->rewrite_report_safe();
}
else {
! $msg .= $self->rewrite_no_report_safe();
!   }
! 
!   # Make the line endings appropriate for the situation
!   if ($self->{msg}->{line_ending} ne "\n") {
! $msg =~ s/\r?\n/$self->{msg}->{line_ending}/g;
}
- 
-   return $msg;
  }
  
  # rewrite the message in report_safe mode
--- 684,696 
  sub rewrite_mail {
my ($self) = @_;
  
!   my $mbox = $self->{msg}->get_mbox_separator() || '';
if ($self->{is_spam} && $self->{conf}->{report_safe}) {
! return $mbox.$self->rewrite_report_safe();
}
else {
! return $mbox.$self->rewrite_no_report_safe();
}
  }
  
  # rewrite the message in report_safe mode

RE: headers creeping into message body after upgrade to 3.1.1

[Paul Stavrides]

Theo, Carl,

I poked around the code this morning and I think for us, this is going
to be a tougher problem to solve than I first thought.

Theo, you are correct AFAIK the calls to the library routines
responsible for wrapping lines and adding in the \t chars are confused
by the lines they are receiving.  I could not find a clean way to hack
this in the spamass-milter code.  I hate to go add code to the milter to
remove what is being added to by spamd.

The -M switch is not an option for us becase we depend on headers to do
a downstream sort of tagged e-mail in the Windows server.

This is fun poking around these systems, but not really what I do day to
day.  I could use some pointers if you would.  I am a little surprised
this isn't causing more trouble than it seems to be.

Thanks again,

--paul

Re: headers creeping into message body after upgrade to 3.1.1

[Theo Van Dinter]

On Thu, Mar 16, 2006 at 12:33:50AM -0600, David B Funk wrote:
> Silly question; would it be sufficient for the milter to just canonicalize
> the message that it passes to SA by converting CRLF to a plain LF?
> Or better, do the inverse of SA; for it to look at the first line of
> the message and if terminated with a plain 'LF' take no special action
> but if terminated with a 'CRLF' then go into canonicalize mode and
> convert all instances of 'CRLF' to plain 'LF'.

You could do that, though as far as the milter is concerned, it'll always
see CRLF for the incoming mail.  IMO, the milter ought to be able to
handle CRLF or LF from spam[cd] and do the right thing for what libmilter
expects when replacing/adding/etc headers.  It's less work for the milter
(doesn't have to go over the entire message) and it also means that it's
not relying on what SpamAssassin does.

-- 
Randomly Generated Tagline:
"I believe in getting into hot water; it keeps you clean." - G. K. Chesterton


pgpzempPDG88a.pgp
Description: PGP signature

Re: headers creeping into message body after upgrade to 3.1.1

[David B Funk]

On Wed, 15 Mar 2006, Theo Van Dinter wrote:

> The problem is caused by a specific feature that was added into
> SpamAssassin in 3.1.1 -- namely that we'll use the same line endings that the
> original message uses (LF vs CRLF).  spamass-milter relied on the previous
> behavior (always use LF), which happened to work well with what libmilter
> expected.
>
> So in this case, I would expect the spamass-milter code to be modified
> to take into account that line endings could either be CRLF (3.1.1 and
> beyond) or LF (3.1.0 and previous).

Silly question; would it be sufficient for the milter to just canonicalize
the message that it passes to SA by converting CRLF to a plain LF?
Or better, do the inverse of SA; for it to look at the first line of
the message and if terminated with a plain 'LF' take no special action
but if terminated with a 'CRLF' then go into canonicalize mode and
convert all instances of 'CRLF' to plain 'LF'.

Thus if SA (3.1 or 3.1.1) saw just 'LF' line endings should it
return data in the form that libmilter expects?

Dave

-- 
Dave Funk  University of Iowa
College of Engineering
319/335-5751   FAX: 319/384-0549   1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include 
Better is not better, 'standard' is better. B{

Re: headers creeping into message body after upgrade to 3.1.1

[Carl Brewer]

Theo Van Dinter wrote:

On Thu, Mar 16, 2006 at 01:19:59PM +1100, Carl Brewer wrote:

Previously, the milter could assume that folding was going to happen via
"\n\t", but now it's "\r\n\t".

Does this mean that a change is needed in spamass-milter or
spamassassin?  It seems odd that this started with 3.1.1 but
didn't occur under 3.0.

Ie: do I look at patching spamass-milter or will the spamassassin
community fix it at their end?


The problem is caused by a specific feature that was added into
SpamAssassin in 3.1.1 -- namely that we'll use the same line endings that the
original message uses (LF vs CRLF).  spamass-milter relied on the previous
behavior (always use LF), which happened to work well with what libmilter
expected.

So in this case, I would expect the spamass-milter code to be modified
to take into account that line endings could either be CRLF (3.1.1 and
beyond) or LF (3.1.0 and previous).


Ok, I'll have a poke through spamass-milter and see if I can patch it

thankyou

Carl

Re: headers creeping into message body after upgrade to 3.1.1

[Theo Van Dinter]

On Thu, Mar 16, 2006 at 01:19:59PM +1100, Carl Brewer wrote:
> >Previously, the milter could assume that folding was going to happen via
> >"\n\t", but now it's "\r\n\t".
> 
> Does this mean that a change is needed in spamass-milter or
> spamassassin?  It seems odd that this started with 3.1.1 but
> didn't occur under 3.0.
> 
> Ie: do I look at patching spamass-milter or will the spamassassin
> community fix it at their end?

The problem is caused by a specific feature that was added into
SpamAssassin in 3.1.1 -- namely that we'll use the same line endings that the
original message uses (LF vs CRLF).  spamass-milter relied on the previous
behavior (always use LF), which happened to work well with what libmilter
expected.

So in this case, I would expect the spamass-milter code to be modified
to take into account that line endings could either be CRLF (3.1.1 and
beyond) or LF (3.1.0 and previous).

(alternately, libmilter could be modified to handle either LF or CRLF, which
would probably be easier to code, but harder to get that API changed...)

-- 
Randomly Generated Tagline:
"In defense of President Bush, that pretzel -- it was one of the really
 twisty kind."   - Unknown


pgpIzNXfBl3m1.pgp
Description: PGP signature

Re: headers creeping into message body after upgrade to 3.1.1

[Carl Brewer]

Theo Van Dinter wrote:

On Wed, Mar 15, 2006 at 04:31:24PM -0500, Paul Stavrides wrote:

The problem is an extra an extra "0D"  in the X-Spam-Checker-Version
line, such that I see an "...0D 0D 0A 09..." by the time I look at the
headers in Windows.  The line is getting munged when it is getting
wrapped.


Interesting.  I was thinking it was the spamass-milter code...
But researching things a little more, it looks like it's actually the
milter API/library:

http://www.milter.org/milter_api/smfi_chgheader.html

"If longer headers are needed, make them multi-line. To make a multi-line
header, insert a line feed (ASCII 0x0a, or \n in C) followed by at least
one whitespace character such as a space (ASCII 0x20) or tab (ASCII 0x09,
or \t in C). The line feed should NOT be preceded by a carriage return
(ASCII 0x0d); the MTA will add this automatically."

Previously, the milter could assume that folding was going to happen via
"\n\t", but now it's "\r\n\t".


Does this mean that a change is needed in spamass-milter or
spamassassin?  It seems odd that this started with 3.1.1 but
didn't occur under 3.0.

Ie: do I look at patching spamass-milter or will the spamassassin
community fix it at their end?


Looking at the spamass-milter code, it looks like "-M" may also be a
work-around for you (disables all markup).


Yes, I've done that for now, thankyou.

Re: headers creeping into message body after upgrade to 3.1.1

[Theo Van Dinter]

On Wed, Mar 15, 2006 at 04:31:24PM -0500, Paul Stavrides wrote:
> The problem is an extra an extra "0D"  in the X-Spam-Checker-Version
> line, such that I see an "...0D 0D 0A 09..." by the time I look at the
> headers in Windows.  The line is getting munged when it is getting
> wrapped.

Interesting.  I was thinking it was the spamass-milter code...
But researching things a little more, it looks like it's actually the
milter API/library:

http://www.milter.org/milter_api/smfi_chgheader.html

"If longer headers are needed, make them multi-line. To make a multi-line
header, insert a line feed (ASCII 0x0a, or \n in C) followed by at least
one whitespace character such as a space (ASCII 0x20) or tab (ASCII 0x09,
or \t in C). The line feed should NOT be preceded by a carriage return
(ASCII 0x0d); the MTA will add this automatically."

Previously, the milter could assume that folding was going to happen via
"\n\t", but now it's "\r\n\t".


Carl Brewer:
> Is it possible to just turn off the X-Spam-Status header as a quick
> workaround?  I tried this in my local.cf but it didn't seem to work :
> 
> report_safe 0
> remove_header all X-Spam-Status

It'd be "remove_header all Status".  You can try it, though if the problem is
wrapping, you may end up with problems with Checker-Version which you can't
disable (short of editing SA modules).

Looking at the spamass-milter code, it looks like "-M" may also be a
work-around for you (disables all markup).

-- 
Randomly Generated Tagline:
Do nothing unless you must, and when you must act -- hesitate.


pgpJ4OWNwnM4C.pgp
Description: PGP signature

Re: headers creeping into message body after upgrade to 3.1.1

[Carl Brewer]

Paul Stavrides wrote:

Felicity,

 

Thanks for the tips. 

 

We too are having the problem of headers creeping into out received 
e-mail.  Difference here is that our setup is a Linux front end to 
MSExchange.  So we run SA site-wide and use Milter to keep the crap out 
of Exchange.  Works like a champ on our 95% Spam e-mail stream.


 

The problem is an extra an extra “0D”  in the X-Spam-Checker-Version 
line, such that I see an “…0D 0D 0A 09…” by the time I look at the 
headers in Windows.  The line is getting munged when it is getting wrapped.


 


We have the problem with:

 


SA 3.1.1

Spamass-Milter 3.0 (savannah.nongnu.org version)

 

There is no problem with SA 3.1.1 at the command line.  The setup was 
working with SA 3.0.3


This is identical to the problem I'm seeing (except NetBSD, not
GNU/Linux is the host OS).

I checked the output of the sa/spamc from the command line and the 
trouble isn’t there.  The file generated in the Linux environment is 
wrapped with just an “…0A…” as you would expect in that setting.


 

I guess we have a problem with the Milter, but we have the current 
version.  I wonder if there are any quick fixes in the Milter setup?  
Why do I have to wrap the header lines at all?  I am down to two X- 
lines anyhow:  the score and the version.


Is it possible to just turn off the X-Spam-Status header as a quick
workaround?  I tried this in my local.cf but it didn't seem to work :

report_safe 0
remove_header all X-Spam-Status

Re: headers creeping into message body after upgrade to 3.1.1

[Theo Van Dinter]

On Thu, Mar 16, 2006 at 08:29:29AM +1100, Carl Brewer wrote:
> >Is this reproducable with spamassassin or spamc/spamd from a commandline? 
> 
> I'm not sure, how would I test it?

Something similar to "spamassassin < file_with_message" or
"spamc < file_with_message" if you want to test spamd.

-- 
Randomly Generated Tagline:
"In defense of President Bush, that pretzel -- it was one of the really
 twisty kind."   - Unknown


pgpncYrKGkLwY.pgp
Description: PGP signature

Re: headers creeping into message body after upgrade to 3.1.1

[Paul Stavrides]

Title: Header1








Felicity,

 

Thanks for the tips.  

 

We too are having the problem of headers creeping into out
received e-mail.  Difference here is that our setup is a Linux front end
to MSExchange.  So we run SA site-wide and use Milter to keep the crap out
of Exchange.  Works like a champ on our 95% Spam e-mail stream.

 

The problem is an extra an extra “0D”  in the
X-Spam-Checker-Version line, such that I see an “…0D 0D 0A 09…”
by the time I look at the headers in Windows.  The line is getting munged
when it is getting wrapped.

 

We have the problem with:

 

    SA
3.1.1

    Spamass-Milter
3.0 (savannah.nongnu.org version)

 

There is no problem with SA 3.1.1 at the command line. 
The setup was working with SA 3.0.3

 

I checked the output of the sa/spamc from the command line
and the trouble isn’t there.  The file generated in the Linux
environment is wrapped with just an “…0A…” as you would
expect in that setting.

 

I guess we have a problem with the Milter, but we have the
current version.  I wonder if there are any quick fixes in the Milter
setup?  Why do I have to wrap the header lines at all?  I am down to
two X- lines anyhow:  the score and the version.

 

Thanks again,

 

--paul

Re: headers creeping into message body after upgrade to 3.1.1

[Carl Brewer]

Theo Van Dinter wrote:

On Wed, Mar 15, 2006 at 06:47:58PM +1100, Carl Brewer wrote:


X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00

   autolearn=ham version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on
   rollcage2.bl.echidna.id.au

It looks like sometimes spamassassin (or spamass-milter?) is
adding a cr/lf in the X-Spam-Status header, which makes it
leak out into the body of the mail. This wasn't happening with 3.0,
and is new behaviour with 3.1.1.



Is this reproducable with spamassassin or spamc/spamd from a commandline? 


I'm not sure, how would I test it?



so, please open up a ticket in Bugzilla and attach the mail and we'll see what
we can do.  If not, I'd talk to the spamass-milter folks ...  3.1 is different
from 3.0, and you may need to upgrade the milter.


Ok, thanks!

Carl

Re: headers creeping into message body after upgrade to 3.1.1

[Theo Van Dinter]

On Wed, Mar 15, 2006 at 06:47:58PM +1100, Carl Brewer wrote:
> X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00
> 
> autolearn=ham version=3.1.1
> X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on
> rollcage2.bl.echidna.id.au
> 
> It looks like sometimes spamassassin (or spamass-milter?) is
> adding a cr/lf in the X-Spam-Status header, which makes it
> leak out into the body of the mail. This wasn't happening with 3.0,
> and is new behaviour with 3.1.1.

Is this reproducable with spamassassin or spamc/spamd from a commandline?  If
so, please open up a ticket in Bugzilla and attach the mail and we'll see what
we can do.  If not, I'd talk to the spamass-milter folks ...  3.1 is different
from 3.0, and you may need to upgrade the milter.

-- 
Randomly Generated Tagline:
"Even if you are on the right track, you'll get run over if you just
 sit there." - Will Rogers


pgphQ2BQNxBTo.pgp
Description: PGP signature

Re: headers creeping into message body after upgrade to 3.1.1

[Loren Wilton]

> Since I upgraded, I'm seeing bits of the X-Spam-Header message
> in my mail bodies, like this :

The latest version changed things to make life on Windows systems better.
Instead of always using a \n for a line ending, it looks at the kind of line
ending it got on the first line of the input file, and uses that for the
output file.  Thus, if \n comes in, \n will go out.  If \r\n comes in, \r\n
will go out.

In theory this should work fine in all cases.  But we know about theories
and the real world.

>From what you are seeing I would make the following guesses:

The input to SA has the first line encoded with \r\n, so that is what SA is
using.

Somehow that line wrap case was encoded differently upstream, and after SA
stuck on the \r\n ended up with something like \r\r\n or \n\r\n.

Alternately, the thing folowing SA works correctly with \r\n terminated
lines, except in the case of a continuation line, and there it gets
confused.

Loren

headers creeping into message body after upgrade to 3.1.1

[Carl Brewer]

Hello,

I just upgraded to 3.1.1 on a NetBSD box via pkgsrc, and
am using sendmail 8.13.5 with spamass-milter 0.3.0, and sendmail
is configured to use cyrus imapd as its local delivery agent.

Since I upgraded, I'm seeing bits of the X-Spam-Header message
in my mail bodies, like this :

To: Carl Brewer <[EMAIL PROTECTED]>
Subject: Re: boing 2
References: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on 
rollcage2.bl.echidna.id.au

X-Virus-Status: Clean
X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00

autolearn=ham version=3.1.1
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on
rollcage2.bl.echidna.id.au


It looks like sometimes spamassassin (or spamass-milter?) is
adding a cr/lf in the X-Spam-Status header, which makes it
leak out into the body of the mail. This wasn't happening with 3.0,
and is new behaviour with 3.1.1.

my config dir contains the following rulesets :

-rw-r--r--  1 root  wheel  15311 Mar 15 18:38 72_sare_redirect_post3.0.0.cf
-rw-r--r--  1 root  wheel   1059 Mar 15 00:41 init.pre
-rw-r--r--  1 root  wheel642 Mar 15 18:30 local.cf
-rwxr-xr-x  1 root  wheel   1642 Mar 15 18:37 update.pl
-rw-r--r--  1 root  wheel   1869 Mar 15 00:41 user_prefs.template
-rw-r--r--  1 root  wheel   2398 Jan 11 09:42 v310.pre



spamass-milter and spamd are running as follows :

root 5861  0.0  2.1 21756 21860 ?  I 6:38PM  0:01.81 perl: 
spamd child
root 7658  0.0  2.0 20012 21444 ?  Ss6:38PM  0:01.81 
/usr/pkg/bin/perl -T -w /usr/pkg/bin/spamd -H -c -d -r /var/run/spamd.pid
root13207  0.0  0.0  2272  1132 ?  IWsa  9:54AM  0:02.96 
/usr/pkg/sbin/spamass-milter -u nobody -r -1 -p /var/run/spamass.sock -f
root15359  0.0  0.7 20012  7408 ?  I 6:38PM  0:00.01 perl: 
spamd child



I've tried a number of things in local.cf :

score SPF_HELO_FAIL 10.000
report_safe 0
remove_header all X-Spam-Status

But this hasn't removed the header or fixed the leak into the
message body.

Any suggestions?

Thanks!

Carl

autolearn=failed ---- after upgrade to 3.11

[Steven Manross]

X-Spam-Status: No, score=-2.6 required=5.0
tests=AWL=0.023,BAYES_00=-2.599 
 autolearn=failed version=3.1.1
 
It seems that since upgrading to 3.11 last night, the
autolearn=yes|no|failed always shows up as failed (on all messages).
 
Did I miss something?
 
As well, the headers added by SA (and me [through SA] for MsgID) are now
showing at the top of the headers from the original message as opposed
to near (or at) the bottom (on all messages)..
 
The upgrade seemed to work fine (previous version was 3.02)..  all tests
came back good...  Spam tagging still works great.  The following
headers are from a mail from this list.

I used the InstallingOnWindows WIKI as a guide for the upgrade.

I am using SA 3.11 running on W2K/Exchange 2000 via a PerlScript tied
into Exchange's SMTP engine.

Steven
 

 
Microsoft Mail Internet Headers Version 2.0
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on 
 xxx.xxx.xxx
X-Spam-MsgId: 1142265031.319183
X-Spam-Level: 
X-Spam-Status: No, score=-0.1 required=5.0
tests=AWL=-1.200,BAYES_00=-2.599,
 RCVD_NUMERIC_HELO=1.5,STOCK_ALERT=2.2,UPPERCASE_25_50=0 autolearn=no 
 version=3.1.1
thread-index: AcZGtdsYoUOdErI8Rl6JuDuKQc06bA==
Received: from mail.apache.org ([209.237.227.199]) by
xxx.xx.xxx with Microsoft SMTPSVC(5.0.2195.6713); Mon, 13
Mar 2006 08:50:30 -0700
Received: (qmail 86421 invoked by uid 500); 13 Mar 2006 15:50:20 -
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
List-Help: 
List-Unsubscribe: 
List-Post: 
List-Id: 
Content-Class: urn:content-classes:message
Delivered-To: mailing list users@spamassassin.apache.org
Importance: normal
Priority: normal
Received: (qmail 86412 invoked by uid 99); 13 Mar 2006 15:50:20 -
Received: from xxx.xxx.org (HELO x.x.org)
(nnn.nnn.nnn.nn)by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Mar
2006 07:50:20 -0800
X-ASF-Spam-Status: No, hits=3.6
required=10.0tests=FORGED_HOTMAIL_RCVD2,RCVD_NUMERIC_HELO,SPF_HELO_PASS,
SPF_PASS,STOCK_ALERT,UPPERCASE_25_50
Received-SPF: pass (xx..org: domain of
[EMAIL PROTECTED] designates nn.nn.nnn.n as permitted sender)
Received: from [nn.nn.nnn.n] (HELO .x.org) (nn.nn.nnn.n)by
apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Mar 2006 07:50:18 -0800
Received: from list by x.xxx.org with local (Exim 4.43) id
1FIpHi-0007S0-07 for users@spamassassin.apache.org; Mon, 13 Mar 2006
16:48:40 +0100
Received: from 15.198.28.205 ([nn.nnn.nn.nnn])by main.gmane.org
with esmtp (Gmexim 0.1 (Debian))id 1AlnuQ-0007hv-00for
; Mon, 13 Mar 2006 16:48:37 +0100
Received: from  by nn.nnn.nnn.nnn with local (Gmexim 0.1
(Debian))id 1AlnuQ-0007hv-00for
; Mon, 13 Mar 2006 16:48:37 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: 
From: "x " <[EMAIL PROTECTED]>
Subject:  Re: encoded spam that got thru
Date:  Mon, 13 Mar 2006 16:47:23 +0100
Lines: 81
Message-ID: <[EMAIL PROTECTED]>
References:  <[EMAIL PROTECTED]>
X-Complaints-To: [EMAIL PROTECTED]
X-Gmane-NNTP-Posting-Host: 15.198.28.205
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2670
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
X-RFC2646: Format=Flowed; Original
Sender: "news" <[EMAIL PROTECTED]>
X-Virus-Checked: Checked by ClamAV on apache.org
Return-Path:
<[EMAIL PROTECTED]>
X-OriginalArrivalTime: 13 Mar 2006 15:50:30.0389 (UTC)
FILETIME=[DB004250:01C646B5]
 

 

RE: autolearn=failed ---- after upgrade to 3.11

[Steven Manross]

> > It seems that since upgrading to 3.11 last night, the 
> > autolearn=yes|no|failed always shows up as failed (on all messages).
> >  
> > Did I miss something?
> 
> Generally "Failed" means that SA somehow can't access the 
> bayes database to write to it.
> 
> Have you tried sa-learn --sync and then sa-learn --dump magic 
> to see if those tools find the bayes database correctly?
> 
I had run the --sync last night...

I just ran the --dump (no issues)

C:\Perl\bin>sa-learn --dump
0.000  0  3  0  non-token data: bayes db version
0.000  0  74899  0  non-token data: nspam
0.000  0  36273  0  non-token data: nham
0.000  0 122147  0  non-token data: ntokens
0.000  0 1140696522  0  non-token data: oldest atime
0.000  0 1142280376  0  non-token data: newest atime
0.000  0  0  0  non-token data: last journal
sync atime
0.000  0 1142162419  0  non-token data: last expiry
atime
0.000  01466085  0  non-token data: last expire
atime delta
0.000  0  31761  0  non-token data: last expire
reduction co
unt

> What about spamassassin --lint to check for config-file errors?
> 
Good suggestion..  I forgot to do that.

It found 2 lint issues:
use_razor 0
use_dcc 0 

Which I removed after remembering about those getting moved to plugins.

And I ran --lint again just for sanity sake -- without error.

It looks like the autolearn is working now.

Does anyone have any ideas on the "misplaced" headers?  Or is that a new
de facto standard?

Steven

RE: autolearn=failed ---- after upgrade to 3.11

[Steven Manross]

> -Original Message-
> From: Matt Kettler [mailto:[EMAIL PROTECTED] 
> Sent: Monday, March 13, 2006 1:35 PM
> To: Steven Manross
> Cc: users@spamassassin.apache.org
> Subject: Re: autolearn=failed  after upgrade to 3.11
> 
> Steven Manross wrote:
> 
> > It looks like the autolearn is working now.
> > 
> > Does anyone have any ideas on the "misplaced" headers?  Or 
> is that a 
> > new de facto standard?
> 
> You mean this:
> > As well, the headers added by SA (and me [through SA] for 
> MsgID) are 
> > now showing at the top of the headers from the original message as 
> > opposed to near (or at) the bottom (on all messages)..
> 
> That's a new standard. It is *required* to avoid breaking the 
> signature of any messages that are signed with domainkeys. 
> (ie: all of yahoo.com)

Correct..  Thank you..  I didn't know.  

I appreciate all the help.

> 
> 

Re: autolearn=failed ---- after upgrade to 3.11

[Matt Kettler]

Steven Manross wrote:

> It looks like the autolearn is working now.
> 
> Does anyone have any ideas on the "misplaced" headers?  Or is that a new
> de facto standard?

You mean this:
> As well, the headers added by SA (and me [through SA] for MsgID) are now
> showing at the top of the headers from the original message as opposed
> to near (or at) the bottom (on all messages)..

That's a new standard. It is *required* to avoid breaking the signature of any
messages that are signed with domainkeys. (ie: all of yahoo.com)

Re: autolearn=failed ---- after upgrade to 3.11

[Matt Kettler]

Steven Manross wrote:
> X-Spam-Status: No, score=-2.6 required=5.0
> tests=AWL=0.023,BAYES_00=-2.599 
>  autolearn=failed version=3.1.1
>  
> It seems that since upgrading to 3.11 last night, the
> autolearn=yes|no|failed always shows up as failed (on all messages).
>  
> Did I miss something?

Generally "Failed" means that SA somehow can't access the bayes database to
write to it.

Have you tried sa-learn --sync and then sa-learn --dump magic to see if those
tools find the bayes database correctly?

What about spamassassin --lint to check for config-file errors?

RE: autolearn=failed ---- after upgrade to 3.11

[Steven Manross]

> -Original Message-
> From: Steven Manross 
> Sent: Monday, March 13, 2006 12:46 PM
> To: users@spamassassin.apache.org
> Subject: autolearn=failed ---- after upgrade to 3.11
> 
> X-Spam-Status: No, score=-2.6 required=5.0
> tests=AWL=0.023,BAYES_00=-2.599
>  autolearn=failed version=3.1.1
>  
> It seems that since upgrading to 3.11 last night, the 
> autolearn=yes|no|failed always shows up as failed (on all messages).

Hmmm..  See below (but it's apparently not always)

>  
> Did I miss something?
>  
> As well, the headers added by SA (and me [through SA] for 
> MsgID) are now showing at the top of the headers from the 
> original message as opposed to near (or at) the bottom (on 
> all messages)..
>  
> The upgrade seemed to work fine (previous version was 3.02).. 
>  all tests came back good...  Spam tagging still works great. 
>  The following headers are from a mail from this list.
> 
> I used the InstallingOnWindows WIKI as a guide for the upgrade.
> 
> I am using SA 3.11 running on W2K/Exchange 2000 via a 
> PerlScript tied into Exchange's SMTP engine.
> 
> Steven
>  
> 
>  
> Microsoft Mail Internet Headers Version 2.0
> X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on  
> xxx.xxx.xxx
> X-Spam-MsgId: 1142265031.319183
> X-Spam-Level: 
> X-Spam-Status: No, score=-0.1 required=5.0 
> tests=AWL=-1.200,BAYES_00=-2.599,  
> RCVD_NUMERIC_HELO=1.5,STOCK_ALERT=2.2,UPPERCASE_25_50=0 autolearn=no
>  version=3.1.1

Ok...  Apparently it's not always...  LOL..  But until I doublechecked
these headers just now, every message that I was looking at had failed.

> thread-index: AcZGtdsYoUOdErI8Rl6JuDuKQc06bA==
> Received: from mail.apache.org ([209.237.227.199]) by 
> xxx.xx.xxx with Microsoft SMTPSVC(5.0.2195.6713); 

Re: trusted_networks seems to be ignored after upgrade

[Eric W. Bates]

Matt Kettler wrote:
...
>>
>>Is the whole trusted_net, dnsbl business written up somewhere?  I would
>>rather not waste your time; but searching the wiki doesn't turn anything up.
>>
>>
> 
> 
> 
> Not really, but I can go over it really fast..
> 
> 
> First, SA parses all the received headers, in backward order, starting with 
> the
> most recent. While doing so, it determines if each host is trusted or 
> untrusted,
> and internal or external (by default trusted_networks == internal_networks, so
> for you, the two are the same).
> 
> Let's make a "simple" example here, that somewhat reflects your situation. In
> this case "B" is taking the place of your 127.0.0.1.
> 
> trusted_networks A
> trusted_networks C
> 
> And a message:
> Received from B by A
> Received from C by B
> Received from D by C
> Received from E by D
> 
> In this case, SA would determine:
> A - trusted, internal
> B - untrusted, external
> C - untrusted, external, because it's "outside" of B.
> D - untrusted, external
> E - untrusted, external
> 
> 
> Now, when evaluating RBLs, the first thing SA does is eliminate all the 
> internal
> hosts from the list. Poof, A disappears from the list.
> 
> For all of the "dialup" type RBLs, SA excludes the first hop. Poof, E
> disappears. So SA will check B, C, and D against the various DUL RBLs.
> 
> In your case, C happens to be a dialup-node, so it matches against SORBS_DUL 
> and
> similar rules.
> 
> 
> Now, if you had:
> 
> trusted_networks A
> trusted_networks B
> trusted_networks C
> 
> Then SA would parse as:
> 
> A - trusted, internal
> B - trusted, internal
> C - trusted, internal (because there's no "break" in the path)
> D - untrusted, external
> E - untrusted, external
> 
> Now when evaluating the DUL RBLs, A,B and C will be dropped because they're
> internal, and E will be dropped because it's a first-hop. Only D gets checked.
> 
> As long as D isn't a dialup node, SORBS_DUL won't hit.
> 

Excellent description, thank you.  Clearly worthy of inclusion on the
wiki.  Adding 127/8 to the trusted list seems to be behaving as you
described.  All is well.

Re: trusted_networks seems to be ignored after upgrade

[Matt Kettler]

Eric W. Bates wrote:
> Eric W. Bates wrote:
>> Matt Kettler wrote:
>>
>> ...
>>
>>> No, it could fire on *ANY* external IP that isn't the first hop.
> I don't think I was clear.  I don't question that any IP in the chain
> might cause the difficuly.  I was questioning why, if 127.0.0.1 is the
> problem, why it was reported as 68.64.105.61 in the rule.

 Because 127.0.0.1 doesn't match the rule. However, the lack of trust in
 127.0.0.1 is causing 68.64.105.61 to be treated as external.

 RCVD_IN_SORBS_DUL can only match external hosts that are not the first hop.

>>
>> I appreciate your patience in helping me get this straight.
>>
>> It sounds as tho having amavis STOP adding the extra recieved header in
>> the message may address the problem?

Yeah that would work, but the right way would be to add 127.0.0.1 to the
trusted_networks.

Really, set trusted_networks to contain the IPs of all the mailservers that add
Received: headers you control. You can have multiple trusted_networks statements
to concat

>>
>>
> Also, adding 127.0.0.1 to trusted_network will, in fact, cause ALL
> inbound mail to be trusted, would it not?
> 
> Is the whole trusted_net, dnsbl business written up somewhere?  I would
> rather not waste your time; but searching the wiki doesn't turn anything up.
> 
> 


Not really, but I can go over it really fast..


First, SA parses all the received headers, in backward order, starting with the
most recent. While doing so, it determines if each host is trusted or untrusted,
and internal or external (by default trusted_networks == internal_networks, so
for you, the two are the same).

Let's make a "simple" example here, that somewhat reflects your situation. In
this case "B" is taking the place of your 127.0.0.1.

trusted_networks A
trusted_networks C

And a message:
Received from B by A
Received from C by B
Received from D by C
Received from E by D

In this case, SA would determine:
A - trusted, internal
B - untrusted, external
C - untrusted, external, because it's "outside" of B.
D - untrusted, external
E - untrusted, external


Now, when evaluating RBLs, the first thing SA does is eliminate all the internal
hosts from the list. Poof, A disappears from the list.

For all of the "dialup" type RBLs, SA excludes the first hop. Poof, E
disappears. So SA will check B, C, and D against the various DUL RBLs.

In your case, C happens to be a dialup-node, so it matches against SORBS_DUL and
similar rules.


Now, if you had:

trusted_networks A
trusted_networks B
trusted_networks C

Then SA would parse as:

A - trusted, internal
B - trusted, internal
C - trusted, internal (because there's no "break" in the path)
D - untrusted, external
E - untrusted, external

Now when evaluating the DUL RBLs, A,B and C will be dropped because they're
internal, and E will be dropped because it's a first-hop. Only D gets checked.

As long as D isn't a dialup node, SORBS_DUL won't hit.

Re: trusted_networks seems to be ignored after upgrade

[Eric W. Bates]

Eric W. Bates wrote:
> Matt Kettler wrote:
> 
> ...
> 
>>No, it could fire on *ANY* external IP that isn't the first hop.

I don't think I was clear.  I don't question that any IP in the chain
might cause the difficuly.  I was questioning why, if 127.0.0.1 is the
problem, why it was reported as 68.64.105.61 in the rule.
>>>
>>>
>>>Because 127.0.0.1 doesn't match the rule. However, the lack of trust in
>>>127.0.0.1 is causing 68.64.105.61 to be treated as external.
>>>
>>>RCVD_IN_SORBS_DUL can only match external hosts that are not the first hop.
>>>
> 
> 
> I appreciate your patience in helping me get this straight.
> 
> It sounds as tho having amavis STOP adding the extra recieved header in
> the message may address the problem?
> 
> 
Also, adding 127.0.0.1 to trusted_network will, in fact, cause ALL
inbound mail to be trusted, would it not?
>>>

Is the whole trusted_net, dnsbl business written up somewhere?  I would
rather not waste your time; but searching the wiki doesn't turn anything up.

Re: trusted_networks seems to be ignored after upgrade

[Matt Kettler]

Eric W. Bates wrote:
> 
> 
> Matt Kettler wrote:
>>> Eric W. Bates wrote:
>>>
 Matt Kettler wrote:

> Eric W. Bates wrote:
>
>
>> I recently upgraded from 2.63 to 3.1 and having done so, my entries for
>> trusted_networks no longer seem to functional.
>>
>> I have way to many trusted network lines, but in particular I know that:
>>
>> trusted_networks68.64/13
>>
>> is no longer working because:
>>
>> Content analysis details:   (5.9 points, 5.0 required)
>>
>> pts rule name  description
>>  --
>> --
>> -0.0 SPF_PASS   SPF: sender matches SPF record
>> 2.0 RCVD_IN_SORBS_DUL  RBL: SORBS: sent directly from dynamic IP
>> address
>>   [68.64.105.61 listed in dnsbl.sorbs.net]
>> 2.2 RCVD_IN_WHOIS_INVALID  RBL: CompleteWhois: sender on invalid IP block
>>   [68.64.105.61 listed in
>> combined-HIB.dnsiplists.completewhois.com]
>> 1.7 RCVD_IN_NJABL_DUL  RBL: NJABL: dialup sender did non-local SMTP
>>   [68.64.105.61 listed in combined.njabl.org]
>>
>>
>> As you know, 68.64.105.61 falls within 68.64.0.0/13; so none of these
>> rules should have hit, correct?
> Maybe.. Were there any untrusted hosts in-between 68.64.105.61 and your 
> network
> in the Received: headers?
 No.  But even if there were, wouldn't the rule fire on the offensive IP
 rather than the one listed as 'trusted'?
>>>
>>> No, it could fire on *ANY* external IP that isn't the first hop.
> 
> I don't think I was clear.  I don't question that any IP in the chain
> might cause the difficuly.  I was questioning why, if 127.0.0.1 is the
> problem, why it was reported as 68.64.105.61 in the rule.

Because 127.0.0.1 doesn't match the rule. However, the lack of trust in
127.0.0.1 is causing 68.64.105.61 to be treated as external.

RCVD_IN_SORBS_DUL can only match external hosts that are not the first hop.



> 
> Also, adding 127.0.0.1 to trusted_network will, in fact, cause ALL
> inbound mail to be trusted, would it not?
> 
> --
> Eric W. Bates
> [EMAIL PROTECTED]

Re: trusted_networks seems to be ignored after upgrade

[Matt Kettler]

Eric W. Bates wrote:
> Eric W. Bates wrote:
>>> Matt Kettler wrote:
>>>
 Eric W. Bates wrote:

> 
> ...


 Maybe.. Were there any untrusted hosts in-between 68.64.105.61 and your 
 network
 in the Received: headers?
>>>
>>> No.  But even if there were, wouldn't the rule fire on the offensive IP
>>> rather than the one listed as 'trusted'?
>>>
> 
> Well, I may have misspoken.  127.0.0.1 is in the path because I'm
> handing off from smtpd to amavis before returning back to smtpd again:

Well you better add 127.0.0.1 to your trusted networks then..

Re: trusted_networks seems to be ignored after upgrade

[Matt Kettler]

Eric W. Bates wrote:
> Matt Kettler wrote:
>> Eric W. Bates wrote:
>>
>>> I recently upgraded from 2.63 to 3.1 and having done so, my entries for
>>> trusted_networks no longer seem to functional.
>>>
>>> I have way to many trusted network lines, but in particular I know that:
>>>
>>> trusted_networks68.64/13
>>>
>>> is no longer working because:
>>>
>>> Content analysis details:   (5.9 points, 5.0 required)
>>>
>>> pts rule name  description
>>>  --
>>> --
>>> -0.0 SPF_PASS   SPF: sender matches SPF record
>>> 2.0 RCVD_IN_SORBS_DUL  RBL: SORBS: sent directly from dynamic IP
>>> address
>>>[68.64.105.61 listed in dnsbl.sorbs.net]
>>> 2.2 RCVD_IN_WHOIS_INVALID  RBL: CompleteWhois: sender on invalid IP block
>>>[68.64.105.61 listed in
>>> combined-HIB.dnsiplists.completewhois.com]
>>> 1.7 RCVD_IN_NJABL_DUL  RBL: NJABL: dialup sender did non-local SMTP
>>>[68.64.105.61 listed in combined.njabl.org]
>>>
>>>
>>> As you know, 68.64.105.61 falls within 68.64.0.0/13; so none of these
>>> rules should have hit, correct?
>>
>> Maybe.. Were there any untrusted hosts in-between 68.64.105.61 and your 
>> network
>> in the Received: headers?
> 
> No.  But even if there were, wouldn't the rule fire on the offensive IP
> rather than the one listed as 'trusted'?

No, it could fire on *ANY* external IP that isn't the first hop.

Re: trusted_networks seems to be ignored after upgrade

[Eric W. Bates]

Matt Kettler wrote:
> Eric W. Bates wrote:
> 
>>I recently upgraded from 2.63 to 3.1 and having done so, my entries for
>>trusted_networks no longer seem to functional.
>>
>>I have way to many trusted network lines, but in particular I know that:
>>
>>trusted_networks68.64/13
>>
>>is no longer working because:
>>
>>Content analysis details:   (5.9 points, 5.0 required)
>>
>> pts rule name  description
>> --
>>--
>>-0.0 SPF_PASS   SPF: sender matches SPF record
>> 2.0 RCVD_IN_SORBS_DUL  RBL: SORBS: sent directly from dynamic IP
>>address
>>[68.64.105.61 listed in dnsbl.sorbs.net]
>> 2.2 RCVD_IN_WHOIS_INVALID  RBL: CompleteWhois: sender on invalid IP block
>>[68.64.105.61 listed in
>>combined-HIB.dnsiplists.completewhois.com]
>> 1.7 RCVD_IN_NJABL_DUL  RBL: NJABL: dialup sender did non-local SMTP
>>[68.64.105.61 listed in combined.njabl.org]
>>
>>
>>As you know, 68.64.105.61 falls within 68.64.0.0/13; so none of these
>>rules should have hit, correct?
> 
> 
> Maybe.. Were there any untrusted hosts in-between 68.64.105.61 and your 
> network
> in the Received: headers?

No.  But even if there were, wouldn't the rule fire on the offensive IP
rather than the one listed as 'trusted'?

> Trust isn't just by IP.. it's a path. SA works backwards through the received:
> headers. Once it sees a host that isn't trusted, all the other received 
> headers
> can't be trusted or internal because that one untrusted host could have forged
> the extra Received: headers.
> 
> 

Re: trusted_networks seems to be ignored after upgrade

[Matt Kettler]

Eric W. Bates wrote:
> I recently upgraded from 2.63 to 3.1 and having done so, my entries for
> trusted_networks no longer seem to functional.
> 
> I have way to many trusted network lines, but in particular I know that:
> 
> trusted_networks68.64/13
> 
> is no longer working because:
> 
> Content analysis details:   (5.9 points, 5.0 required)
> 
>  pts rule name  description
>  --
> --
> -0.0 SPF_PASS   SPF: sender matches SPF record
>  2.0 RCVD_IN_SORBS_DUL  RBL: SORBS: sent directly from dynamic IP
> address
> [68.64.105.61 listed in dnsbl.sorbs.net]
>  2.2 RCVD_IN_WHOIS_INVALID  RBL: CompleteWhois: sender on invalid IP block
> [68.64.105.61 listed in
> combined-HIB.dnsiplists.completewhois.com]
>  1.7 RCVD_IN_NJABL_DUL  RBL: NJABL: dialup sender did non-local SMTP
> [68.64.105.61 listed in combined.njabl.org]
> 
> 
> As you know, 68.64.105.61 falls within 68.64.0.0/13; so none of these
> rules should have hit, correct?

Maybe.. Were there any untrusted hosts in-between 68.64.105.61 and your network
in the Received: headers?

Trust isn't just by IP.. it's a path. SA works backwards through the received:
headers. Once it sees a host that isn't trusted, all the other received headers
can't be trusted or internal because that one untrusted host could have forged
the extra Received: headers.

trusted_networks seems to be ignored after upgrade

[Eric W. Bates]

I recently upgraded from 2.63 to 3.1 and having done so, my entries for
trusted_networks no longer seem to functional.

I have way to many trusted network lines, but in particular I know that:

trusted_networks68.64/13

is no longer working because:

Content analysis details:   (5.9 points, 5.0 required)

 pts rule name  description
 --
--
-0.0 SPF_PASS   SPF: sender matches SPF record
 2.0 RCVD_IN_SORBS_DUL  RBL: SORBS: sent directly from dynamic IP
address
[68.64.105.61 listed in dnsbl.sorbs.net]
 2.2 RCVD_IN_WHOIS_INVALID  RBL: CompleteWhois: sender on invalid IP block
[68.64.105.61 listed in
combined-HIB.dnsiplists.completewhois.com]
 1.7 RCVD_IN_NJABL_DUL  RBL: NJABL: dialup sender did non-local SMTP
[68.64.105.61 listed in combined.njabl.org]


As you know, 68.64.105.61 falls within 68.64.0.0/13; so none of these
rules should have hit, correct?

Thanks for your time.

--
Eric W. Bates

Re: SQL not working after upgrade 3.0.4 -> 3.1.0

[Michael Monnerie]

On Mittwoch, 26. Oktober 2005 12:50 Thomas Booms wrote:
> [28039] warn: lint: 5 issues detected, please rerun with debug
> enabled for more information

Fix your config file, and do what above message suggests.

mfg zmi
-- 
// Michael Monnerie, Ing.BSc  ---   it-management Michael Monnerie
// http://zmi.at   Tel: 0660/4156531  Linux 2.6.11
// PGP Key:   "lynx -source http://zmi.at/zmi2.asc | gpg --import"
// Fingerprint: EB93 ED8A 1DCD BB6C F952  F7F4 3911 B933 7054 5879
// Keyserver: www.keyserver.net Key-ID: 0x70545879


pgp1xhOEE7VlX.pgp
Description: PGP signature

SQL not working after upgrade 3.0.4 -> 3.1.0

[Thomas Booms]

Hello all,

I've upgrade SA 3.0.4 to 3.1.0 a few weeks ago and saw after a while, 
that the db settings in mysql seem to be ignored. Making system wide 
settings in local.cf are working.


Here my debug output from 3.1.0:

spamassassin -D --lint
[28039] dbg: logger: adding facilities: all
[28039] dbg: logger: logging level is DBG
[28039] dbg: generic: SpamAssassin version 3.1.0
[28039] dbg: config: score set 0 chosen.
[28039] dbg: util: running in taint mode? yes
[28039] dbg: util: taint mode: deleting unsafe environment variables, 
resetting PATH

[28039] dbg: util: PATH included '/sbin', keeping
[28039] dbg: util: PATH included '/usr/sbin', keeping
[28039] dbg: util: PATH included '/usr/local/sbin', keeping
[28039] dbg: util: PATH included '/root/bin', keeping
[28039] dbg: util: PATH included '/usr/local/bin', keeping
[28039] dbg: util: PATH included '/usr/local/news/bin', keeping
[28039] dbg: util: PATH included '/usr/bin', keeping
[28039] dbg: util: PATH included '/usr/X11R6/bin', keeping
[28039] dbg: util: PATH included '/bin', keeping
[28039] dbg: util: PATH included '/var/qmail/bin', keeping
[28039] dbg: util: PATH included '/usr/local/bin/ezmlm', keeping
[28039] dbg: util: PATH included '/usr/local/sbin', keeping
[28039] dbg: util: PATH included '/usr/games', keeping
[28039] dbg: util: PATH included '/opt/gnome/bin', keeping
[28039] dbg: util: PATH included '/opt/kde3/bin', keeping
[28039] dbg: util: PATH included '/usr/lib/java/jre/bin', keeping
[28039] dbg: util: final PATH set to: 
/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/local/news/bin:/usr/bin:/usr/X11R6/bin:/bin:/var/qmail/bin:/usr/local/bin/ezmlm:/usr/local/sbin:/usr/games:/opt/gnome/bin:/opt/kde3/bin:/usr/lib/java/jre/bin

[28039] dbg: dns: is Net::DNS::Resolver available? yes
[28039] dbg: dns: Net::DNS version: 0.52
[28039] dbg: dns: name server: 192.168.1.50, family: 2, ipv6: 0
[28039] dbg: diag: perl platform: 5.008007 linux
[28039] dbg: diag: module installed: Digest::SHA1, version 2.10
[28039] dbg: diag: module installed: MIME::Base64, version 3.05
[28039] dbg: diag: module installed: HTML::Parser, version 3.45
[28039] dbg: diag: module installed: DB_File, version 1.811
[28039] dbg: diag: module installed: Net::DNS, version 0.52
[28039] dbg: diag: module installed: Net::SMTP, version 2.29
[28039] dbg: diag: module installed: Mail::SPF::Query, version 1.997
[28039] dbg: diag: module installed: IP::Country::Fast, version 309.002
[28039] dbg: diag: module installed: Razor2::Client::Agent, version 2.72
[28039] dbg: diag: module not installed: Net::Ident ('require' failed)
[28039] dbg: diag: module not installed: IO::Socket::INET6 ('require' 
failed)

[28039] dbg: diag: module installed: IO::Socket::SSL, version 0.96
[28039] dbg: diag: module installed: Time::HiRes, version 1.68
[28039] dbg: diag: module installed: DBI, version 1.48
[28039] dbg: diag: module installed: Getopt::Long, version 2.34
[28039] dbg: diag: module not installed: LWP::UserAgent ('require' failed)
[28039] dbg: diag: module not installed: HTTP::Date ('require' failed)
[28039] dbg: diag: module not installed: Archive::Tar ('require' failed)
[28039] dbg: diag: module not installed: IO::Zlib ('require' failed)
[28039] dbg: ignore: using a test message to lint rules
[28039] dbg: config: using "/etc/mail/spamassassin" for site rules pre files
[28039] dbg: config: read file /etc/mail/spamassassin/init.pre
[28039] dbg: config: read file /etc/mail/spamassassin/v310.pre
[28039] dbg: config: using "/usr/local/share/spamassassin" for sys rules 
pre files
[28039] dbg: config: using "/usr/local/share/spamassassin" for default 
rules dir

[28039] dbg: config: read file /usr/local/share/spamassassin/10_misc.cf
[28039] dbg: config: read file 
/usr/local/share/spamassassin/20_advance_fee.cf
[28039] dbg: config: read file 
/usr/local/share/spamassassin/20_anti_ratware.cf
[28039] dbg: config: read file 
/usr/local/share/spamassassin/20_body_tests.cf
[28039] dbg: config: read file 
/usr/local/share/spamassassin/20_compensate.cf
[28039] dbg: config: read file 
/usr/local/share/spamassassin/20_dnsbl_tests.cf

[28039] dbg: config: read file /usr/local/share/spamassassin/20_drugs.cf
[28039] dbg: config: read file 
/usr/local/share/spamassassin/20_fake_helo_tests.cf
[28039] dbg: config: read file 
/usr/local/share/spamassassin/20_head_tests.cf
[28039] dbg: config: read file 
/usr/local/share/spamassassin/20_html_tests.cf
[28039] dbg: config: read file 
/usr/local/share/spamassassin/20_meta_tests.cf

[28039] dbg: config: read file /usr/local/share/spamassassin/20_net_tests.cf
[28039] dbg: config: read file /usr/local/share/spamassassin/20_phrases.cf
[28039] dbg: config: read file /usr/local/share/spamassassin/20_porn.cf
[28039] dbg: config: read file /usr/local/share/spamassassin/20_ratware.cf
[28039] dbg: config: read file /usr/local/share/spamassassin/20_uri_tests.cf
[28039] dbg: config: read file /usr/local/share/spamassassin/23_bayes.cf
[28039] dbg: config: read file /u

Re: spamassassin less effective after upgrade to 3.1.0: some checks no longer executed ?

[Justin Mason]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


[EMAIL PROTECTED] writes:
> Hi,
> 
> problem is solved.
> 
> i noticed via solaris' truss tool that mimedefang.pl didn't read 
> /usr/perl5/5.6.1/etc/mail/spamassassin. And this is the directory that 
> contained the v310.pre script which by default disables dcc, pyzor and 
> razor2 (by commenting the loadplugin keyword).
> 
> I made /etc/mail/spamassassin a link to above mentioned directory, and now 
> everything is fine and dandy.

Interesting -- that's not the default, by any means.  

> Took me 3 hours of debugging though...

this is why std "spamassassin" lists all those paths out at startup, when
run with --debug.  perhaps something mimedefang should do also ;)

- --j.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFDUU3nMJF5cimLx9ARAmTUAJ9HMr4gVRqmQnyudHLHJ1/jFj2tSwCghJCV
zdHU/ZRHbxhS8ewNFxLr4PE=
=+Rjv
-END PGP SIGNATURE-

Re: spamassassin less effective after upgrade to 3.1.0: some checks no longer executed ?

[tomvo]

Hi,


problem is solved.

i noticed via solaris' truss tool that
mimedefang.pl didn't read /usr/perl5/5.6.1/etc/mail/spamassassin. And this
is the directory that contained the v310.pre script which by default disables
dcc, pyzor and razor2 (by commenting the loadplugin keyword).

I made /etc/mail/spamassassin a link
to above mentioned directory, and now everything is fine and dandy.

Took me 3 hours of debugging though...

kind regards to all for the help,

gr,
tom.


---
Tom Van Overbeke - ABSI Unix System Engineer
email: [EMAIL PROTECTED]
Tel: +32 2 333 40 00 - Fax: +32 2 332 34 69
website: http://www.absi.be
---







"Menno van Bennekom" <[EMAIL PROTECTED]>
14/10/2005 13:56
Please respond to mvbengro
        
        To:
       [EMAIL PROTECTED]
        cc:
       "Alan Premselaar" <[EMAIL PROTECTED]>,
users@spamassassin.apache.org
        Subject:
       Re: spamassassin less effective after
upgrade to 3.1.0: some              
               
      checks no longer executed ?


> Tom,
>
>   you may want to cross-post this to the mimedefang list.  it's
likely
> someone there may also be able to help you.
>
> I also run mimedefang but I haven't experienced these types of problems.
> you may want to log in as the defang user and check the path and see
if
> there are any suspect entries in your path.
>
> also, if you don't have a recent version of razor installed, I know
> there were issues with older versions running in taint mode so maybe
> it's related to that.
>
> what does your mimedefang-filter file look like?  have you checked
the
> Changelog and all the required COMPATIBILITY warnings when upgrading
> mimedefang?
>
> HTH
>
> alan
>
Indeed it looks like a mimedefang problem, I have no experience with that
because I use postfix+amavisd.
So your spamassassin --lint -D as mimedefang user now suggests that
Razor/DCC are working. To be absolutely sure you could check a message
(preferably a spam that has a hit in DCC/Razor) with 'cat  |
spamassassin -D'. If you see the normal DCC/Razor actions then
SA/Razor/DCC should be fine.
You could also double-check the permissions of the Razor/DCC dirs, after
upgrades I often have to change dirs+files like /var/dcc and ~/.razor to
the right permissions for the SA-user.

Regards
Menno

Re: spamassassin less effective after upgrade to 3.1.0: some checks no longer executed ?

[Menno van Bennekom]

> Tom,
>
>   you may want to cross-post this to the mimedefang list.  it's likely
> someone there may also be able to help you.
>
> I also run mimedefang but I haven't experienced these types of problems.
> you may want to log in as the defang user and check the path and see if
> there are any suspect entries in your path.
>
> also, if you don't have a recent version of razor installed, I know
> there were issues with older versions running in taint mode so maybe
> it's related to that.
>
> what does your mimedefang-filter file look like?  have you checked the
> Changelog and all the required COMPATIBILITY warnings when upgrading
> mimedefang?
>
> HTH
>
> alan
>
Indeed it looks like a mimedefang problem, I have no experience with that
because I use postfix+amavisd.
So your spamassassin --lint -D as mimedefang user now suggests that
Razor/DCC are working. To be absolutely sure you could check a message
(preferably a spam that has a hit in DCC/Razor) with 'cat  |
spamassassin -D'. If you see the normal DCC/Razor actions then
SA/Razor/DCC should be fine.
You could also double-check the permissions of the Razor/DCC dirs, after
upgrades I often have to change dirs+files like /var/dcc and ~/.razor to
the right permissions for the SA-user.

Regards
Menno

Re: spamassassin less effective after upgrade to 3.1.0: some checks no longer executed ?

[Alan Premselaar]

[EMAIL PROTECTED] wrote:


Hi,

I mentioned earlier that i thought i had found the problem (as user 
defang /usr/local/bin was not found in the path). Now, i'm not so sure 
anymore that this is the real problem. i noticed in the --lint output 
this line:

[419] dbg: util: running in taint mode? yes
[419] dbg: util: taint mode: deleting unsafe environment variables, 
resetting PATH


I assume this is because it's running with --lint, i don't know. anyway, 
i created links to /usr/bin, and now spamassassin --lint -D running as 
user defang does all the checks that it should do. But when i restart 
mimedefang (I even rebooted the server just to be sure !), still no 
mention of razor, dcc or pyzor


Fact of the matter is that we call spamassassin via mimedefang, that is 
via perl. Now I don't know much about the internals of how mimedefang 
invokes spamassassin, but i do know that it's not the  same as running 
the spamassassin executable.


What I would need, is a way to debug spamassassin when it's called via 
mimedefang, so that I know why it would skip certain checks.
Currently, I don't know how to do that. My perl skills are not adequate 
enough to figure this one out.


Please help me.

thx,
tom.


Tom,

 you may want to cross-post this to the mimedefang list.  it's likely 
someone there may also be able to help you.


I also run mimedefang but I haven't experienced these types of problems.
you may want to log in as the defang user and check the path and see if 
there are any suspect entries in your path.


also, if you don't have a recent version of razor installed, I know 
there were issues with older versions running in taint mode so maybe 
it's related to that.


what does your mimedefang-filter file look like?  have you checked the 
Changelog and all the required COMPATIBILITY warnings when upgrading 
mimedefang?


HTH

alan

Re: spamassassin less effective after upgrade to 3.1.0: some checks no longer executed ?

[tomvo]

Hi,

I mentioned earlier that i thought i
had found the problem (as user defang /usr/local/bin was not found in the
path). Now, i'm not so sure anymore that this is the real problem. i noticed
in the --lint output this line:
[419] dbg: util: running in taint mode? yes
[419] dbg: util: taint mode: deleting unsafe environment variables, resetting
PATH

I assume this is because it's running
with --lint, i don't know. anyway, i created links to /usr/bin, and now
spamassassin --lint -D running as user defang does all the checks that
it should do. But when i restart mimedefang (I even rebooted the server
just to be sure !), still no mention of razor, dcc or pyzor

Fact of the matter is that we call spamassassin
via mimedefang, that is via perl. Now I don't know much about the internals
of how mimedefang invokes spamassassin, but i do know that it's not the
 same as running the spamassassin executable.

What I would need, is a way to debug
spamassassin when it's called via mimedefang, so that I know why it would
skip certain checks.
Currently, I don't know how to do that.
My perl skills are not adequate enough to figure this one out.

Please help me.

thx,
tom.



---
Tom Van Overbeke - ABSI Unix System Engineer
email: [EMAIL PROTECTED]
Tel: +32 2 333 40 00 - Fax: +32 2 332 34 69
website: http://www.absi.be
---







"Menno van Bennekom" <[EMAIL PROTECTED]>
13/10/2005 15:29
Please respond to mvbengro
        
        To:
       [EMAIL PROTECTED]
        cc:
       users@spamassassin.apache.org
        Subject:
       Re: spamassassin less effective after
upgrade to 3.1.0: some              
          checks no longer executed
?


Only difference with my 'spamassassin --lint -D' output
I saw was that
after the line 'uridnsbl: domains to query' I have a block of 14 lines
with 'dns: checking RBL sbl-xbl.etcetera' that you don't have. Probably
not important. And I can't see your SARE-rules getting loaded, in my
output I see SARE being loaded after the line 'config: using "/"
for
site rules dir'. The v310.pre and init.pre are the same as mine.

Maybe (like already suggested) the user that starts spamassassin could
be
checked for having a user_prefs file, or for having permission troubles.
Also with 'cat mail | spamassassin -D' you should be able to see if that
specific mail is checked against DCC and Razor. Again, best to check that
is with the same user that executes spamassassin.
You could also sniff on ports tcp/2703 (razor) and udp/6277 (dcc).

Regards
Menno

Re: spamassassin less effective after upgrade to 3.1.0: some checks no longer executed ?

[tomvo]

Hi,

I think i've found it. i followed your
suggestion to run spamassassin as the user it normally runs as (user defang),
and when i run with --lint, defang can't find the executables anymore.
they reside in /usr/local/bin, and that's not in defang's path.

Something has definitely changed here.


I made links for dccproc, razor-check
and pyzor  to /usr/bin and reran --lint with user defang. seems to
work fine.
then restarted mimedefang and sendmail,
but no joy yet...

does this tale sound familiar to anyone
?

I compiled all these progs myself, usually
with standard settings, except sometimes specifying it should run as user
defang where appropriate.

tom.

---
Tom Van Overbeke - ABSI Unix System Engineer
email: [EMAIL PROTECTED]
Tel: +32 2 333 40 00 - Fax: +32 2 332 34 69
website: http://www.absi.be
---







"Menno van Bennekom" <[EMAIL PROTECTED]>
13/10/2005 15:29
Please respond to mvbengro
        
        To:
       [EMAIL PROTECTED]
        cc:
       users@spamassassin.apache.org
        Subject:
       Re: spamassassin less effective after
upgrade to 3.1.0: some              
          checks no longer executed
?


Only difference with my 'spamassassin --lint -D' output
I saw was that
after the line 'uridnsbl: domains to query' I have a block of 14 lines
with 'dns: checking RBL sbl-xbl.etcetera' that you don't have. Probably
not important. And I can't see your SARE-rules getting loaded, in my
output I see SARE being loaded after the line 'config: using "/"
for
site rules dir'. The v310.pre and init.pre are the same as mine.

Maybe (like already suggested) the user that starts spamassassin could
be
checked for having a user_prefs file, or for having permission troubles.
Also with 'cat mail | spamassassin -D' you should be able to see if that
specific mail is checked against DCC and Razor. Again, best to check that
is with the same user that executes spamassassin.
You could also sniff on ports tcp/2703 (razor) and udp/6277 (dcc).

Regards
Menno

Re: spamassassin less effective after upgrade to 3.1.0: some checks no longer executed ?

[Menno van Bennekom]

Only difference with my 'spamassassin --lint -D' output I saw was that
after the line 'uridnsbl: domains to query' I have a block of 14 lines
with 'dns: checking RBL sbl-xbl.etcetera' that you don't have. Probably
not important. And I can't see your SARE-rules getting loaded, in my
output I see SARE being loaded after the line 'config: using "/" for
site rules dir'. The v310.pre and init.pre are the same as mine.

Maybe (like already suggested) the user that starts spamassassin could be
checked for having a user_prefs file, or for having permission troubles.
Also with 'cat mail | spamassassin -D' you should be able to see if that
specific mail is checked against DCC and Razor. Again, best to check that
is with the same user that executes spamassassin.
You could also sniff on ports tcp/2703 (razor) and udp/6277 (dcc).

Regards
Menno

Re: spamassassin less effective after upgrade to 3.1.0: some checks no longer executed ?

[Justin Mason]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


[EMAIL PROTECTED] writes:
> Hi,
> 
> in directory (/usr/perl5/5.6.1/etc/mail/spamassassin) , i have these 
> files:
> 
> init.pre local.cf local.cf.040605  v310.pre
> 
> contents (for brevity, i'll only put the uncommented lines):
> 
> bash-2.05# grep -v ^# init.pre
> 
> 
> loadplugin Mail::SpamAssassin::Plugin::URIDNSBL
> loadplugin Mail::SpamAssassin::Plugin::Hashcash
> loadplugin Mail::SpamAssassin::Plugin::SPF
> 
> 
> bash-2.05# grep -v ^# local.cf
> 
> required_hits   5
> ok_languagesnl en fr
> ok_locales  en
> skip_rbl_checks 0
> use_bayes 1
> bayes_auto_learn 1
> bayes_path /var/spool/MIMEDefang-bayes/bayes
> bayes_file_mode 0666
> bayes_auto_expire 1
> bayes_expiry_max_db_size 10
> bayes_learn_to_journal 1
> bayes_min_ham_num 100
> bayes_min_spam_num 100
> lock_method flock
> use_razor2  1
> use_dcc 1
> use_pyzor   1
> use_bayes   1
> 
> 
> bash-2.05# grep -v ^# v310.pre
> 
> loadplugin Mail::SpamAssassin::Plugin::DCC
> loadplugin Mail::SpamAssassin::Plugin::Pyzor
> loadplugin Mail::SpamAssassin::Plugin::Razor2
> loadplugin Mail::SpamAssassin::Plugin::SpamCop
> loadplugin Mail::SpamAssassin::Plugin::AWL
> loadplugin Mail::SpamAssassin::Plugin::AutoLearnThreshold
> loadplugin Mail::SpamAssassin::Plugin::WhiteListSubject
> loadplugin Mail::SpamAssassin::Plugin::MIMEHeader
> loadplugin Mail::SpamAssassin::Plugin::ReplaceTags
> 
> my rules are in directory /usr/perl5/5.6.1/share/spamassassin
> 
> As you can see, plugins are not commented and are enabled (use_dcc etc.)
> 
> The only check that i can see that currently works is bayes. 
> and spamassassin --lint -D says clearly that it can load the plugins, and 
> the required rules files to use pyzor, razor and dcc are also there.
> 
> So I am stumped. apparently spamassassin --lint -D is misleading me 
> here
> 
> i'd be grateful for all possible clues to resolve this issue.
> 
> For example, is there a way to see if a mail actually passes the let's say 
> DCC check (25_dcc.cf) ?

enable SpamAssassin debugs in amavisd.   BTW if "spamassassin --lint -D"
works, that often means that it's a difference in user configuration
in $HOME , between the user you run "spamassassin --lint -D" with, and
the user amavisd scans mail as.

> Perhaps the way dcc is invoked causes some kind of error that goes 
> unnoticed ? but as razor and pyzor also don't work, this is not very 
> likely...

- --j.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFDTXizMJF5cimLx9ARAnrXAKCw2j92jxbcnLeOa7Lbp205zB7DPgCgn7x7
55Fp3LxILPG4gnyqr7pznQs=
=pRiA
-END PGP SIGNATURE-

Re: spamassassin less effective after upgrade to 3.1.0: some checks no longer executed ?

[tomvo]

Hi,

in directory (/usr/perl5/5.6.1/etc/mail/spamassassin)
, i have these files:

init.pre        
local.cf         local.cf.040605  v310.pre

contents (for brevity, i'll only put
the uncommented lines):

bash-2.05# grep -v ^# init.pre


loadplugin Mail::SpamAssassin::Plugin::URIDNSBL
loadplugin Mail::SpamAssassin::Plugin::Hashcash
loadplugin Mail::SpamAssassin::Plugin::SPF


bash-2.05# grep -v ^# local.cf

required_hits        
  5
ok_languages        
   nl en fr
ok_locales        
     en
skip_rbl_checks 0
use_bayes 1
bayes_auto_learn 1
bayes_path /var/spool/MIMEDefang-bayes/bayes
bayes_file_mode 0666
bayes_auto_expire 1
bayes_expiry_max_db_size 10
bayes_learn_to_journal 1
bayes_min_ham_num 100
bayes_min_spam_num 100
lock_method     flock
use_razor2        
     1
use_dcc        
        1
use_pyzor        
      1
use_bayes        
      1


bash-2.05# grep -v ^# v310.pre

loadplugin Mail::SpamAssassin::Plugin::DCC
loadplugin Mail::SpamAssassin::Plugin::Pyzor
loadplugin Mail::SpamAssassin::Plugin::Razor2
loadplugin Mail::SpamAssassin::Plugin::SpamCop
loadplugin Mail::SpamAssassin::Plugin::AWL
loadplugin Mail::SpamAssassin::Plugin::AutoLearnThreshold
loadplugin Mail::SpamAssassin::Plugin::WhiteListSubject
loadplugin Mail::SpamAssassin::Plugin::MIMEHeader
loadplugin Mail::SpamAssassin::Plugin::ReplaceTags

my rules are in directory /usr/perl5/5.6.1/share/spamassassin

As you can see, plugins are not commented
and are enabled (use_dcc etc.)

The only check that i can see that currently
works is bayes. 
and spamassassin --lint -D says clearly
that it can load the plugins, and the required rules files to use pyzor,
razor and dcc are also there.

So I am stumped. apparently spamassassin
--lint -D is misleading me here


i'd be grateful for all possible clues
to resolve this issue.

For example, is there a way to see if
a mail actually passes the let's say DCC check (25_dcc.cf) ?

Perhaps the way dcc is invoked causes
some kind of error that goes unnoticed ? but as razor and pyzor also don't
work, this is not very likely...




---
Tom Van Overbeke - ABSI Unix System Engineer
email: [EMAIL PROTECTED]
Tel: +32 2 333 40 00 - Fax: +32 2 332 34 69
website: http://www.absi.be
---







"Menno van Bennekom" <[EMAIL PROTECTED]>
12/10/2005 16:05
Please respond to mvbengro
        
        To:
       [EMAIL PROTECTED]
        cc:
       users@spamassassin.apache.org
        Subject:
       Re: spamassassin less effective after
upgrade to 3.1.0: some             checks
no longer executed ?


I see that the site rules dir is "/usr/perl5/5.6.1/etc/mail/spamassassin"
according to the debug output, maybe you should check that your local.cf
v310.pre and sare-rules exist in that directory.

Regards
Menno van Bennekom

> Hi,
>
> I recently upgraded our mail relay software:
>
> (sendmail is 8.13.3, but I didn't upgrade this)
>
> mimedefang from 2.51 to 2.53
> razor2 from 2.67 to 2.77
> dcc from 1.2.71 to 1.3.18
> spamassassin from 3.0.2 to 3.1.0
>
> we executed spamassassin via mimedefang's mimedefang-filter file (and
> accompanying sa-mimedefang.cf file, neither of these files were modified
> during the upgrade), these are the lines that invoke spamassassin:
>
>     # Spam checks if SpamAssassin is installed
>     if ($Features{"SpamAssassin"}) {
>         if (-s "./INPUTMSG" < 100*1024)
{
>             # Only scan messages smaller
than 100kB.  Larger messages
>             # are extremely unlikely
to be spam, and SpamAssassin is
>             # dreadfully slow on very
large messages.
>             my($hits, $req, $names,
$report) = spam_assassin_check();
>             my($score);
>             if ($hits < 40) {
>                 $score = "*"
x int($hits);
>             } else {
>                 $score = "*"
x 40;
>
>
> the initial upgrade went fine, but recently, customers start to complain
> that they receive more spam than before.
> When I checked the logfiles, i noticed that ***before the upgrade***,
i
> had lots of lines with
>
> BAYES_99,DCC_CHECK,DIGEST_MULTIPLE,FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_40_50,HTML_MESSAGE,MIME_HTML_ONLY,MSGID_OUTLOOK_INVALID,NO_DNS_FOR_FROM,NO_REAL_NAME,RAZOR2_CF_RANGE_51_100,RAZOR2_CHECK,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL,RCVD_IN_XBL,SARE_OEM_PRODS_1,SARE_OEM_PRODS_2,SARE_OEM_PRODS_3,SARE_OEM_PRODS_FEW,SARE_OEM_SOFT_IS,SARE_PRODS_LOTS,SARE_PRODUCTS_02,SARE_PRODUCTS_03,SARE_PRODUCTS_04
>
>
>
> now, ***after the upgrade*** these are the sort of checks i see on
mails
> marked as spam:
> BAYES_99,DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_HOTMAIL_RCVD2,HTML_MESSAGE,HTML_MIME_NO_HTML_

Re: spamassassin less effective after upgrade to 3.1.0: some checks no longer executed ?

[Justin Mason]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


[EMAIL PROTECTED] writes:
> Hi Jim,
> 
> I suppose you're not referring to the fact that razor2 and dcc is 
> commented by default ? because i wrote in mail that i did uncomment them.

Tom --

doh!   my mistake.  Sorry about that.

I don't think anything significant changed between 3.0.x and 3.1.0
regarding how Razor and DCC are run, apart from their move to plugins.
I would enable debugging in amavisd, and see what gets output by
the Razor/DCC plugins when a message is scanned there...

- --j.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFDTVg0MJF5cimLx9ARArkqAKCpbDKmkelCFiGimPxrX6dJ02TxAwCgmhaL
KC/opXf+zGPzeH5+CL5FnRA=
=dluS
-END PGP SIGNATURE-

Re: spamassassin less effective after upgrade to 3.1.0: some checks no longer executed ?

[tomvo]

Hi Jim,

I suppose you're not referring to the
fact that razor2 and dcc is commented by default ? because i wrote in mail
that i did uncomment them.


gr,
tom
---
Tom Van Overbeke - ABSI Unix System Engineer
email: [EMAIL PROTECTED]
Tel: +32 2 333 40 00 - Fax: +32 2 332 34 69
website: http://www.absi.be
---







[EMAIL PROTECTED] (Justin Mason)
Sent by: [EMAIL PROTECTED]
12/10/2005 18:52
        
        To:
       [EMAIL PROTECTED]
        cc:
       users@spamassassin.apache.org
        Subject:
       Re: spamassassin less effective after
upgrade to 3.1.0: some checks         no longer
executed ?


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


A tip: when the documentation says you need to read the "UPGRADE"
document, you really *do* need to read that document ;)

First item in

  http://spamassassin.apache.org/dist/UPGRADE

will tell you what you need to know.

- --j.

[EMAIL PROTECTED] writes:
> Hi,
> 
> I recently upgraded our mail relay software:
> 
> (sendmail is 8.13.3, but I didn't upgrade this)
> 
> mimedefang from 2.51 to 2.53
> razor2 from 2.67 to 2.77
> dcc from 1.2.71 to 1.3.18
> spamassassin from 3.0.2 to 3.1.0
> 
> we executed spamassassin via mimedefang's mimedefang-filter file (and

> accompanying sa-mimedefang.cf file, neither of these files were modified

> during the upgrade), these are the lines that invoke spamassassin:
> 
>     # Spam checks if SpamAssassin is installed
>     if ($Features{"SpamAssassin"}) {
>         if (-s "./INPUTMSG" < 100*1024)
{
>             # Only scan messages smaller
than 100kB.  Larger messages
>             # are extremely unlikely
to be spam, and SpamAssassin is
>             # dreadfully slow on very
large messages.
>             my($hits, $req, $names,
$report) = spam_assassin_check();
>             my($score);
>             if ($hits < 40) {
>                 $score = "*"
x int($hits);
>             } else {
>                 $score = "*"
x 40;
> 
> 
> the initial upgrade went fine, but recently, customers start to complain

> that they receive more spam than before.
> When I checked the logfiles, i noticed that ***before the upgrade***,
i 
> had lots of lines with 
> 
> BAYES_99,DCC_CHECK,DIGEST_MULTIPLE,FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_40_50,HTML_MESSAGE,MIME_HTML_ONLY,MSGID_OUTLOOK_INVALID,NO_DNS_FOR_FROM,NO_REAL_NAME,RAZOR2_CF_RANGE_51_100,RAZOR2_CHECK,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL,RCVD_IN_XBL,SARE_OEM_PRODS_1,SARE_OEM_PRODS_2,SARE_OEM_PRODS_3,SARE_OEM_PRODS_FEW,SARE_OEM_SOFT_IS,SARE_PRODS_LOTS,SARE_PRODUCTS_02,SARE_PRODUCTS_03,SARE_PRODUCTS_04
> 
> 
> 
> now, ***after the upgrade*** these are the sort of checks i see on
mails 
> marked as spam:
> BAYES_99,DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_HOTMAIL_RCVD2,HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,INFO_TLD,MIME_HEADER_CTYPE_ONLY,MIME_HTML_ONLY,MSGID_FROM_MTA_ID,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DSBL,RCVD_IN_NJABL_PROXY,RCVD_IN_SORBS_DUL,RCVD_IN_SORBS_SOCKS
> 
> now, as far as i can tell, these checks are defined in the SARE rules
in 
> my directory /usr/perl5/5.6.1/share/spamassassin, so at least I assume

> spamassassin is being started by mimedefang
> 
> But I don't see any DCC_CHECK , or RAZOR2 line anymore in my logs,
even 
> thoug it is enabled (I now the lines in v310.pre are commented. In
general 
> i see for the mails marked as spam at lot less checks.
> 
> I didn't alter the rules in /usr/perl/5.6.1/share/spamassassin (I
didn't 
> read anywhere that I needed to upgrade them for 3.1.0)
> 
> spamassassin --lint -D returns this (also indicating that everything

> should be fine and that network checks are enabled):
> 
> 
> [419] dbg: logger: adding facilities: all
> [419] dbg: logger: logging level is DBG
> [419] dbg: generic: SpamAssassin version 3.1.0
> [419] dbg: config: score set 0 chosen.
> [419] dbg: util: running in taint mode? yes
> [419] dbg: util: taint mode: deleting unsafe environment variables,

> resetting PATH
> [419] dbg: util: PATH included '/usr/sbin', keeping
> [419] dbg: util: PATH included '/usr/bin', keeping
> [419] dbg: util: PATH included '/usr/sbin', keeping
> [419] dbg: util: PATH included '/usr/ccs/bin', keeping
> [419] dbg: util: PATH included '/opt/sfw/bin', keeping
> [419] dbg: util: PATH included '/usr/local/bin', keeping
> [419] dbg: util: PATH included '/usr/perl5/5.6.1/bin', keeping
> [419] dbg: util: final PATH set to: 
> /usr/sbin:/usr/bin:/usr/sbin:/usr/ccs/bin:/opt/sfw/bin:/usr/local/bin:/usr/perl

Re: spamassassin less effective after upgrade to 3.1.0: some checks no longer executed ?

[Justin Mason]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


A tip: when the documentation says you need to read the "UPGRADE"
document, you really *do* need to read that document ;)

First item in

  http://spamassassin.apache.org/dist/UPGRADE

will tell you what you need to know.

- --j.

[EMAIL PROTECTED] writes:
> Hi,
> 
> I recently upgraded our mail relay software:
> 
> (sendmail is 8.13.3, but I didn't upgrade this)
> 
> mimedefang from 2.51 to 2.53
> razor2 from 2.67 to 2.77
> dcc from 1.2.71 to 1.3.18
> spamassassin from 3.0.2 to 3.1.0
> 
> we executed spamassassin via mimedefang's mimedefang-filter file (and 
> accompanying sa-mimedefang.cf file, neither of these files were modified 
> during the upgrade), these are the lines that invoke spamassassin:
> 
> # Spam checks if SpamAssassin is installed
> if ($Features{"SpamAssassin"}) {
> if (-s "./INPUTMSG" < 100*1024) {
> # Only scan messages smaller than 100kB.  Larger messages
> # are extremely unlikely to be spam, and SpamAssassin is
> # dreadfully slow on very large messages.
> my($hits, $req, $names, $report) = spam_assassin_check();
> my($score);
> if ($hits < 40) {
> $score = "*" x int($hits);
> } else {
> $score = "*" x 40;
> 
> 
> the initial upgrade went fine, but recently, customers start to complain 
> that they receive more spam than before.
> When I checked the logfiles, i noticed that ***before the upgrade***, i 
> had lots of lines with 
> 
> BAYES_99,DCC_CHECK,DIGEST_MULTIPLE,FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_40_50,HTML_MESSAGE,MIME_HTML_ONLY,MSGID_OUTLOOK_INVALID,NO_DNS_FOR_FROM,NO_REAL_NAME,RAZOR2_CF_RANGE_51_100,RAZOR2_CHECK,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL,RCVD_IN_XBL,SARE_OEM_PRODS_1,SARE_OEM_PRODS_2,SARE_OEM_PRODS_3,SARE_OEM_PRODS_FEW,SARE_OEM_SOFT_IS,SARE_PRODS_LOTS,SARE_PRODUCTS_02,SARE_PRODUCTS_03,SARE_PRODUCTS_04
> 
> 
> 
> now, ***after the upgrade*** these are the sort of checks i see on mails 
> marked as spam:
> BAYES_99,DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_HOTMAIL_RCVD2,HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,INFO_TLD,MIME_HEADER_CTYPE_ONLY,MIME_HTML_ONLY,MSGID_FROM_MTA_ID,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DSBL,RCVD_IN_NJABL_PROXY,RCVD_IN_SORBS_DUL,RCVD_IN_SORBS_SOCKS
> 
> now, as far as i can tell, these checks are defined in the SARE rules in 
> my directory /usr/perl5/5.6.1/share/spamassassin, so at least I assume 
> spamassassin is being started by mimedefang
> 
> But I don't see any DCC_CHECK , or RAZOR2 line anymore in my logs, even 
> thoug it is enabled (I now the lines in v310.pre are commented. In general 
> i see for the mails marked as spam at lot less checks.
> 
> I didn't alter the rules in /usr/perl/5.6.1/share/spamassassin (I didn't 
> read anywhere that I needed to upgrade them for 3.1.0)
> 
> spamassassin --lint -D returns this (also indicating that everything 
> should be fine and that network checks are enabled):
> 
> 
> [419] dbg: logger: adding facilities: all
> [419] dbg: logger: logging level is DBG
> [419] dbg: generic: SpamAssassin version 3.1.0
> [419] dbg: config: score set 0 chosen.
> [419] dbg: util: running in taint mode? yes
> [419] dbg: util: taint mode: deleting unsafe environment variables, 
> resetting PATH
> [419] dbg: util: PATH included '/usr/sbin', keeping
> [419] dbg: util: PATH included '/usr/bin', keeping
> [419] dbg: util: PATH included '/usr/sbin', keeping
> [419] dbg: util: PATH included '/usr/ccs/bin', keeping
> [419] dbg: util: PATH included '/opt/sfw/bin', keeping
> [419] dbg: util: PATH included '/usr/local/bin', keeping
> [419] dbg: util: PATH included '/usr/perl5/5.6.1/bin', keeping
> [419] dbg: util: final PATH set to: 
> /usr/sbin:/usr/bin:/usr/sbin:/usr/ccs/bin:/opt/sfw/bin:/usr/local/bin:/usr/perl5/5.6
> .1/bin
> [419] dbg: dns: is Net::DNS::Resolver available? yes
> [419] dbg: dns: Net::DNS version: 0.48
> [419] dbg: dns: name server: 193.110.158.169, family: 2, ipv6: 0
> [419] dbg: diag: perl platform: 5.006001 solaris
> [419] dbg: diag: module installed: Digest::SHA1, version 2.10
> [419] dbg: diag: module not installed: IO::Socket::SSL ('require' failed)
> [419] dbg: diag: module installed: Time::HiRes, version 1.59
> [419] dbg: diag: module installed: DBI, version 1.45
> [419] dbg: diag: module installed: Getopt::Long, version 2.25
> [419] dbg: diag: module installed: LWP::UserAgent, version 2.032
> [419] dbg: diag: module installed: HTTP::Date, version 1.46
> [419] dbg: diag: module not installed: Archive::Tar ('require' failed)
> [419] dbg: diag: module not installed: IO::Zlib ('require' failed)
> [419] dbg: diag: module installed: MIME::Base64, version 3.05
> [419] dbg: diag: module installed: HTML::Parser, version 3.45
> [419] dbg: diag: module installed: DB_File, version 1.810
> [419] dbg: diag: module installed: Net::DNS, version 0.48
> [419] dbg: diag: module installed: Net::SMTP, version 2.28
> [4

Re: spamassassin less effective after upgrade to 3.1.0: some checks no longer executed ?

[Menno van Bennekom]

I see that the site rules dir is "/usr/perl5/5.6.1/etc/mail/spamassassin"
according to the debug output, maybe you should check that your local.cf
v310.pre and sare-rules exist in that directory.

Regards
Menno van Bennekom

> Hi,
>
> I recently upgraded our mail relay software:
>
> (sendmail is 8.13.3, but I didn't upgrade this)
>
> mimedefang from 2.51 to 2.53
> razor2 from 2.67 to 2.77
> dcc from 1.2.71 to 1.3.18
> spamassassin from 3.0.2 to 3.1.0
>
> we executed spamassassin via mimedefang's mimedefang-filter file (and
> accompanying sa-mimedefang.cf file, neither of these files were modified
> during the upgrade), these are the lines that invoke spamassassin:
>
> # Spam checks if SpamAssassin is installed
> if ($Features{"SpamAssassin"}) {
> if (-s "./INPUTMSG" < 100*1024) {
> # Only scan messages smaller than 100kB.  Larger messages
> # are extremely unlikely to be spam, and SpamAssassin is
> # dreadfully slow on very large messages.
> my($hits, $req, $names, $report) = spam_assassin_check();
> my($score);
> if ($hits < 40) {
> $score = "*" x int($hits);
> } else {
> $score = "*" x 40;
>
>
> the initial upgrade went fine, but recently, customers start to complain
> that they receive more spam than before.
> When I checked the logfiles, i noticed that ***before the upgrade***, i
> had lots of lines with
>
> BAYES_99,DCC_CHECK,DIGEST_MULTIPLE,FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_40_50,HTML_MESSAGE,MIME_HTML_ONLY,MSGID_OUTLOOK_INVALID,NO_DNS_FOR_FROM,NO_REAL_NAME,RAZOR2_CF_RANGE_51_100,RAZOR2_CHECK,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL,RCVD_IN_XBL,SARE_OEM_PRODS_1,SARE_OEM_PRODS_2,SARE_OEM_PRODS_3,SARE_OEM_PRODS_FEW,SARE_OEM_SOFT_IS,SARE_PRODS_LOTS,SARE_PRODUCTS_02,SARE_PRODUCTS_03,SARE_PRODUCTS_04
>
>
>
> now, ***after the upgrade*** these are the sort of checks i see on mails
> marked as spam:
> BAYES_99,DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_HOTMAIL_RCVD2,HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,INFO_TLD,MIME_HEADER_CTYPE_ONLY,MIME_HTML_ONLY,MSGID_FROM_MTA_ID,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DSBL,RCVD_IN_NJABL_PROXY,RCVD_IN_SORBS_DUL,RCVD_IN_SORBS_SOCKS
>
> now, as far as i can tell, these checks are defined in the SARE rules in
> my directory /usr/perl5/5.6.1/share/spamassassin, so at least I assume
> spamassassin is being started by mimedefang
>
> But I don't see any DCC_CHECK , or RAZOR2 line anymore in my logs, even
> thoug it is enabled (I now the lines in v310.pre are commented. In general
> i see for the mails marked as spam at lot less checks.
>
> I didn't alter the rules in /usr/perl/5.6.1/share/spamassassin (I didn't
> read anywhere that I needed to upgrade them for 3.1.0)
>
> spamassassin --lint -D returns this (also indicating that everything
> should be fine and that network checks are enabled):
>
>
> [419] dbg: logger: adding facilities: all
> [419] dbg: logger: logging level is DBG
> [419] dbg: generic: SpamAssassin version 3.1.0
> [419] dbg: config: score set 0 chosen.
> [419] dbg: util: running in taint mode? yes
> [419] dbg: util: taint mode: deleting unsafe environment variables,
> resetting PATH
> [419] dbg: util: PATH included '/usr/sbin', keeping
> [419] dbg: util: PATH included '/usr/bin', keeping
> [419] dbg: util: PATH included '/usr/sbin', keeping
> [419] dbg: util: PATH included '/usr/ccs/bin', keeping
> [419] dbg: util: PATH included '/opt/sfw/bin', keeping
> [419] dbg: util: PATH included '/usr/local/bin', keeping
> [419] dbg: util: PATH included '/usr/perl5/5.6.1/bin', keeping
> [419] dbg: util: final PATH set to:
> /usr/sbin:/usr/bin:/usr/sbin:/usr/ccs/bin:/opt/sfw/bin:/usr/local/bin:/usr/perl5/5.6
> .1/bin
> [419] dbg: dns: is Net::DNS::Resolver available? yes
> [419] dbg: dns: Net::DNS version: 0.48
> [419] dbg: dns: name server: 193.110.158.169, family: 2, ipv6: 0
> [419] dbg: diag: perl platform: 5.006001 solaris
> [419] dbg: diag: module installed: Digest::SHA1, version 2.10
> [419] dbg: diag: module not installed: IO::Socket::SSL ('require' failed)
> [419] dbg: diag: module installed: Time::HiRes, version 1.59
> [419] dbg: diag: module installed: DBI, version 1.45
> [419] dbg: diag: module installed: Getopt::Long, version 2.25
> [419] dbg: diag: module installed: LWP::UserAgent, version 2.032
> [419] dbg: diag: module installed: HTTP::Date, version 1.46
> [419] dbg: diag: module not installed: Archive::Tar ('require' failed)
> [419] dbg: diag: module not installed: IO::Zlib ('require' failed)
> [419] dbg: diag: module installed: MIME::Base64, version 3.05
> [419] dbg: diag: module installed: HTML::Parser, version 3.45
> [419] dbg: diag: module installed: DB_File, version 1.810
> [419] dbg: diag: module installed: Net::DNS, version 0.48
> [419] dbg: diag: module installed: Net::SMTP, version 2.28
> [419] dbg: diag: module not installed: Mail::SPF::Query ('require' failed)
> [419] dbg: diag: module not installe

spamassassin less effective after upgrade to 3.1.0: some checks no longer executed ?

[tomvo]

Hi,

I recently upgraded our mail relay software:

(sendmail is 8.13.3, but I didn't upgrade
this)

mimedefang from 2.51 to 2.53
razor2 from 2.67 to 2.77
dcc from 1.2.71 to 1.3.18
spamassassin from 3.0.2 to 3.1.0

we executed spamassassin via mimedefang's
mimedefang-filter file (and accompanying sa-mimedefang.cf file, neither
of these files were modified during the upgrade), these are the lines that
invoke spamassassin:

    # Spam checks if SpamAssassin
is installed
    if ($Features{"SpamAssassin"})
{
        if (-s "./INPUTMSG"
< 100*1024) {
           
# Only scan messages smaller than 100kB.  Larger messages
           
# are extremely unlikely to be spam, and SpamAssassin is
           
# dreadfully slow on very large messages.
           
my($hits, $req, $names, $report) = spam_assassin_check();
           
my($score);
           
if ($hits < 40) {
           
    $score = "*" x int($hits);
           
} else {
           
    $score = "*" x 40;


the initial upgrade went fine, but recently,
customers start to complain that they receive more spam than before.
When I checked the logfiles, i noticed
that ***before the upgrade***, i had lots of lines with 

BAYES_99,DCC_CHECK,DIGEST_MULTIPLE,FORGED_OUTLOOK_HTML,FORGED_OUTLOOK_TAGS,HTML_40_50,HTML_MESSAGE,MIME_HTML_ONLY,MSGID_OUTLOOK_INVALID,NO_DNS_FOR_FROM,NO_REAL_NAME,RAZOR2_CF_RANGE_51_100,RAZOR2_CHECK,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL,RCVD_IN_XBL,SARE_OEM_PRODS_1,SARE_OEM_PRODS_2,SARE_OEM_PRODS_3,SARE_OEM_PRODS_FEW,SARE_OEM_SOFT_IS,SARE_PRODS_LOTS,SARE_PRODUCTS_02,SARE_PRODUCTS_03,SARE_PRODUCTS_04



now, ***after the upgrade*** these are
the sort of checks i see on mails marked as spam:
BAYES_99,DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_HOTMAIL_RCVD2,HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,INFO_TLD,MIME_HEADER_CTYPE_ONLY,MIME_HTML_ONLY,MSGID_FROM_MTA_ID,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_DSBL,RCVD_IN_NJABL_PROXY,RCVD_IN_SORBS_DUL,RCVD_IN_SORBS_SOCKS

now, as far as i can tell, these checks
are defined in the SARE rules in my directory /usr/perl5/5.6.1/share/spamassassin,
so at least I assume spamassassin is being started by mimedefang

But I don't see any DCC_CHECK , or RAZOR2
line anymore in my logs, even thoug it is enabled (I now the lines in v310.pre
are commented. In general i see for the mails marked as spam at lot less
checks.

I didn't alter the rules in /usr/perl/5.6.1/share/spamassassin
(I didn't read anywhere that I needed to upgrade them for 3.1.0)

spamassassin --lint -D returns this
(also indicating that everything should be fine and that network checks
are enabled):


[419] dbg: logger: adding facilities:
all
[419] dbg: logger: logging level is
DBG
[419] dbg: generic: SpamAssassin version
3.1.0
[419] dbg: config: score set 0 chosen.
[419] dbg: util: running in taint mode?
yes
[419] dbg: util: taint mode: deleting
unsafe environment variables, resetting PATH
[419] dbg: util: PATH included '/usr/sbin',
keeping
[419] dbg: util: PATH included '/usr/bin',
keeping
[419] dbg: util: PATH included '/usr/sbin',
keeping
[419] dbg: util: PATH included '/usr/ccs/bin',
keeping
[419] dbg: util: PATH included '/opt/sfw/bin',
keeping
[419] dbg: util: PATH included '/usr/local/bin',
keeping
[419] dbg: util: PATH included '/usr/perl5/5.6.1/bin',
keeping
[419] dbg: util: final PATH set to:
/usr/sbin:/usr/bin:/usr/sbin:/usr/ccs/bin:/opt/sfw/bin:/usr/local/bin:/usr/perl5/5.6
.1/bin
[419] dbg: dns: is Net::DNS::Resolver
available? yes
[419] dbg: dns: Net::DNS version: 0.48
[419] dbg: dns: name server: 193.110.158.169,
family: 2, ipv6: 0
[419] dbg: diag: perl platform: 5.006001
solaris
[419] dbg: diag: module installed: Digest::SHA1,
version 2.10
[419] dbg: diag: module not installed:
IO::Socket::SSL ('require' failed)
[419] dbg: diag: module installed: Time::HiRes,
version 1.59
[419] dbg: diag: module installed: DBI,
version 1.45
[419] dbg: diag: module installed: Getopt::Long,
version 2.25
[419] dbg: diag: module installed: LWP::UserAgent,
version 2.032
[419] dbg: diag: module installed: HTTP::Date,
version 1.46
[419] dbg: diag: module not installed:
Archive::Tar ('require' failed)
[419] dbg: diag: module not installed:
IO::Zlib ('require' failed)
[419] dbg: diag: module installed: MIME::Base64,
version 3.05
[419] dbg: diag: module installed: HTML::Parser,
version 3.45
[419] dbg: diag: module installed: DB_File,
version 1.810
[419] dbg: diag: module installed: Net::DNS,
version 0.48
[419] dbg: diag: module installed: Net::SMTP,
version 2.28
[419] dbg: diag: module not installed:
Mail::SPF::Query ('require' failed)
[419] dbg: diag: module not installed:
IP::Country::Fast ('require' failed)
[419] dbg: diag: module installed: Razor2::Client::Agent,
version 2.77
[419] dbg: diag: module not installed:
Net::Ident ('require' failed)
[419] dbg: diag: module not installed:
IO::Socket::INET6 ('require' failed)
[419] dbg: ignore: using a test message
to lint rules
[419] dbg: config: using "/usr/perl5/5.6.1/etc/mail/spamassassin"
for site rules pre

Re: Spam increase after "upgrade" to 3.03 on Debian Stable

[Magnus Holmgren]

Bill Moseley wrote:
> 
> I updated two very similar Woody machines that day, and this machine
> was trouble -- for some reason dist-upgraded removed a number of
> packages for a reason I'm not clear on.  (Like Apache and Bind!)
> 
OT and probably too late, but in case anyone else's planning to do the
same: It's recommended to use aptitude to upgrade to Sarge, due to its
better dependency handling.

-- 
Magnus Holmgren
[EMAIL PROTECTED]