Bart, thanks for the well thought-out suggestions. > -----Original Message----- > From: Bart Schaefer [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 03, 2004 9:24 AM [...] > > > LOCKFILE=${SPAM_TRAP}$LOCKEXT > > :0 Wc > > * $ ! ? test -f $SPAM_TRAP > > | touch $SPAM_TRAP && chown ${LOGNAME}.mail $SPAM_TRAP && chmod > 640 $SPAM_TRAP > > > > :0 > > $SPAM_TRAP > > LOCKFILE # release lock > > Why run the 'touch' as a pipe? >
An evolutionary artifact. I didn't have that touch/chown/chmod stuff in at first, and then when I added it later, didn't think of your simpler solution ... > :0: > * $ 9876543210^0 ? test -f $SPAM_TRAP > * $ 1^0 ? touch $SPAM_TRAP && ... > $SPAM_TRAP > Looks good. I'm a little iffy on how the chain of touch, chmod, chown might set the status codes, but have that problem in my formulation. This might come up for example, the intended recipient is 'root' and the script is being run by 'root'. Thus the chown is redundant. I'm sure there's ways to work around that, with a little research. > You could also assign to UMASK so as to avoid the chmod. > Yup. thanks. > > Questions: > > > > - if the delivery part of this recipe were changed simply to: > > > > :0: > > $SPAM_TRAP > > > > can I depend upon procmail to create that file with the recipient as > > owner of the file? > > Not if you haven't dropped privileges, no. > > > (the containing directory is owner=root,group=mail and is writeable only > > by owner/group and rx everyone). > > If you want to continue using a systemwide directory like that, then > you'll have to continue with the chmod. > > > Or would procmail create it on behalf of the current user, which is root > > (or mail)? > > Yes. > > > - in this section of the recipe: > > > > # > > # Invoke spamasassin to check for spam. > > # > > :0 fw:$SA_LOCK > > * $ ? test -x $SA > > | su $LOGNAME -c "$SA" > > > > I wanted to make sure that spamassassin is run under the user-id of > > the recipient > > Is there a reason you aren't running spamd and using "spamc -u $LOGNAME"? > Yes. this prototype was developed just to test for a single user, and it was easier just to run SA directly for now. Spamc/spamd would be in the production set up. Your point that spamc will switch users without the need for an explicit 'su' is well-taken, however. > > - The bigger question I have is: Is keeping the logs, the virus mail, > > the almost-certain spam mail in a global location worth the fuss? > > Ordinarily I wouldn't think so, but it probably made your periodic cleanup > scripts simpler, so ... > Possibly, if mail filtering were done on a mail server, and mail delivery done at one/more separate hosts. In this case, the scavenger scripts could just as likely cruise the users' home directories. > > - I'm concerned that the users may have some trouble navigating the spam > > folder in /var/spam_trap/$LOGNAME, and may even require a link from > > their home directory back to the spam_trap folder to easily access it > > from their mail client application. > > This is probable. > Yeah, I'm waiting for feedback on that point. > > - A downside to using this /etc/procmailrc approach is that some > > decisions are being made for the user: where to put the virus mail, > > almost-certain spam, marginal spam, and logs. If the user had their own > > filtering/filing rules for spam (one user did, but won't mind the > > change), they've just been pre-empted by the sitewide procmailrc. > > A technique that's been suggested before on the procmail list is to test > for the presence of a $HOME/.procmailrc file and only do the global > processing if the user doesn't have one. > Might be a good way to go, thanks.
