You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Joe Acquisto-j4 <jo...@j4computers.com> on 2013/09/07 02:49:32 UTC

Re: SA not "honoring" customs in "local.cf"

Thanks for the leads.

>>> On 9/6/2013 at 10:05 AM, Kris Deugau <kd...@vianet.ca> wrote:
> Joe Acquisto-j4 wrote:
>. . . 
> I read back a bit in the thread;  you've definitely got something
> strange going on.
> 
> I don't see a couple of bits of information that might help narrow it down:
> 
> - which distribution?

OpenSuSE 12.2  
SA version appears to be 3.3.2 

> - is this a packaged SA, or installed from source?

Came with distro

> - where did the init script come from?

> - how are you calling SA for normal scanning?

If I understand correctly- 
Postfix - master.cf has a spamasssasin entry which calls a batch file which in turn calls spamc.

> Next:
> 
> You should have, in the first few lines from spamassassin -D --lint, a
> line like this (this is from CentOS, self-built package derived at one
> time from the RPMForge package):
> 
> Sep  6 09:35:26.372 [30447] dbg: generic: Perl 5.008008, PREFIX=/usr,
> DEF_RULES_DIR=/usr/share/spamassassin, LOCAL_RULES
> _DIR=/etc/mail/spamassassin, LOCAL_STATE_DIR=/var/lib/spamassassin

Matches 

> SA reads rules from all of these locations, and the processes them from
> the DEF_RULES_DIR, LOCAL_STATE_DIR, and then LOCAL_RULES_DIR locations,
> sorted alphabetically within each grouping.  Unfortunately -D doesn't
> actually indicate when it parses any given specific file from one of
> those locations.
> 
> Try "grep -r RP_MATCHES_RCVD /etc" - compare that with the list of files
> spamassassin -D --lint reports that it's read.

Seems to agree

> The /etc/init.d/spamd file has a hardcoded reference to that specific
>> file. I'm pretty sure it is the one being read.
> 
> Take a message that triggered this rule, and run "spamassassin <
> message";  does it still trigger the rule?  If not then try removing the
> arguments that set any of the configuration paths from the init script.
>  For most cases this is redundant anyway;  SA knows which directories it
> should look in.

Well, if I interpret the output to screen correctly, it does not.  That is, the "top"
of the output does not show it, but further "down" the original scoring does show.

I had to dig way back into older SPAM to find one that had that scoring.   None 
of the recent stuff has that entry.  IIRC setting the value to 0, for this test, has the effect of
not running it.   So, I guess it is actually working now?

Still, there are some BAYES scores that do not seem to take effect.
 
> -kgd