At 16:20 2002-05-13 -0400, Curtis Maurand did say:
Duh, he said sheepishly. It was in all the docs. That fixed it. Thanks.
Next question. Given the prereq's at the top of the file minus the
logging, is that a good start for a system wide procmailrc file?
No.
SHELL=/bin/sh
Okay in an /etc/procmailrc, since some users might not have shell logins.
MAILDIR=${HOME}/mail
Hmm, what if the user doesn't have a mail dir like this? The script should
check. The accepted approach from an /etc/procmailrc, wouldn't be to
deliver to a mailbox on the users's behalf, but either to add a header
identifying a message as suspect spam, or, when you're positive of spam or
virus conditions, to discard (or file where root can access it), rather
than delivering it for the recipient.
LOGFILE=${MAILDIR}/procmail.log
You're logging on behalf of the user. What if they don't want this?
LOG="---Logging ${LOGFILE} for ${LOGNAME}
"
Putting the logfile name INTO the logfile for each message, seems kind of
useless. In fact, putting the user's name into a USER-SPECIFIC logfile
seems useless as well.
VERBOSE=yes
Suitable for debugging, but way uncool for high volume mail. Esp if the
poor sucker user gets stuffed with the disk quota.
If you're doing things as if you're the user (putting files in their dirs
sort of qualifies in general, unless you have some other plan), you should
use DROPPRIVS in /etc/procmailrc (see 'man procmailrc')
As for the two junkmail rules you had, I'm afraid they're a bit
broad. Nobody goes to Reno, Vegas, or Atlantic City? Nobody possibly
deals with Proctor & Gamble? You realize that "gambling" won't get tagged
in the subject?
If you develop some complex rules covering a variety of spams, you might
rather stuff a header into the messages, from which users can easily filter
on within their email client or local .procmailrc.
If you check the archives, some time back I presented a method which people
could use to have "configs" which an /etc/procmailrc could use to run
per-user options in the global RC, allowing users to opt in and out of
having you filter or ditch their email:
/etc/procmailrcs/user_options.dat:
userlogname SPAMHEADER
otheruser SPAMTOSS OTHEROPTION
# get options line
FILTER_OPTIONS=`grep "^$LOGNAME " /etc/procmailrcs/user_options.dat`
:0
* some identifying contition(s)
{
# file into a mailbox you can review and periodically trash, or
# just send it straight to /dev/null
:0:
* FILTER_OPTIONS ?? [ ]SPAMTOSS\>
/var/spamarchive/spewtum.mbx
# Alternatley, add a header
:0f
* FILTER_OPTIONS ?? [ ]SPAMHEADER\>
| formail -I "X-Spam-Status: true"
}
If instead, you had a variety of conditions, you could set a flag:
NL="
"
:0
* some condition
{
LOG="SPAM: some condition$NL"
SPAM=1
}
:0E
* some OTHER condition
{
LOG="SPAM: some other condition$NL"
SPAM=1
}
(etc)
:0
* SPAM ?? 1
{
# file into a mailbox you can review and periodically trash, or
# just send it straight to /dev/null
:0:
* FILTER_OPTIONS ?? [ ]SPAMTOSS\>
/var/spamarchive/spewtum.mbx
# Alternatley, add a header
:0f
* FILTER_OPTIONS ?? [ ]SPAMHEADER\>
| formail -I "X-Spam-Status: true"
}
This would allow you to streamline the handling of the spam (or whatever)
confitions. Actions taken in the /etc/procmailrc should probably be logged
to an administrative logfile, not to individual users'. With this in
place, you could still reveiew how much mail would have been identified as
spam, even if those individual users opted to NOT use the spam filters.
Common spam checks could be in an included rcfile:
:0
* FILTER_OPTIONS ?? [ ](SPAMHEADER|SPAMTOSS)\>
{
INCLUDERC=/etc/procmailrc/spam.rc
}
In this way, only those users electing to have spam manhandled will
actually invoke any procmail code to do so. You could run all the checks
within the brace instead of as an includerc. or, you could include the
rules, but have the handlers external to that rcfile (thus, users could
include the global spam.rc into their own .procmailrcs, but only to _ID_
spam, not to actually dispense of it).
There are a variety of other approaches.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail