Discussion about the Procmail mail delivery agent

Professional Software Engineering | 9 Nov 2011 22:57

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

(Continue reading)

headers

Bart Schaefer | 10 Nov 2011 05:10

Re: Organizing

On Wed, Nov 9, 2011 at 1:57 PM, Professional Software Engineering
<PSE-L <at> mail.professional.org> 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.

I was going to suggest something similar, except that instead of using
rsync I'd prefer using a source code control system (such as git or
svn) so that you can make changes on different hosts and have them
merged, rather than having to always edit on a primary host.

I do this with my zsh configuration (so far my procmail configuration
has been sufficiently host-specific as to not be worth live-sharing).

>  Wherever you need to include something that is host specific, use the
> hostname as part of the filename.

Equivalently, place the files common to a host in a directory named
for that host.

Processing all the *.rc files in a directory without knowing their
names in advance, can be a little tricky.  One way is to recursively
invoke procmail, but then each rcfile must be able to stand on its
own.  Another way is to manufacture a temporary file in which there
appears an INCLUDERC for each file you want to read, and then
INCLUDERC that temporary file; but then you need to be careful that
the temporary is created with a unique name in a secure location.

(Continue reading)

headers

LuKreme | 10 Nov 2011 06:03

Re: Organizing

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.

(Continue reading)