Re: Organizing

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.