On Tue, 10 Nov 2015 10:55:38 +0000 Phil Reynolds wrote: > On Tue, 10 Nov 2015 10:45:03 +0000 > Phil Reynolds <p...@tinsleyviaduct.com> wrote: > > > On Mon, 9 Nov 2015 13:23:04 +0000 > > Phil Reynolds <phil-spamassas...@tinsleyviaduct.com> wrote: > > > > > I have recently transferred all of my email system to a new > > > machine, but spamassassin is not yet fully functional. > > > > > > It seems that it is trying to use /var/mail/.spamassassin as a > > > data directory - this is fine, but it does not appear to be > > > correctly set up. > > > > I purged all spamassassin setup and started again, just to prove > > what was going on. There's no real change. I have put syslog output > > generated by spamd at http://paste.debian.net/330559/
: spamd: connection from localhost [127.0.0.1]:47762 to port 783, fd 5 : spamd: setuid to mail succeeded > > and /var/mail/.spamassassin has not been created, but spamd still > > wants to use it. > > It turned out /var/mail had permissions unsuitable... have made it > writable by the mail group now. There are two common ways to use spamd with spamc: 1. with per unix user data/settings. spamd runs as root and the spamd child process drops privileges per email to the unix user running spamc. This allows spamd to access unix home directories without running as root. 2. with global (or virtual user) data/settings spamd starts as root and permanently drops to the unix user specified by the spamd -u argument - typically called "spamd". Any per user data is then for virtual users and the files are own by the unprivileged unix user. You appear to running spamd as (1) but then running spamc with the user "mail". Unless you need spamd to access the home directories of login users, you should be running as (2) starting spamd with -u.
