At 12:13 2011-11-09, LuKreme wrote:
I'm thinking about taking a run at organizing, really organizing,
all the procmail recipes for my several email accounts.
I have, needless to say, code that is shared, duplicated, or nearly
duplicated across my 4 primary accounts,a bout a half-dozen
secondary accounts, and then a portion of that code is shared over
to most of the user accounts on the system.
Before I got started, I wanted some recommendations on how, exactly
to go about this.
If you're dealing with multiple HOSTS (versus multiple accounts on
ONE HOST), set up a script to invoke rsync to synchronize from your
"primary" host out to the others, using a "shared" or "common"
procmail scripts folder. Local differences can be maintained in
hostnamed folders.
You could for instance have the ~/.procmailrc INCLUDERC something
using the username or the hostname as a filename base - then you
could maintain a master copy of everything on the primary host, and
synchronize it ALL to the other hosts without having to fret over
something getting overwritten. Wherever you need to include
something that is host specific, use the hostname as part of the filename.
* hand off processing to .procmailrc if user has one, otherwise
process for spam
Ah, you're talking about a global procmail configuration you're
trying to synchronize. Same basic advice as above, but obviously
tweaked to the global folder.
In .procmailrc
call external basicrc file for all users to process list messages, +
addressing, and set default delivery locations (like .$ARG/ or .SPAM/)
Is there a reason you don't do this in the global procmailrc, after DROPPRIVS?
There are no doubt things in your global config which some users
might want to opt out of. I've posted in the past about using group
membership as a method of opting users in and out of certain global
filters (though that's managed from an administrator POV, not a user
one). You could instead have a webform which the users log into and
that turns things on and off - just make a script/program that checks
the datafile (or actual db) that the form sets the changes into.
---
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