procmail
[Top] [All Lists]

Re: what directory to put a server-wide .procmailrc file

2005-07-21 09:00:05
Please don't ask questions using the subject line.  That question isn't 
posed in the body anywhere...

0.

See 'man procmail'

/etc/procmailrc (file)

or sometimes (depending on your system)

/usr/local/etc/procmailrc

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'

INCLUDERC

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 
interface).

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/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>