Thanks for the info, it solved my problem. As it turns out, the important change was the DROPPRIVS=yes - adding this caused procmail to apply the user's environement and privileges to the rest of the procmail script, and all of a sudden SA started running as the correct user. I didn't need to add the -u flag.
What *did* happen as a result, though, was that while the user_prefs started working correctly, procmail stopped dumping to the correct mbox file. the last line of my procmail script: mail/SPAM worked fine when run from the user directory, the spam got correctly placed. However, when run system wide, since procmail's current directory wasn't the homedir, it didn't work. I had to add the following two lines: MAILDIR=$HOME/mail (added to the beginning of the procmail script) $MAILDIR/SPAM (as a replacement for the mail/SPAM line at the end) Ok, I could have done it in a single line, but I decided to be neat and tidy about it :) Anyways, that fixed the problem and now all is running well. Thanks again! regards, Paul ----- Original Message ----- From: "Kris Deugau" <[EMAIL PROTECTED]> To: "Paul Fielding" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, January 14, 2004 3:52 PM Subject: Re: [SAtalk] SA runs as root instead of user in sitewide config > Paul Fielding wrote: > > From what I've been able to determine, I *think* what's happening is > > that when procmail is running via the user rc file, SA is being run > > as the proper user and the proper user SA prefs are being called. > > However, when I use the sitewide rc file, SA seems to be being called > > as root, and root's user SA prefs are being called instead. Any > > suggestions? > > Try making the following changes for /etc/procmailrc: > > ---------------- > # This is generally a GoodThing(TM) anyway, unless you MUST run > # sections of /etc/procmailrc as root... > DROPPRIVS=yes > > # send mail through SpamAssassin > :0 fw > * < 256000 > # *** This is the semi-critical bit; I don't know if $LOGNAME is set > # correctly when procmail starts processing recipes from > # /etc/procmailrc. > # Change this: > # | /usr/bin/spamc -f > # to this: > | /usr/bin/spamc -f -u $LOGNAME > > :0 > *^Subject: \*\*\*\*\*SPAM > mail/SPAM > ---------------- > > > syslog when run as /etc/procmailrc: > [snip] > > Jan 14 02:41:58 hildegard spamd[24780]: Still running as root: > > user not specified with -u, not found, or set to root. Fall back to > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Here's the log fragment telling you exactly *what* is going wrong for > proper per-user spamd/spamc usage. To fix it for certain, you'll > probably have to spend a while reading the man pages for procmail, or > consulting a procmail list- I have no idea whether my suggestions above > will work. > > In the systems I'm adminning here, one has per-user .procmailrc files > (created with default calls to SA when the account is created), and the > other calls SA as a Perl module from the MIMEDefang milter program and I > don't do per-user prefs anyway. > > -kgd > -- > "Sendmail administration is not black magic. There are legitimate > technical reasons why it requires the sacrificing of a live chicken." > - Unknown > ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
