[I cross-posted this question to the SA list, and Bart answered there.
Am reposting my reply, with Bart's reply interleaved to this list because
there are some helpful procmail ideas there.]
Bart, thanks for the well thought-out suggestions.
-----Original Message-----
From: Bart Schaefer [mailto:schaefer(_at_)zanshin(_dot_)com]
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.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail