Replacing SA preferences switch with a custom hook

[MRob]

On 2016-12-01 15:54, Tom Johnson wrote:
> We're using sa_userpref for a few customers, but the time penalty
> that's incurred doing a save of current preferences and a load of the
> new ones is starting to hurt.
> 
> We've found we're using only a few of the possible settings that can
> be used here, and are considering moving these off into a hook or
> module instead of doing the full spamassassin config reload:
> 
> 	score
> 	ok_languages
> 	whitelist_from_rcvd
> 	whitelist_subject
> 	blacklist_subject
> 
> The last three could be checked before invoking SA, so we could
> short-circuit that process.  The first two might need to be done after
> the SA check, so adjustments could be made to the final score.
> 
> Has anyone else looked at moving these sorts of small individual
> features into a custom hook who would like to share what they've done?
>  Or is there interest from anyone else for this sort of thing? If
> there is, we'd be happy to share what we come up with.

We are absolutely interested in this. Currently we have two different 
solutions in different places:

(1) Don't do any per-user settings in amavis/SA, make sure 
$sa_tag_level_deflt is undef and $sa_spam_subject_tag is empty string. 
This causes the spam status headers to be inserted in all cases, then we 
apply filtering rules during delivery that let the user tag the subject 
or other things. The annoying part about this is if a user sets a 
different score than our $sa_tag2_level_deflt, the headers don't agree 
with their spam detection level. We tell users to ignore the 
discrepancy, since our filter system goes by score and not the yes/no 
indicators. I suppose it might be possible to rewrite the yes/no parts 
of the headers, but that seems dubious.

(2) Run SA out of the LDA instead of amavis. This gives complete control 
to the users, though multiple recipient emails will get scanned more 
than once and if a user changes scoring that lets egregious spam through 
and sets a forwarding address to Gmail, Hotmail or Yahoo, our MTA's 
reputation suffers (or indeed, if forwarding is done with aliases in the 
MTA, *all* spam gets sent to the destination which can be harmful).

I hadn't known that amavis per-user settings carried a performance 
burden, so that's good to know. I'm not sure if you'd be interested in 
option 2 and would be keen to know if you think it might suffer the same 
performance problems (spamd looking up user settings in SQL).

May I ask what your present per-user setup is?