Front page | perl.qpsmtpd |
Postings from April 2012
Re: A basket of changes
Thread Previous
|
Thread Next
From:
Matt Simerson
Date:
April 6, 2012 00:09
Subject:
Re: A basket of changes
Message ID:
ABD203B0-2DBF-4A63-9EF7-81E06669BC69@tnpi.net
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
Thread Previous
|
Thread Next