R: R: R: R: R: Question about SQL-based AWL
> -Messaggio originale- > Da: Luca Bertoncello [mailto:[EMAIL PROTECTED] > > "Giampaolo Tomassoni" <[EMAIL PROTECTED]> schrieb: > > > 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, > > then... > > Ach! > Does it mean, that it is not possible to have a per-user-AWL if I use > the SpamAssassin-Daemon? Right, that's what I meant. FWIK, every and each SA-powered daemon do create a fresh SA instance at startup, then use it to inspect mail directed to different users by first "tweaking" the current user in SA. Since PersistentAddrList caches the user at startup, this tweaking can't work to AWL... Giampaolo > > Thanks > Luca Bertoncello > ([EMAIL PROTECTED])
Re: R: R: R: R: Question about SQL-based AWL
"Giampaolo Tomassoni" <[EMAIL PROTECTED]> schrieb: > 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, > then... Ach! Does it mean, that it is not possible to have a per-user-AWL if I use the SpamAssassin-Daemon? Thanks Luca Bertoncello ([EMAIL PROTECTED])
R: R: R: R: Question about SQL-based AWL
> -Messaggio originale- > Da: Luca Bertoncello [mailto:[EMAIL PROTECTED] > > "Giampaolo Tomassoni" <[EMAIL PROTECTED]> schrieb: > > > 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 > > Yes, of course! I forgot to say it... > > > 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. > > 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, then... Giampaolo > > Could you give me an example? > > Thanks a lot! > Luca Bertoncello > ([EMAIL PROTECTED])
Re: R: R: R: Question about SQL-based AWL
"Giampaolo Tomassoni" <[EMAIL PROTECTED]> schrieb: > 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 Yes, of course! I forgot to say it... > 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. 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... Could you give me an example? Thanks a lot! Luca Bertoncello ([EMAIL PROTECTED])
R: R: R: Question about SQL-based AWL
> -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])