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...
This seems like the sort of topic that deserves a mention in the spamassassin plugin POD. After pondering it, I looked around and found this: http://www.qmailwiki.org/Simscan/Guide#Multiple_Recipient_Problem_with_Per_User_simscan_option If there is a single recipient in the email then simscan adds the -u user@domain option to spamc. This tells spamassassin to look up the users preferences to over ride the system wide spamassassin preferences. But if there is more than one recipient then which user preference should simscan set? The solution simscan uses is if there is more than one recipient and the --enable-spamc-user option is set, then it skips adding the -u user@domain option to spamc. This problem is avoided by having your local delivery agent do the spamassassin processing. That seems reasonable and 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. As far as adding the X-Spam- headers, I think this is a good solution: if ( $recipient_count > 1 && $username =~ /@/ ) { # do NOT add X-Spam- headers } else { # add X-Spam-* headers }; 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
