Please don't ask questions using the subject line. That question isn't
posed in the body anywhere...
See 'man procmail'
or sometimes (depending on your system)
Note that unlike the user .procmailrc file, the global filename isn't
preceeded by a dot.
At 09:29 2005-07-21 -0500, Brian Harrell wrote:
1. If it is possible, is there any special global variables needed to
put at the top of that file?
Nothing special, though ofttimes it is beneficial to set a path and a
shell, since not all local users who may have mail accounts necessarily
have a valid login shell. I preserve the original settings, change the
variables to reflect my global needs (say as necessary for invoking
processes used by the global filters), then restore the original settings
(and unset the variables used to preserve them) when exiting the global
procmailrc, so that the USER procmailrc isn't being handed an environment
which the user doesn't expect.
2. If not possible, how can I "include" or "call" a recipe within my
.procmailrc file so that others on my server can "include" several
spam recipes as needed or opt-out of them as they wish.
See 'man procmailrc'
If you check the archives for this list (see <http://www.procmail.org/> for
a link to a searchable archive), there have been several discussions in the
past for how to facilitate users opting in or out of certain global
features. Checking for a file in the users homedir, using group
memberships (managed by the admin, not users), using a db (user can
manipulate their options via a web form which updates either a
conventional sql or berkley type db, or even writes settings to a simple
flat file), etc. You have to come up with the mechanism to manage those
changes external to procmail, and then simply produce a way for procmail to
check the option for any given $LOGNAME.
While not user-maintained, a list processing front-end I wrote uses a
flat-file to manage per-list filter options, with the listname anchored to
the beginning of the line, and options simply spaced apart on the line
following it. the procmail script invokes grep to retrieve the option line
to a variable, and then uses simple regexps to check for the presence of
individual option strings as they are needed. This is how you could use a
flat-file db, though you'd still need to have some method for the USERS to
update their settings (which is a facility which would have nothing to do
with procmail - unless you wanted to make some convoluted email-based
settings form, but ultimatley, you're best off having a shell or web-based
One word of advice: if you're going to develop something to enable users to
opt in or out of some feature, you should design it such that it can be
expanded to handle MULTIPLE options, not just one. That way, it can grow
with your needs.
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 homepage: http://www.procmail.org/