Procmail and RCS

A few quick notes on using procmail and RCS together.


Always ensure the directory contains an RCS directory for RCS to store its data. Only two commands are really needed:

rcsdiff -u .procmailrc
ci -l .procmailrc

The former shows a unified diff of the changes. The latter checks in the current changes and immediately relocks the file (thus ensuring a copy always exists for procmail and for editing on the disc. rlog is useful for dumping the revision history if you don’t use $Log to embed the history in the version-controlled file itself.


It’s a good idea to put your rules in the following order:

That helps minimise the amount of processing needed.


I set up my logfile in .procmailrc as follows:

LOGFILE=$HOME/logs/procmail.`date +%Y%m`.log

That ensures a separate logfile is generated for each month and that the ordering is safe. To compress those logs at the start of the following month, I have this in my crontab:

0 0 1 * * for i in `ls $HOME/logs/procmail.*.log | sort -r | tail -n +2`; do gzip $i; done

The loop is there just in case nothing needs compressing. However, there’ll usually only be the one logfile to compress.

Duplicate filtering

This rule uses formail to remove emails that have a message-id that has already passed through the system. It keeps an 8K log. “W” waits until it gets the exit code from formail and filters if appropriate. the ‘h’ means pipe the headers only. it uses a user-defined lockfile for this task.

:0 Wh: msgid.lock
| /usr/bin/formail -D 8192 $HOME/.msgid.cache

TNEF attachments

Dealing with people who wouldn’t know a grown-up mail server and mail agent if it hit them in the face? ytnef to the rescue!

* ^X-MS-TNEF-Correlator
    :0 fw B
    * winmail.dat
    | /usr/bin/ytnef-filter


to do


Created at 15:14 UTC on May 22nd, 2012 and last modified at 16:11 UTC on May 22nd, 2012