Organizing

headers LuKreme | 10 Nov 2011 06:03

On 09 Nov 2011, at 14:57 , Professional Software Engineering wrote:
> 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.

That’s one thing I am not having to deal with. We just have the one mailserver and that isn’t king to change.

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

Both, really.

>> 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?

Because some users will have their own .procmailrc files they want to run. Also, I find that the
intersection of people who can grok plus addressing and people who cannot grok a simple .procmailrc is
near enough to nil as makes no difference

> There are no doubt things in your global config which some users might want to opt out of.

The global config doesn’t actually *do* anything. It sets a bunch of variables (CLEANFROM, etc), sets a
header if the message can in on a spoofed local IP, and it backsup the message. Frankly, if users want to
opt-out of the header, they can simply remove it.

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

That’s a good idea.

--

-- 
When the routine bites hard / and ambitions are low And the resentment
rides high / but emotions won't grow And we're changing our ways, /
taking different roads Then love, love will tear us apart again

Re: Organizing