You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Luca Bertoncello <lu...@lucabert.de> on 2007/07/28 11:53:24 UTC
Question about SQL-based AWL
Hi, list!
I use SpamAssassin 3.2.2 and I configured it to use a MySQL-DB to manage the
Bayes and the AWL.
So, I created the table awl after the documentation, and I write all the data
in local.cf.
All runs perfectly!
Now the question: in the table awl I have a field username, but this is
always nobody.
I tought, it is the user that receive the E-Mails, but it doesn't seems so.
Can someone explain me, what does this field do?
Thanks a lot
Luca Bertoncello
(lucabert@lucabert.de)
R: R: R: R: R: Question about SQL-based AWL
Posted by Giampaolo Tomassoni <g....@libero.it>.
> -----Messaggio originale-----
> Da: Luca Bertoncello [mailto:lucabert@lucabert.de]
>
> "Giampaolo Tomassoni" <g....@libero.it> 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
> (lucabert@lucabert.de)
Re: R: R: R: R: Question about SQL-based AWL
Posted by Luca Bertoncello <lu...@lucabert.de>.
"Giampaolo Tomassoni" <g....@libero.it> 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
(lucabert@lucabert.de)
R: R: R: R: Question about SQL-based AWL
Posted by Giampaolo Tomassoni <g....@libero.it>.
> -----Messaggio originale-----
> Da: Luca Bertoncello [mailto:lucabert@lucabert.de]
>
> "Giampaolo Tomassoni" <g....@libero.it> 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
> (lucabert@lucabert.de)
Re: R: R: R: Question about SQL-based AWL
Posted by Luca Bertoncello <lu...@lucabert.de>.
"Giampaolo Tomassoni" <g....@libero.it> 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
(lucabert@lucabert.de)
R: R: R: Question about SQL-based AWL
Posted by Giampaolo Tomassoni <g....@libero.it>.
> -----Messaggio originale-----
> Da: Luca Bertoncello [mailto:lucabert@lucabert.de]
>
> "Giampaolo Tomassoni" <g....@libero.it> 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
> (lucabert@lucabert.de)
Re: R: R: Question about SQL-based AWL
Posted by Luca Bertoncello <lu...@lucabert.de>.
"Giampaolo Tomassoni" <g....@libero.it> 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).
Any idea?
Thanks
Luca Bertoncello
(lucabert@lucabert.de)
R: R: Question about SQL-based AWL
Posted by Giampaolo Tomassoni <g....@libero.it>.
> -----Messaggio originale-----
> Da: Luca Bertoncello [mailto:lucabert@lucabert.de]
>
> "Giampaolo Tomassoni" <g....@libero.it> schrieb:
>
> > It is the user in behalf of whom SA is parsing the message.
> >
> > This may mean the user actually receiving the message, but in many
> setups
> > (like, in example, amavisd-new) this is the user running the milter
> > software. You are probably running SA as the "nobody" user.
>
> Now the other question: why does SpamAssassin use the user
> configuration for
> the Black-/Whitelists and not for the AutoWhitelist?
What is your milter? What is your setup? This may influence stuff like
Back'n'Whitelists as well as autowhitelist.
Giampaolo
>
> Thanks
> Luca Bertoncello
> (lucabert@lucabert.de)
Re: R: Question about SQL-based AWL
Posted by Luca Bertoncello <lu...@lucabert.de>.
"Giampaolo Tomassoni" <g....@libero.it> schrieb:
> It is the user in behalf of whom SA is parsing the message.
>
> This may mean the user actually receiving the message, but in many setups
> (like, in example, amavisd-new) this is the user running the milter
> software. You are probably running SA as the "nobody" user.
Now the other question: why does SpamAssassin use the user configuration for
the Black-/Whitelists and not for the AutoWhitelist?
Thanks
Luca Bertoncello
(lucabert@lucabert.de)
R: Question about SQL-based AWL
Posted by Giampaolo Tomassoni <g....@libero.it>.
> -----Messaggio originale-----
> Da: Luca Bertoncello [mailto:lucabert@lucabert.de]
>
> Hi, list!
>
> I use SpamAssassin 3.2.2 and I configured it to use a MySQL-DB to
> manage the
> Bayes and the AWL.
>
> So, I created the table awl after the documentation, and I write all
> the data
> in local.cf.
> All runs perfectly!
>
> Now the question: in the table awl I have a field username, but this is
> always nobody.
> I tought, it is the user that receive the E-Mails, but it doesn't seems
> so.
>
> Can someone explain me, what does this field do?
It is the user in behalf of whom SA is parsing the message.
This may mean the user actually receiving the message, but in many setups
(like, in example, amavisd-new) this is the user running the milter
software. You are probably running SA as the "nobody" user.
Giampaolo
>
> Thanks a lot
> Luca Bertoncello
> (lucabert@lucabert.de)