Replacing SA preferences switch with a custom hook

[MRob]

On 2016-12-01 18:19, Tom Johnson wrote:
> MRob wrote
> 
>> On Dec 1, 2016, at 5:59 PM, MRob <mrobti at insiberia.net> wrote:
>> 
>> (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?
> 
> Neither of these work for us, since we filter email for thousands of
> domains and aren't doing local delivery of the email, and because we
> need all the header information to be accurate for our users.
> 
> Right now we use the sa_userconf sql field, and a sa_userpref table
> per the standard SpamAssassin methodology.  But the SA switch user can
> easily add several hundred milliseconds to the processing of each
> mail, so we need to get rid of it.
> 
> We need to adjust the SA score, and have amavisd-new then process the
> email appropriately, making sure all the headers are correct, the
> email is properly delivered or quarantined, etc....  Either that's
> going to have be via the user preference switch, or we have to do it
> in a Custom hook (checks).  And the slower processing time is forcing
> us to look at the latter solution.

Amavis uses SA as a library, right? Maybe it would be beneficial to make 
amavis call spamd instead; I don't know if spamd would be more efficient 
at changing user preferences(?).