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
smime.p7s
Description: S/MIME cryptographic signature
____________________________________________________________
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