Discussion about the Procmail mail delivery agent

LuKreme | 9 Nov 2011 21:13

Organizing

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.

I was considering something along these lines, with * items being things the are already done.

* procmailrc file with basic variable extraction, mail backup

* hand off processing to .procmailrc if user has one, otherwise process for spam

In .procmailrc
call external basicrc file for all users to process list messages, + addressing, and set default delivery
locations (like .$ARG/ or .SPAM/)

process local rc files (~/.procmail/.*rc)

call a deliveryrc file that actually delivers the mail and logs to user’s log file (~/logs/pm.10-11-2011.log)

I figure the deliveryrc and basicrc can be the same file for everyone if I do it right, though I am unsure how to
load arbitrary files in the user’s ~/.procmail/ folder.

Does all of this sound reasonable? Does anyone have any hints (or samples) on something like this? What I
envision is something that is going to be necessarily a lot more complicated than what I am currently
doing, but will end up being more flexible and easier to manage since most files will just be shared between
all users. I may even look into doing something like creating a library of procmail includes that a user

(Continue reading)

headers

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)

headers

Professional Software Engineering | 10 Nov 2011 15:29

Re: Organizing

At 21:03 2011-11-09, LuKreme wrote:
> >> 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.

So?  You can still run the stuff "for all users" in the global 
procmailrc, then fall through to their personal .procmailrc configs.

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