At 10:39 I did a slackpkg upgrade on my mailserver. After that, I noticed a lot of spam slipping through into my mailbox. In the afternoon, Anne phoned and complained about how much spam she was suddenly getting. Well dang. I had been so busy with other issues on my desktops after the upgrade I hadn't bothered paying attention to the mailserver.
I looked in the mail logs.
Jun 28 14:10:30 moshie sm-mta: q5SIAUPO010283: Milter (spamassassin): local socket name /var/run/spamass.sock unsafe Jun 28 14:10:30 moshie sm-mta: q5SIAUPO010283: Milter (spamassassin): to error state
It doesn't like something about the socket file /var/run/spamass.sock, so it refuses to continue. I looked at that file, and it looked okay to me. I did a Google search and got a bunch of entries from 2003 that didn't tell me anything. So maybe the upgrade needs the mail chain restarted. I stopped spamd and spamass-milter, and then sendmail. Deleted the offending file /var/run/spamass.sock. Restarted them. Watched an email come through, and got the same result.
Looked in the logs again and spotted this just after I restarted the spamassassin processes.
Jun 28 14:12:46 moshie sm-mta: NOQUEUE: SYSERR(root): /etc/mail/sendmail.cf: line 1668: Xspamassassin: local socket name /var/run/spamass.sock unsafe: Group writable directory
Aha, so that's the problem. /var/run is group writable. Did it change? I looked in /var/log/packages to see what packages had been upgraded.
cd /var/log/packages ls | grep "Jun 28"
and got this lot
-rw-r--r-- 1 root root 2166 Jun 28 10:38 aaa_base-14.0-i486-2 -rw-r--r-- 1 root root 5021 Jun 28 10:38 grep-2.12-i486-1 -rw-r--r-- 1 root root 69788 Jun 28 10:38 imagemagick-6.7.7_9-i486-1 -rw-r--r-- 1 root root 1287 Jun 28 10:38 pycurl-7.19.0-i486-1 -rw-r--r-- 1 root root 16940 Jun 28 10:38 shadow-184.108.40.206-i486-3 -rw-r--r-- 1 root root 2950 Jun 28 10:38 xz-5.0.4-i486-1
aaa_base looked interesting, so I looked in that file and /var/run is mentioned. I don't know what happened. I extracted the package and looked at doinst.sh. It did not specifically change permissions of /var/run with chmod, but it still could have changed permissions. Perhaps /var/run used to be group writable and the upgrade persuaded some things to start testing more seriously? Perhaps the upgrade did reset /var/run to be group writable? I don't know.
So I changed permissions on /var/run so that group is not writable:
chmod g-w /var/run
then I restarted SpamAssassin and sendmail, and this time there were no errors, and email started to be checked for spam again. Problem solved.
I don't know if this is going to cause a problem for some other bit of software. Time will tell.