> -----Messaggio originale----- > Da: Luca Bertoncello [mailto:[EMAIL PROTECTED] > > "Giampaolo Tomassoni" <[EMAIL PROTECTED]> schrieb: > > > What is your milter? What is your setup? This may influence stuff > like > > Back'n'Whitelists as well as autowhitelist. > > I use Exim and I scan the E-Mail with this rule: > > warn message = X-Spam-Score: $spam_score ($spam_bar) > spam = ${acl_m9}:true > > acl_m9 contains the username on the system. > > After the documentation of Exim, it will give the username to > SpamAssassin > (and this is confirmed by the using of personalized Black-/Whitelists).
Ok. I can't understand if you are using spamd or amavisd, but you are probably running SA in a daemon which instantiate SA once and then switches user at will. Now, if this is the case the Mail::SpamAssassin::PersistentAddrList class is instantiated only once too. At creation time, Mail::SpamAssassin::PersistentAddrList copies the current SA user in its own object, and then keeps using the copy. Thereby, when spamd/amavisd switches the SA user to the one which will get the e-mail, the username copy in the Mail::SpamAssassin::PersistentAddrList object wouldn't be affected, thereby the problem. This is something I already saw in my postgresql awl tables, but I'm quite happy with it because, after all, I prefer AWL to work globally, since it would be much less useful in a per-user way. You are however right: this behavior should be enforced only by using the user_awl_sql_override_username setting in SA, so it should not show without it. One could easily regard it as a bug, then. Giampaolo > Any idea? > > Thanks > Luca Bertoncello > ([EMAIL PROTECTED])
