MH: slocal: .maildelivery etc

MH ...: .maildelivery etc

The .maildelivery file is a little like a poor man's .procmailrc.

Addison-Wesley book: The Procmail Companion

Pearson Education - The Procmail Companion

You can order an "on demand" paper copy of this book [UK Link], [Link for Germany].

I owe a paper copy of this book (I got mine through Amazon), and I would love to have a PDF available.

Yes, of course, there are a few manual pages for procmail etc., but this book still makes sense.

procmail regular expressions matching e-mail subjects: sometimes blanks are not blanks

• I had written a specific procmail rule a while ago,
• it had worked for quite a while,
• for quite some while now it had not worked as expected;
• I had a look at the header lines as displayed by my e-mail reader,
• I also had a look at my procmail LOGFILE;
• the subject line looked rather differently,
• all the blanks were rather '_', i.e. underscore characters, that's because the subject wasn't in 7-bit ASCII but rather in UTF-8;
• for readability I now match this by the '.' wild card, I think, that's good enough.

procmail rules: changing somebody's status from A to junk

And blacklisted one "all" my phones as well.
This time it should last for a while.

Google Mail: from forwarding to active polling

I really liked their feature, that I can forward the incoming e-mail to my Google Mail account (and the Google Mail / Google Apps one as well) to my main e-mail account.
But they poke the "Return-Path:" mail header field then, and that makes it unreasonable for use with procmail.
So for the time being I switched them from forwarding to getting polled by fetchmail with SMTP-ing to my standard account.
The new problem to face then: My mobile phone Internet Access does not allow me to do IMAP and SMTP, and most corporate networks just as well. So maybe I let my own server in my home office do this. The downside of that: sometimes messages do not get successfully sent out, and I will never notice them, if that occurs on my (home office) server. In my experience that only occurs to messages with weird sender addresses and so forth – but you never really know that.
Well, we shall see! More valuable experiences to make.

my procmail rules: sourceforge now also comes as sourceforge.com, not just only sourceforge.net

And that makes me change my procmail rules yet another time.
Not that I ever hoped, this would ever end.

writing procmail rules querying Return-Path

I prefer writing procmail rules querying Return-Path instead of From.

The Return-Path header field gets faked rather rarely as opposed to the From header field, it's far more often machine generated, that's why I regard it more reliable.

Today I found myself in a situation, where the Return-Path header field looked differently after my usual fetchmail+procmail execution chain. I didn't recognize that from the beginning. I tried hard for a couple of hours matching the "original" Return-Path, but I did not succeed. Only after I recognized the difference and turned my interest towards the "new" Return-Path, I immediately succeeded creating another nice procmail rule for that message resp. for messages from that sender.

I still cannot explain myself, why and how Return-Path gets changed, but now I know and respect it does.

observing the procmail LOGFILE

I am a fervent user of procmail, have been such a user, since I found out, that sieve is far less available in any such mail environment as mine at my provider's site.

I really don't know of a lot of others, that also use procmail. I think, Axel uses procmail as well, I worked with Axel like almost 15 years ago at ERNO. I only found out, that "Sven G." (a rather prominent open source person living in Berlin) also uses procmail, when we had a pasta evening together in my kitchen last Friday.

Observing procmail LOGFILE is my way of finding out about new e-mail messages, that try to reach me. I think, usually people have a look at their single mailbox (in case they are POP3 users) or at their 5 IMAP folders (just guessing that "5"). I have like 50 IMAP folders, and because I quite often toggle the "READ flag" of messages back to "unread", observing procmail LOGFILE and also keeping separate track of important messages in my diary is my way of attempting not to lose track.

Now why did I start this article today? Sven G. is a "procmail LOGFILE observer", too. And by "observer" I mean using "tail -f" on that logfile – IYKWIM. I just remembered that and Sven G., when I restarted that command line yet once again, and that raised a smile in my heart, that I enjoyed.

how to test procmail rules?

This may sound utterly silly, but within all these years, that I have been using procmail, I never came around to find a way of testing procmail rules other than by testing them in production for my incoming e-mail. The problem is, procmail gets called through sendmail and they deliver the messages. If I resend messages, sendmail changes the Return-Path header field, on which my rules are based. All other relevant looking header fields can get tweaked and faked, Return-Path seems alright (???).

