At 17:34 2003-06-03 -0400, Damian Gerow wrote:
I've done a fair bit with procmail in the past, so I'm pretty comfortable
with writing an actual procmailrc. But I've never used a /global/
procmailrc script, and I need one for the project I'm currently working
on. A quick Google search didn't turn anything up, so I thought I'd ask
here.
I suggest you 'google' on '/etc/procmailrc'
Basically, how does a global procmailrc work?
The same way a per-user one does, but there are some gotchas:
* /etc/procmailrc is invoked with root privs, which are dropped
when procmail switches to ~/.procmailrc, or if you explicitly
use DROPPRIVS (allowing you to have something in /etc/procmailrc
which is executed as the user), though you cannot regain privs
once you've dropped them.
I force a DROPPRIVS=YES at the end of my /etc/procmailrc anyway
because it avoids some extra logging if the user doesn't have a
~/.procmailrc of their own.
* /etc/procmailrc is invoked with the shell of the USER - so if the
user doesn't have a shell defined (or has a restricted shell of some
sort), things won't simply work because it's in /etc/procmailrc. What
I do is save the user shell, force a known shell, then revert to the
saved shell before leaving the /etc/procmailrc:
ORGSHELL=${SHELL}
SHELL/bin/sh
(do your stuff)
SHELL=${ORGSHELL}
ORGSHELL
* it is good practice to undefine anything you define in your
/etc/procmailrc which you wouldn't want the user to have access to
(or which could conceivably make the users procmailrc act differently
than if you didn't have a global procmailrc). See above, where I
undefine SAVEDSHELL.
* Because /etc/procmailrc invokes with root perms, you need to be
especially careful of what you do in that rcfile - THOROUGHLY test
your rcfiles in a sandbox before employing them in /etc/procmailrc.
* Just as 'man procmail' advises, you need to be cautious about
filtering mail and forwarding messages within /etc/procmailrc - if
the account to which you forward them to (or which may in turn forward
to another account) processes through /etc/procmailrc on delivery,
then
you're setting up one NASTY mail loop. Use of X-Loop is imperative.
* Files _created_ during processing of /etc/procmailrc have ownership
appropriate to the user which the process is running as - root if it
has elevated perms, or $LOGNAME if you've used DROPPRIVS.
* you can quickly bail from /etc/procmailrc by using:
SWITCHRC
If I set up a global procmail script, will the per-user scripts still be run?
Yes, after the global procmailrc finishes - presuming that it doesn't
deliver the message.
What if a user has a .forward file in their directory?
That's problematic - the .forward takes precedence over the procmailrc.
Ideally, the users .forward would be run, then if delivery is still local,
the global procmailrc would be used, then the per-user procmailrc.
That might be ideal for you. In my book, 'ideal' would be:
(procmail as LDA, as it should be)
global procmailrc (regardless of whether there is a .forward or not)
forward (if present, to do whatever)
~/.procmailrc (if the forward invoked procmail, or didn't exist)
since this sequence would keep the mail handing in the control of the
admin. Alas, this isn't how things are.
'man procmail' details several commandline options which will affect
whether /etc/procmail is skipped. From memory, this includes:
-f-
-p
-m (rcfile)
(any rcfile)
IOW, if there's a .forward file necessary to invoke procmail (or used in
any event - but once procmail-as-LDA hands the .forward-invoked program -
even if that happens to be procmail - then the procmail-as-LDA is out of
the picture), so long as it doesn't use any of the above arguments,
procmail should run /etc/procmailrc (with root perms) before runnning
~/.procmailrc. If instead, the above args are present, then procmail will
simply run the given rcfile or ~/.procmailrc, as appropriate to the
invocation, without invoking the global rcfile.
(Obviously, if a user has .forward set up to call procmail explicitly with
their local recipes, then the global recipes will not be used.)
Which sort of violates the whole purpose of *ADMIN* controlled global
recipes, doesn't it? Yea, I'm a bit annoyed that .forward allows users to
bypass the global rcfile if they do things a certain way, but then, my
global rcfile is there to protect users from viruses and spam - if they're
dense enough to bypass that, then it's their problem, not mine. This is
probably a larger problem for those admins who use the global rc file to
spy on users (though there are better ways).
If you want users to opt-out of your global procmailrc (or parts of it),
you can have the global procmailrc use any of a number of methods to check
for the users preference. They could be a member of a group (say, for
admin-control of what a user is included in, say group "spamfilt", though
this reveals info to other users on that host):
GROUPS=`groups $LOGNAME`
# if user is a member of the spamfilt group, subject them to filtering
:0
* GROUPS ?? [ ]spamfilt\>
{
LOG="perform spam filtering for $LOGNAME$NL"
# do your stuff
}
Or, they can have a file in their home directory, which the global rcfile
can check for the existance of (or of specific contents):
OPTIONS=`cat $HOME/.mail_options`
:0
* OPTIONS ?? [ ]someoptions\>
{
LOG="$LOGNAME has some option enabled$NL"
# do your stuff
}
There are other options - you could run a program to query a database for
the settings of the individual user, through which the user could set their
options via a web interface (i.e. absolutely no shell knowledge necessary
for Joe Clueless User).
We're using sendmail 8.12, and would be using procmail as the LDA, so
per-user .forward's wouldn't be required.
They're not _required_ to invoke procmail (since it is the LDA, and
therefore invoked by the MTA), but users can still have .forward files,
which can throw a wrench into things, as described above.
---
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