9 Nov 2011 22:57
Professional Software Engineering <PSE-L <at> mail.professional.org>
2011-11-09 21:57:24 GMT
2011-11-09 21:57:24 GMT
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.