> 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
