Good day!
You were completely right: after I added '-u debian-spamd' (this user was
automatically created at the time of package installation) to the spamd
start string in the /etc/default/spamassassin AWL started working right as
expected. The database is now filled almost as expected:
*************************** 9. row ***************************
username: m...@mmm.mmm
email: f...@fff.fff
ip: none
count: 1
totscore: 0.179
signedby:
Thank you for your advice!
What bothers me now are the values of the 'ip' and 'signedby' fields: I
don't seem to understand what they are needed for and whether the data that
they contain is of any importance? If there is a link to read, I will be
glad to follow it.
I have a suspicion that IP address will be set as soon as I will start
sending and receiving mail to/from remote hosts that are not on my
'allowed-ips' list. Can you confirm? Unfortunately, I can't test receiving
right now -- I'm on a development environment. But what about the
'signedby' field?
Boris
On 16 January 2016 at 17:36, RW <rwmailli...@googlemail.com> wrote:
> On Sat, 16 Jan 2016 15:07:36 +0300
> ????? ???????? wrote:
>
>
> > No, spamd is running as user "root", so I don't have the "-u" key
> > anywhere in the smapd configs. I'm sorry for not making this clear
> > enough.
> >
> > What I meant to say is that when I send or receive a message through
> > my Exim (on the remote host) it passes the message to the spamd by
> > calling a locally installed (i.e. installed on the same host where
> > Exim is) spamc binary with the following command: "spamc
> > -F /etc/spamc/spamc.conf -u $local_part@$domain". Unfortunately, I am
> > still unable to get this setup working properly with AWL, as username
> > in the AWL table is set to "nobody".
>
>
> Running spamd without -u is intended to support unix account users. In
> this case the spamd child process drops its privileges from root to the
> user running spamc or the user specified by spamc -u. This allows spamd
> to access home directories without running as root. Probably what's
> happening is that as $local_part@$domain isn't a unix user, spamd is
> overriding it with the unix user "nobody" to avoid scanning an email as
> root.
>
> You should be running spamd with "-u spamd" which causes spamd to drop
> its privileges to the unprivileged user spamd after it has bound to
> the default port (it's usually called spamd, but your spamassassin
> package may have created some other user for this purpose). When you do
> this, the user in spamc -u can be treated as a virtual user.
>
>
>
>
