The other solution to this problem is to use the $LOGNAME variable that's set by procmail to be the local recipient. So, when you call spamc, include the -u option followed by $LOGNAME (-u $LOGNAME) and spamc calls spamd as the final recipient, allowing spamd to read their local user_prefs.
This doesn't contradict the need for spamc/spamd to handle this itself, but it's another solution to the issue. On Tue, 24 Sep 2002, Cheryl L. Southard wrote: > However, I still think that spamd should be able to setuid to the > user by itself. According to the man page for spamd: > -u username, --username=username > Run as the named user. The alternative, default > behaviour is to setuid() to the user running "spamc", if > "spamd" is running as root. > So the default behavior should be to setuid to the user receiving the e-mail. > > And when I change my /etc/procmailrc file to use "spamassassin -P" instead > of spamc, then it works fine and uses my user_prefs file. I guess > something is strange with spamc/spamd. -- Public key #7BBC68D9 at | Shane Williams http://pgp.mit.edu/ | Systems Administrator UT-GSLIS =----------------------------------+------------------------------- All syllogisms contain three lines | [EMAIL PROTECTED] Therefore this is not a syllogism | www.gslis.utexas.edu/~shanew ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
