This is a discussion on R: R: R: R: Question about SQL-based AWL - SpamAssassin ; > -----Messaggio originale----- > Da: Luca Bertoncello [mailto:firstname.lastname@example.org] > > "Giampaolo Tomassoni" schrieb: > > > Ok. I can't understand if you are using spamd or amavisd, but you are > > probably running SA in a daemon which instantiate ...
> -----Messaggio originale-----
> Da: Luca Bertoncello [mailto:email@example.com]
> "Giampaolo Tomassoni"
> > 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
> Yes, of course! I forgot to say it...
> > You are however right: this behavior should be enforced only by using
> > user_awl_sql_override_username setting in SA, so it should not show
> > it. One could easily regard it as a bug, then.
> OK! I seen this statement, but I didn't undestood how it works...
> It expects a parameter, but I don't know what I have to write...
Luca, I'm meaning this behavior should be enforced only by turning the
user_awl_sql_override_username switch on, and then the SQL 'username' column
would be filled with the username to be used to connect to the sql db, as
opposed to the current SA user.
Actually, when user_awl_sql_override_username is off, you should get a
per-user AWL in which the sql 'username' column is filled with the current
SA user. Unfortunately, PersistentAddrList caches the SA username at
startup, which is when the SA username is the one of the user starting SA
(nobody in your case). It seems to me that this caching defeats any attempt
to change the AWL username later.
You can't obtain a per-user AWL by tweaking user_awl_sql_override_username,
> Could you give me an example?
> Thanks a lot!
> Luca Bertoncello