> -----Messaggio originale-----
> Da: Luca Bertoncello [mailto:lucabert@lucabert.de]
> "Giampaolo Tomassoni" 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.


> Any idea?
> Thanks
> Luca Bertoncello
> (lucabert@lucabert.de)