At 14:46 2002-10-03 -0600, LuKreme did say:
I have a /etc/procmailrc that runs al incoming mail through some virus
filters and spamassassin. I have a user account that does not want the
mail run through the spamassassin script (don't ask me).
Don't blame someone for wanting more control over their OWN email.
Is there a way to exclude that account from /etc/procmailrc?
I use /etc/procmailrc to INCLUDERC other specific filters. This isn't
critical, but it certainly keeps it tidy.
You could maintain a config file with lines starting with usernames and
grep that:
username option option option
Or, you could make use of unix groups.
# obtain list of groups
GROUPS=`groups $LOGNAME`
#or, via a standalone file
#GROUPS=`grep ^"$LOGNAME " /etc/procmailrc/user_options.dat
# if user is a member of the MAIL_NOSPAM group, subject them to filtering
:0
* GROUPS ?? [ ]MAIL_NOSPAM\>
{
# or, you could roll out your filter here.
INCLUDERC=/etc/procmailrcs/global/nospam.rc
}
# (repeat as necessary for other types of filters)
DROPPRIVS=yes
I use the grep type functionality EXTENSIVELY for a mailing list
preprocessor which I developed for a site on which I am an administrator -
it allows each list to "subscribe" to certain filter options, thus
permitting the filters themselves to be independant of the actual lists
(the filters could care less what list is what - so long as the filter is
enabled or not). The groups functionality would be easier to use for
regular mail accounts (and since in either case, you're running an external
process to obtain the data, it's probably not a real big performance
difference anyway).
An alternative - which fully places the option configuration into the hands
of the user is to have a ~user/.mailopts file from which the options (or,
in your case, exclusion options) are read:
NOTGROUPS=`cat $HOME/.mailopts`
Remember, /etc/procmailrcs is running as whatever user your MTA
is. Frequently, that is root, so the user dir should be fully readable
despite any perms they may have on it. If it REALLY becomes necessary
(though I don't know how it might affect any other /etc/procmailrc handling
you might be doing), you could DROPPRIVS *BEFORE* retrieving the user
options, then /etc/procmailrc becomes a non-privleged global filter, and
assumes the users' identity, in which case it should be able to read the
content of their homedir...
There's a *LOT* of ways to approach something like this - look at the big
picture and think "modular".
---
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