SpamAssassin has, for the most part, worked wonderfully in keeping spam out of the users' mailboxes for three mail domains that I use it on. I collect all spam into one "spam" mailbox, and someone reviews that mailbox regularly to fish out any (these days almost non-existant) false positives.
Having read much of the documentation before installation and during the "testing" phase, I assumed that Bayes, auto-whitelist, and any other "intelligence" features would automatically be used when their respective databases became sufficiently large. But after many months of lots of mail usage they never began to be used. Until recently I simply let it slide because other projects demanded more attention and it was "good enough" as it was.
I accomplished my work from procmail with the following recipes:
:0fw: spamassassin.lock * < 256000 | spamc
:0: * ^X-Spam-Status: Yes.* /var/spool/mail/spam
The lockfile is uneccessary, I think, but I use it to keep the log messages in /var/log/maillog in a one-mail-at-a-time order.
The problem that I had with the auto-features not ever being used was because spamc was being called as root, and thus spamc would run as user "nobody" and wouldn't have access permissions to /root/.spamassassin. Furthermore, having spamc run always as the same user would have made per-user databases and preferences impossible, since they would only be useful for that one user. (This may be desireable in some environments where the mail habits are quite similar between users, where users change frequently, or where system user accounts per-user do not actually exist.)
The "common" solution to this is usually to add DROPPRIVS=yes to the procmail script prior to the spamc recipe. However, this would have made the /var/spool/mail/spam file require full access mode for all users, and I didn't want this - especially because I "logrotate" that file every week and wouldn't easily be able to control the creation of that file.
The trick for me was to do 'spamc -u $LOGNAME' instead of just 'spamc' which causes spamc to be called as the recipient's user account instead of root, but doesn't stop procmail from using root privileges to dump spam into /var/spool/mail/spam.
The spamc manpage states that the -u option is somewhat deprecated. Well, call it what you wish, but it certainly is a useful feature, and I hope it never gets removed.
Thanks.
Lee.
------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
