On 2022-11-29 at 18:39:49 UTC-0500 (Wed, 30 Nov 2022 09:39:49 +1000)
Adam Nielsen via Exim-users <a.nielsen@???>
is rumored to have said:
> Hi all,
>
> I'm running into an issue with the way Exim 4.94.2 invokes
> SpamAssassin (SA).
>
> I have added some custom rules to SA, however when Exim invokes it, my
> custom rules are ignored.
Where did you add the rules?
SA uses 3 sets of rules:
1. Channel rules. Typically only the default rule channel from the ASF
SA project itself but also any others maintained with sa-update, such as
the popular KAM channel. Location varies b y distribution/packager
choice, usually something like /var/{db,lib,share,}/spamassassin/<SA
Version>/<Channel>. These should never be edited by hand.
2. Site-wide local rules in *.cf text files. Typically
/etc/mail/spamassassin/ but sometimes elsewhere depending on packager
choices.
3. Per-User local rules. These are all the *.cf files in
$HOME/.spamassassin/
1 & 2 should be loaded no matter how you use SA. 3 can be finicky,
especially when using SA via the spamd daemon.
> However if I use the "spamc" command to manually pass an e-mail into
> SA
> (or if I run SA from the command line) then my custom rules are picked
> up correctly.
This looks like SA (specifically in this case: the spamd daemon) is
using different rulesets between Exim and interactive calls. The only
reason that should happen in this pattern is if you've given spamd the
right arguments for per-user rules but Exim and spamc are not running as
the same user OR spamd cannot properly select or access per-user rules
when called from Exim OR spamd has not loaded the current rules.
The last case has the simplest possible solution: just restart spamd.
> I originally thought this was a SA problem, however I am unable to
> reproduce the issue using SA tools, it is only when Exim calls SA that
> I see the problem.
Right, but it is still a SA problem.
The "spamassassin" script always uses the currently effective user's
per-user rules and the current site-wide rules, as it doesn't use spamd.
If you use spamc, you may have environment variables that affect which
per-user rules (if any) it loads and you may be talking to a fresh spamd
child instance which has the latest rules loaded, or you may be talking
to an older one that has a stale ruleset.
It's also possible that you have spamd trying to load per-user rules
that it can find for your command-line invocation but cannot determine
when Exim is calling it.
> Is there any sort of test mode I can use to see how exactly Exim is
> passing the message to SA so I can further debug the problem? I've
> had
> a look through the command line docs and I can only see test modes for
> virus scanners, but nothing stands out for the spam checker.
>
> I'm specifying SA in the Exim config as:
>
> spamd_address = 127.0.0.1 783
That eliminates almost everything that Exim could do "wrong" in calling
SA, given a reasonably normal config (i.e. no embedded Perl.) The spamd
client protocol is very simple and spamd is not tolerant of deviations.
So the problem is in what spamd is doing. It is possible to run spamd
with debug flags (-D <list of diag classes>) to get its activity
details logged but that is not a reasonable thing to do on a high-volume
system.
> It runs correctly and the default rules are applied, with the e-mail
> being delivered with newly added spam headers, so everything appears
> to
> be working fine. I have added many custom rules in the past (with the
> same Exim config) and it has worked fine, it's just the latest custom
> rule I added only gets used when *I* call SA, not when Exim calls it,
> and I haven't been able to work out why.
Simplest possible solution: restart spamd. That would fix the stale
ruleset possibility.
Without knowing your specific spamd config it is impossible to guess
what a fix for a more complex issue with ruleset selection might be...
--
Bill Cole
bill@??? or billcole@???
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
