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

On 2026-01-07 at 23:25:42 UTC-0500 (Wed, 7 Jan 2026 21:25:42 -0700)
Philip Prindeville via users <[email protected]>
is rumored to have said:

> As best as I know, I invoke spamassassin via the mimedefang hook.

Standard historical behavior in MIMEDefang is to use SpamAssassin via 
its own import of the libraries and calling the relevant routines 
directly, rather than using the SpamAssassin Client spamc or talking its 
protocol to spamd processes. If you are using MIMEDefang you therefore 
DO NOT NEED to run a spamd daemon.

The latest version of MD  (3.5) includes an alternative mechanism of 
using Mail::SpamAssassin::Client, and if you are using that, then you DO 
need to run spamd.

Historically, MD has used /etc/mail/sa-mimedefang.cf or 
/etc/mail/spamassassin/sa-mimedefang.cf as its primary SA config file 
instead of local.cf, so if that exists it may be pointing at the wrong 
rules location.

In any case, you need to restart MIMEdefang for it to pick up rule 
changes.

>> On Jan 7, 2026, at 8:14 PM, David B Funk 
>> <[email protected]> wrote:
>>
>> 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{


-- 
  Bill Cole
  [email protected] or [email protected]
  (AKA @[email protected] and many *@billmail.scconsult.com 
addresses)
  Not Currently Available For Hire