On Apr 3, 2012, at 12:13 PM, Matt Simerson wrote:
> On Apr 3, 2012, at 7:09 AM, Jared Johnson wrote:
>
>>>> 6. spamassassin plugin: added support for per-user SA config settings,
>>>> rewrote header processing logic in spamassassin plugin so it adds all the
>>>> SA generated X-Spam-* headers to the message. Refactored the code for
>>>> better maintainability.
>>>
>>> Adding all the X-Spam-* headers to all recipients' messages could
>>> technically be thought of as too transparent in some situations. <snip>
>>>
>>> Anyway this isn't exactly an objection, just pointing it out in case
>>> anyone can think of a more serious problem with such transparency. The
>>> only other option is to queue multiple messages, one for each recipient.
>>> This is quite a lot of trouble to go to just to avoid exposing X-Spam-*
>>> headers to other recipients... although our organization's fork does go to
>>> this trouble in order to deal with other problems, like Subject header to
>>> use when different recipients have differing spam scores and subject
>>> tagging is on :)
>>
>> We could add a "suppress headers..." config option.
>>
>> I would suggest instead editing the SpamAssassin config and not have those
>> headers added in the first place...
>
> <snip>We could adopt a similar approach. If the message has multiple
> recipients, then leave the username as qpsmtpd typically sets:
>
> my $username = $self->{_args}->{spamd_user} || getpwuid($>);
>
> If the username is 'vpopmail' and there's only one recipient, then set
> $username to the email address of the recipient, so that per-user
> SpamAssassin prefs are used.
>
> I already have a site-wide maildrop filter. For my users that enable "spam
> filtering" (the default, so almost all of them), their messages are delivered
> via maildrop. Maildrop inspects the messages during delivery and if the
> message has no SA headers, then it gets passed to spamd before delivery and
> the recipients per-user prefs will get honored.
>
> Pros:
> 1. Every message for every recipient is assured to have that users
> personal spam preferences honored.
> 2. The X-Spam- tags in every delivered message will reflect that users
> personal preferences.
>
> Cons:
> 1. For sites whose LDA does SA filtering, messages with scores lower
> than check_spam_reject that are not tagged by qpsmtpd will get scanned once
> during the SMTP conversation, and then once for each recipient. I think this
> may be better than having qpsmtpd queue multiple messages. That approach
> scans every message recipient pair once, even for messages above the
> check_spam_reject score. I just checked my logs and 36% of messages received
> today had scores above check_spam_reject.
>
> 2. Messages significantly affected by a per-user pref (like a
> blacklisted sender) that would have been rejected by qpsmtpd will then be
> subject to the LDA rules. This is only a con because the spam munge and
> reject scores needs to be set in two locations on the server. If the settings
> differ, it could cause confusion.
>
> Other thoughts?
> Matt
I have reworked the SA plugin, making it much more modular and easier to grok.
I also changed the per-user feature to only take effect if the message has a
single recipient. I also added this POD to the module:
=head1 MULTIPLE RECIPIENT BEHAVIOR
This plugin supports per-user SpamAssassin preferences. When per-user SA prefs
are enabled (by setting spamd_user = vpopmail), the message recipient is used
as the spamd username. If SpamAssassin has per-user preferences enabled, it
will consult the users spam preferences when scoring the message.
When a message has multiple recipients, we do not change the spamd username.
The message is still scored by SA, but per-user preferences are not
consulted. To aid in debugging, messages with multiple recipents will
have an X-Spam-User header inserted. Admins and savvy users can look for
that header to confirm the reason their personal prefs were not consulted.
To get per-user SA prefs to work for messages with multiple recipients, the
LDA should be configured to check for the presence of the X-Spam-User header.
If the X-Spam-User header is present, the LDA should submit the message to
spamd for re-processing with the recipients address.
Full details are available on GitHub:
https://github.com/msimerson/qpsmtpd/blob/cebbc2dfb5f776cca92c8aa5854f97c8e0523050/plugins/spamassassin
Matt
