Dealing with large amounts email, especially those generated by busy mailing lists, can be a time-consuming business. Fortunately, a variety of tools exist for automatically organising and dealing with mail.
For many people, sorting mail into folders based on sender, list, or other criteria is an essential part of how they manage mail.
Procmail sits at the tail end of the mail delivery process, and applies the filters before mail is handled by whatever mail client. Typically, procmail is called from the .forward file, or suitable equivilant. Many default mail setups now enable procmail delivery by default, in which case no user setup (other than the .procmailrc file) is needed.
Procmail uses a single file which specifies the filters (or recipies). This is almost always $HOME/.procmailrc.
The standard procmail documentation is quite good. Under tradional UNIX setups, "man procmailrc" and "man procmailex" should give you a give a good understanding of the possibiloities. For our purposes, we show a couple of simple examples.
Conceptually, the procmailrc file is a list of recipes. Each recipe consists of a set of patterns, and an action. Mail is handled by the first recipe that matches, and the appropriate action is taken. If no recipe is matched, the mail is delivered to the location specified by $DEFAULT. It's common to set DEFAULT to a sensible location at the start of the procmailrc file. Recipes either deliver the mail somewhere (to a suitable amilbox, forward to another address, etc). or pass the message on to later procmail recipes. This allows very complex filtering results.
Setting VERBOSE=on and running procmail by hand is very useful for debugging procmail errors.
Recipes start with :0. If using mboxes, or another format which requires locking, use :0: to instruct procmail to create a lockfile, important if multiple copies of procmail will run, which is common under moderate mail loads.
Conditions start with "*", and are regular expressions applied to the headers of the mail message, by default. This behaviour can be changed by suitable flags, but that's not relevant here.
Anything else is an action. If it doesn't start woith a suitable action modified, it's taken as the name of a file to deliver mail to
So, to filter the list email@example.com to a different mailbox, the following recipe will do:
:0: * To:.*firstname.lastname@example.org $HOME/Mail/spam-list
The list email@example.com sets a List-Id, but does strange stuff to the To and From fields, so we filter on List-Id
# All filtered mail is in $HOME/Mail, so set MAILDIR MAILDIR=$HOME/Mail :0: * List-Id:.*weird.spammity.tld weird-list
For an extensive list of examples and ideas for using procmail, the procmail tips page at http://pm-doc.sourceforge.net/pm-tips-body.html is a very useful resource.
GMail handles mail sorting through the use of labels, and the filtering mechanism to mark messages. This is quite a powerful concept, as multiple labels can be applied to a message, enabling quite complex views of you email correspondence.
For mailing lists, it's usually easiest to filter on the from field, so a simple
which marks the messages as with a suitable label (i.e. clug-tech). Note that, if you've disabled the option for the list to deliver copies of your messages back to you, this will not mark your messages. This can easily be solved by extending the filter to detect messages sent to clug-tech as well. This presents a problem as the default action is to combine fields with an implicit AND, but this can be avoided by using the "Has the words" field. So adding
there should do the trick.
A simple search
will then restrict your view to clug-tech messages.
The correct way to do mail filtering in mutt is to leave it up to a mail filter, such as procmail.
The wrong way to do mail filtering is to use the "spam" command to tag messages. This allows you to apply arbitary spam tags, based on the message headers, which can then be filtered on.
spam "From: *firstname.lastname@example.org" "clug"
Will mark each mail from clug-tech with the "clug" tag.
limit ~H clug
will restrict the view to just those messages tagged "clug".
You know that really, really annoying twerp on list <X>. Don't you wish you could just not see his mail messages?
Killfiles are an old Usenet concept, being basically a list of senders to ignore completely. This can easily be emulated by the current mail handling tools.
The simplest approach is simply to deliver to /dev/null. The message disappears, you never see it and everyone is happy.
:0: * From:.*email@example.com* /dev/null
Of, course, sometime the twerp sends you personal queries that can mean money, so maybe you only want to delete messages to the list.
:0: * From:.*firstname.lastname@example.org* * To:.*email@example.com* /dev/null
More complex stuff can be done, by chaining rules together.
Since you can filter on the result of a command inside the procmailrc file, it's fairly easy to setup things so that any address in a sepcific file is ignored - there are several examples on google, but a popular one is:
:0 * ? /bin/fgrep -i -q -f $HOME/.killfile /dev/null
This has obvious weaknesses. It filters on all the headrs, not just from, doesn't consider lists differently, but it can be easily extended for more complex situations, by methods including, adding extra coniditions, using different commands rather than fgrep, or by using this as the start of a procmail recipe chain.
Since procmail can filter on anything in the header, you can also do things like filtering on References to kill a thread that gone wacko, or filtering on the received lines to block whoever's mailing-bombing the list from a open relay.
You can of course create a filter to simply delete the messages from the annoying party, but this is not the gmail way. We want to label these so they can be easily excluded.
Create a label (killfile for example).
Create a filter to apply the label to those you want to ignore. Although the default interface for filter creation doesn't provide an option for including boolean operators, there are ways around this (see Steve McCarthy's create Gmail filters for example). I find it easiest to specify the filter purely in the "Has the words" field.
So, to mark X@junk.tld and Y@bogus.tld as people I wish to ignore, create the filter as
(from: X@junk.tld) OR (from: Y@bogus.tld)
with the action label with killfile. Another possiblity is to specify the filter as
(X@junk.tld OR Y@bogus.tld)
in the From field.
Then, to view the inbox without those entries, simply specify your mail search as:
This can be combined with labelling lists, so that, when viewing list traffic, you don't see messages from the twerp, but if not viewing list traffic, you will, so private communication is still possible.
As already noted, one should use the a mail filter, rather than abuse mutt's spam command, but, for completeness, a description of how to emulate a killfile by abusing spam
spam "From: X@junk.tld" "Killfile"
will label messages from X@junk.tld with the spam tag "Killfile". These can then be filtered out by specifying a suitable limit expression for the folder, such as
limit ! ~H Killfile
which limits the folder those those messages which do not have the tag Killfile.
You can also use delete-pattern to remove the messages permenantly.