I'll try to find out on the procmail list, ie. on http://dir.gmane.org/gmane.mail.procmail .

Update / 2010-12-26:

Setting "VERBOSE=on" within your .procmailrc shows a lot of helpful output.

Yes, a message, that my .procmailrc does not deal with, as I think it should, must get copied to another IMAP folder; from there I copy it back to the IMAP folder, which I direct fetchmail to. I can repeat that endlessly, until I find out what's going on. Maybe that also works somehow with formail, but I haven't figured that out yet.

Email overload? Try Priority Inbox - Official Gmail Blog

Email overload? Try Priority Inbox - Official Gmail Blog

procmail has been around since December 1990. Those, who didn't want to know, needed to suffer for that. Well deserved.

unit tests for my procmailrc

I love adding procmail rules, as getting my incoming e-mail almost perfectly sorted eases my life in such a tremendous way – but sometimes that really frightens me.
I just thought, if I ever get around "to it", I will write unit tests for my procmailrc.

debugging my .procmailrc

It's usually not really big fun, if you find a message like this in your procmail log file: "procmail: Missing action".

Well, I don't yet know of a procmail syntax checker, which is rather a pity, so the debugging is of a dynamic kind.

Just add "VERBOSE=on" in the beginning of your .procmailrc, enjoy the flood of "procmail: No match on ...,", and find your "procmail: Missing action" occasionally in the middle of it. You found the corrupted rule then. The rule in question might actually be a very rarely used one resp. one pretty at the end of your .procmailrc, so it may take a while resp. a couple of incoming mails, until it gets used and shows up.
Once you found and corrected the offender, I am quite sure, you will remove "VERBOSE=on" very quickly.

creating diary entries from procmail LOGFILE entries

Incoming e-mail messages may be worth getting recorded in a diary, of course most of them are not, do you agree?
Quite some times I manually create diary entries from my procmail LOGFILE.
I should have written a script to do that a long time ago. Now I did. That effort was really, really little, but I like the results.

Update / 2010-07-23:
I used to copy the entries from that log to my diary, and then a little later I usually wonder, which ones got already processed and completed. So what was missing, was just a little aid, but it looked difficult so solve for a while.
Today I introduced something new and the entry now looks like this:

23 Jul 2010

        09:56:49 [_] From: abc@def.com;

That's wicked cooled, isn't it? Yes, I know.

a call monitor for the FRITZ!Box, using a gmail address book and an area code directory

The FRITZ!Box family of routers also provide telephony services, actually all my phones go through my 7390. They are built using Linux and Busybox. On its TCP/IP port 1012 it offers event records on all telephony actions. Last Christmas I implemented a ruby script dealing with these event records and the "call threads". Yes, there is even a notion of "call threads". At that time I already decided I wanted to use my gmail address book as the data base for looking up all telephone numbers. Now I completed this task. There is a directory of area codes for Germany ("ONB"). I also make use of that one now: For every caller, whose telephone number is not listed in my gmail address book, I show at least from which area he called. I am rather glad with this software.
Initially I also wanted to make this ruby script an OS X cocoa ruby script with a colorful GUI, maybe to run on my iPhone. I'm not sure, whether I will ever be able to work on this.

Update 2010-07-02:
Having my script running now stably for quite a while, it was time for a new feature – somehow.
I have been using procmail for splitting my incoming e-mail for like 13 years or so now.
The procmail rules obviously derive from the addresses I am expecting e-mail messages from.
In former times I had a plug-in for emacs's BBDB, that created raw procmail rules from my emacs address book.
Now with my new approach it makes sense to generate procmail rules from the gmail address book.
Tonight I was in the mood for an little programming excercise, and I implented this feature rather spontaneously. I like it very much.
Right …, generating procmail rules isn't really a proper task for a call monitor, I do know that.

Update 2011-03-28:
This software now makes use of an XML Gmail address book. If you want to find out more on this issue, filter this blog using the tags shown below!