Software

Filter for unwanted mail and mailing lists with procmail


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!

About

Vincent Danen works on the Red Hat Security Response Team and lives in Canada. He has been writing about and developing on Linux for over 10 years and is a veteran Mac user.

5 comments
Photogenic Memory
Photogenic Memory

I've always wanted to set up my own mail server. The problem is that there are so many types of them like Sendmail, Exchange, ... etc. Anyways, the way you wrote out the rules to dictate the servers' response to unwanted types of mail was totally understandable. Cool! Looks like I'm going to start out with Procmail.

vdanen
vdanen

Unlike Sendmail, Exchange (or my favourite, Exim), Procmail isn't an MTA (Mail Transfer Agent); it's an MDA (Mail Delivery Agent). You can use it in conjunction with any MTA, but it doesn't replace one. I use Exim with SpamAssassin and TMDA on my personal server and use procmail for filtering mailing lists, deleting unwanted messages, etc. Great combo.

Absolutely
Absolutely

Of course, it's the only one I've administered so far, but it also isn't missing anything I think it "should" have, so that isn't such faint praise, really. Very helpful pair of articles, Vincent. Thanks! Can you recommend anything as concise for SpamAssassin? So far, I'm just dumping everything that's not on my 'known-good' list into a 'review' folder with ' [pre]:0 $MAIL/inbox-review[/pre] ' Until I make sure *all* the sender addresses I want to clear are in .procmailrc, I have to spend little extra time reviewing that folder. It's been a couple weeks and I'm almost certain there are no new senders I hear from rarely but still want to keep in my address book, so I'm eager to setup automated SPAM cooking. Thanks again for the excellent articles.

Absolutely
Absolutely

Jaqui: [i] naturally, you have looked at the docs from:[/i] http://spamassassin.apache.org/doc.html I've glanced at online help and man pages, and noticed there is a lot of content, thus my question to Vincent, and intentional use of the word 'concise.' Of course, it's not as verbose as the Exim4 doc, but I had the Debian 3.1 Bible to ease that a heckuva lot; I guess it spoiled me.