Joe Acquisto-j4 wrote: > I'd like to revisit this, now that I have sufficient energy to devote to > some hard sleuthing. Despite the > fact that I was less than sharp (ahem) when first looking at this, I do > feel I have covered all the obvious > suspects. > > Some gentle nudges (or not) might get me rolling again. I suppose I > should repost this with details of what I > have done so far, as even those of kind and gentle nature may not be > inclined to search it out.
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? - is this a packaged SA, or installed from source? - where did the init script come from? - how are you calling SA for normal scanning? 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 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. > 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. -kgd
