Re: Changes to /etc/mail/spamassassin/sa-rules.cf not taking after restarting spamassassin service

Philip,

There's probably some other mechanism that is using SA in some way which you are 
not 'looking' at.
For example, AMAVISD imports the SA perl "engine" within itself and doesn't use 
'spamd' at all.
You may have some kind of filter-chain in your MSA (postfix maybe?) that is 
invoking "spamassassin" as a filter process and configured to use SA from some 
other directory.

Try stopping your 'spamd' and send yourself mail. If it's still getting filtered 
then you haven't found the actual SA agent, time to do some detective work.


On Wed, 7 Jan 2026, Philip Prindeville via users wrote:

> Hi all,
>
> I'm on Fedora 43 running spamassassin-4.0.1-7.
>
> A rule involving sendgrid.net was causing false positives so I tried to comment it on in spamassassin/sa-rules.cf and restarted the service.
>
> No dice.  I was still getting matches against it.
>
> So I changed the name and lowered the score and did a service stop/start just in case.  No change!!!  The rule by the old name was still getting matches.
>
> What's going on?  That's not supposed to be able to happen.
>
> What would cause it to hold onto an old version of the file even after restarting?  Is there a cache I'm not aware of?
>
> I did a "ps -ef | grep -e spamd -e spamassassin" after the "stop" just to make sure the processes were all being cleaned up.  They were.
>
> So how is this happening?
>
> Thanks,
>
> -Philip
>
>

-- 
Dave Funk                               University of Iowa
<dbfunk (at) engineering.uiowa.edu>     College of Engineering
319/335-5751   FAX: 319/384-0549        1256 Seamans Center, 103 S Capitol St.
Sys_admin/Postmaster/cell_admin         Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{