We could easily add a "suppress headers..." config option. I would suggest instead editing the SpamAssassin config and not have those headers added in the first place...
Sent from my iPad On Apr 3, 2012, at 7:09 AM, "Jared Johnson" <jjohn...@efolder.net> 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. In > practical terms the worst thing I can think of would be that one recipient > would be able to see that some other recipient whose preferences they are > not allowed to look at has whitelisted or blacklisted some sender address. > That's assuming you have added information to each header to indicate > which recipient it is for -- but if you haven't, how would each recipient > know which X-Spam-* header applies to them? > > 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 :) > > -Jared >
