Thus spake Professional Software Engineering
(PSE-L(_at_)mail(_dot_)professional(_dot_)org) [03/06/03 20:43]:
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'
Tried it. Also googled on 'global procmailrc' and
'/usr/local/etc/procmailrc'.
While I could find snippets, I haven't found enough to actually say:
"If procmail is used as the LDA, then when the time comes to do local
delivery, the global procmail file will be run, then the users .forward
file, then the per-user procmailrc."
(I don't even know if that's true or not.)
Basically, how does a global procmailrc work?
The same way a per-user one does, but there are some gotchas:
<snip>
* /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
Good idea... But I think you're missing an '=' on the second line...
* 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.
We will be running at most *two* recipes in the global procmailrc --
undefining things will be relatively simple.
In my googling, the one thing that's been hammered again and again is the
privileges issue.
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.
Thanks -- this is the tidbit that I'm looking for. The global procmailrc
will not be doing delivery -- we leave this up to the user.
What if a user has a .forward file in their directory?
That's problematic - the .forward takes precedence over the procmailrc.
Hmmm... Problematic, but as you said in portions I snipped, if a user
really wants to opt-out of the global procmailrc, they can. However, since
we /do/ use .forwards validly in a number of places, this could cause some
problems. I'll have to set something up to play with this.
So (forgive the basic questions, just trying to make sure I've got this
right) what happens if we have a global procmailrc, and the user has neither
a .forward nor a .procmailrc, and the global procmailrc does *not* do
delivery? My presumption, based on past procmail experience, is that
procmail will deliver the mail itself to /var/mail/$user...
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)
Actually, that is fine for me. Perhaps a better way of phrasing it would
be: "Ideally, procmail would load and run the global script, then pass
things off to the per-user .forward *or* .procmailrc files, I don't care in
which order."
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):
Hmmmm... I hadn't thought of this yet, but definitely a good idea. I'll
file it away, and look at it again once the basic concept is up and running.
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.
Yes, just included to avoid the, "What are you running?" questions.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail