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:
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?