On Tue, 3 Feb 2004, Gary Funck wrote:
> [I posted this to the procmail list, but I think the SA-related, and
> mail admin. related issues are more germane to this list, so am
> re-posting here.]
I got it on both lists, but I'm only replying on sa-users; propagate as
you will.
> 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?
:0:
* $ 9876543210^0 ? test -f $SPAM_TRAP
* $ 1^0 ? touch $SPAM_TRAP && ...
$SPAM_TRAP
You could also assign to UMASK so as to avoid the chmod.
> 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"?
> - 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 ...
> - 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.
> - 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.
