http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5131
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[EMAIL PROTECTED]
------- Additional Comments From [EMAIL PROTECTED] 2006-10-17 10:36 -------
Simply purging the current Mail::SpamAssassin object and creating a new one to
load a new
configuration set into doesn't work. Nearly all rules are stored in some global
area. This means that
when you kill the Mail::SpamAssassin object you don't actually kill all of the
loaded rules.
Now look at how rules are executed in, for instance,
PerMsgStatus.pm::do_head_tests(). We loop over
the static data in Mail::SpamAssassin::PerMsgStatus::_head_tests_*.
So, imagine for a moment what happens when you remove rules from a rules file
between HUPs. That's
right: the rules continue to be run because nothing actually purges all of the
in-memory rules.
A valid next step in trying to solve this is to head over to
Mail::SpamAssassin::PerMsgStatus::_head_tests_ and start deleting all of the
loaded rules. Do this for
head tests, body tests, raw body tests etc. Great, the hack works. Wrong. There
are some plugins that
come with SA that store their data in some made-up global namespace. Now you
have special cases to
clean up. Ugg.
Why not fix this correctly by cleaning up the config namespace such that all
config data is stored in one
nice container. Purge the container: purge all of the rules.
HUP is the easy part. It's like a 20-line patch at most. This isn't the problem
though. The problem is
finding and refactoring all of the different rule plugins that store their data
in ruletype-specific places
and changing them to be stored in a nice container that is a member of a
Mail::SpamAssassin instance.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
