Last week, we looked at an initial procmail setup with a very basic ~/.procmail/procmail.rc file. This file configured our variables, filtered out duplicate messages, created a by-month dated mailbox archive of all incoming e-mails, and then began filtering mails by calling two other files of recipes: ~/.procmail/deletes.rc and ~/.procmail/mailinglists.rc.

Finally, mail was delivered to one of two Inbox mailboxes depending on who the mail was addressed to.

This week, we’ll examine some recipes in the deletes.rc and mailinglists.rc files. These files get included by procmail at the point they are noted in the procmail.rc file as such:

INCLUDERC=$PMDIR/deletes.rc
INCLUDERC=$PMDIR/mailinglists.rc

The deletes.rc file would be used to filter out unwanted mails; be it bounced e-mails, spam, or anything else you don’t want to end up in a legitimate mailbox. Ordinarily, those mails would be sent to /dev/null and deleted completely, but until you are confident with your procmail setup, it would be advisable to filter them to a mailbox specifically for the purpose of deletion, something like ~/Mail/2delete.

An example deletes.rc might look like:

# delete stuff the server marks as spam outright
:0
* ^Subject:.*[--SPAM--]
$MAIL/2delete

For many, this might be sufficient. For others, if you send mail to various mailing lists from a particular address and experience a lot of bounce or failed delivery notifications, you can get rid of them as well. This will take time to build a rule-set to cover everything as different MTA’s report failures differently. Assume mail was being sent out from noreply@foo.org, you could have recipes as follows:

:0
* ^FROM_MAILER
* ^TO_.*noreply.*@foo.org
$MAIL/2delete

:0
* ^TO_.*noreply@foo.org
* ^Subject:.*Undeliver(ed Mail|able).*
$MAIL/2delete

:0
* ^TO_.*noreply@foo.org
* ^Subject:.*Returned mail.*
$MAIL/2delete

:0
* ^TO_.*noreply@foo.org
* ^Subject:.*DELIVERY FAIL(URE|ED).*
$MAIL/2delete

:0
* ^TO_.*noreply@foo.org
* ^Subject:.*Delivery Status Notification.*
$MAIL/2delete

The permutations of failure and bounce notifications are endless. In the above, all mail sent to noreply@foo.org from a MAILER-DAEMON account (as noted by ^FROM_MAILER) is dumped. After that, filtering is done based on subject lines.

The second file of recipes, ~/.procmail/mailinglists.rc, is used to filter email from mailing lists to corresponding mailboxes. Typically, filtering on the Return-Path header works best for mailing lists; however, it depends on the mailing list software used for any given mailing list.

Here are a few examples:

<code>
:0
* ^Return-Path:.*dev-bounces@annvix.org
$MAIL/avx-dev

:0
* ^Return-Path:.*users-bounces@annvix.org
$MAIL/avx-users

:0
* ^Return-Path:.*security-announce-owner@mandrivalinux.org
$MAIL/mdv-security-announce
</code>

The examples are quite self-explanatory and very simple. They simply are filters based on the Return-Path header; if a match is found, the destination mailbox noted (such as $MAIL/avx-dev) is the delivery location.

Throughout these examples, you’ll have noted that each recipe starts with the :0 identifier. After this identifier, you can indicate various flags, such as c for making a cloned copy of the e-mail and then proceeding with other recipes to deliver the original e-mail. You can also use h to simply feed the headers of an e-mail to procmail instead of both headers and the message body. The man procmailrc will give you more information than you probably want on the syntax and options of recipes, while man procmailex will give a number of further examples of procmail recipes.

Delivered each Tuesday, TechRepublic’s Linux and Open Source newsletter provides tips, articles, and other resources to help you hone your Linux skills. Automatically sign up today!