mpaperno
commented
6 years ago Not sure what to tell you here. I'd try a newer spampd version since there have been some good changes in terms of root access, daemonizing, and ability to set SA's home directory. Also there's only one v2.30 that I'm aware of (that I've published, anyway, there are other distros too).
Ultimately there must be some reason for skipping tests. Perhaps the debug "spew" at startup could provide a clue (compared to say running SA directly with --debug option). If anyone discovers it is caused by something spampd can fix, please reopen this issue. Since there have been no further "me toos" on this issue, I'm assuming some (relatively) isolated cause.
Hi,
I’ve noticed that a lot of spam gets past spampd that spamassassin itself classifies as spam if run from the command line.
I’m trying to understand why, after all one is just a shell for the other.
Looking at the startup I see massive differences between the debug log of spamassassin when started through spampd and when running spamassassin directly.
On my Ubuntu 14.04 install, spampd is run as an old school sysv init, dated from 2005.
On starting (service spampd start) it calls spamassassin and spews a log.
If I run Sudo -u vmail HOME=/var/cache/spampd spamassassin -D -t < some_message
Where vmail is permissively equivalent to user spampd, I am able to well classify some_message as spam. That same message when received through spampd is not classified as spam (scores of 3.5 vs 10+)
The first difference I see is that spampd is able to read and write /root/.spamassassin, even though the user spampd has no permissions to do so. I notice that spamassassin, if able to read and write here, behaves very differently, hence the HOME= in the command line invocation.
So spampd is somehow keeping permissions and running spamassassin before the call to setuid to change to spampd.
Even if I force spampd to run as user spampd by running it thus: sudo -u spampd /usr/sbin/spampd --tagall --port=10025 --host=127.0.0.1 --relayport=10026 --relayhost=127.0.0.1 --pid=/var/run/spampd.pid --children=3 --user=spampd --group=spampd --logsock=unix --maxsize=10240 --log-rules-hit --debug
Then it still behaves differently. This time, according to the startup log, it reads exactly the same config files but now omits entire swathes of tests.
The conclusion is that spampd is very sensitive to the invocation method, keeping state from before it’s invocation including being able to read and write files that are not permitted to it’s non privileged user.
I notice that there are two different spampd v 2.30, one from 2005 and the other from 2012, the two files are very different, however the above behaviour is the same with both versions.
I know this is not your issue, but my config has the allow_user_rules=0 set, so spamassassin should not be reading config from /root/.spamassassin even if it is permitted, though this is a separate issue for the spamassassin dev.
So, any clues how to get spampd to classify the spam as spamassassin does?