Reports of procmail's death are not terribly exaggerated

The mail delivery agent (MDA) procmail is a Linux and Unix mainstay; for years it has been the recommended solution for sorting large volume email and filtering out spam. The trouble is that it is dead, and it has been for close to a decade. Or at least that may be the problem, depending on how you look at it. The question of when (or if) to declare an open source project dead does not have a clear answer, and many people still use procmail to process email on high-capacity systems.

For those unfamiliar with it, MDAs like procmail receive incoming mail from mail transport agents (MTAs) like Sendmail or Postfix, then process the received messages according to user-defined "recipes." Recipes examine the headers and body of messages, and are usually used to sort email to different mailboxes, forward messages to different addresses, and perhaps most importantly, to recognize and dispose of spam — often by triggering an external spam filtering tool like SpamAssassin. Recipes can also modify messages themselves, such as to truncate dangerously long message bodies or abbreviate irritatingly-long recipient lists.

Officially, the last stable procmail release was version 3.22, made in September of 2001. As one might expect, there has never been an official "the project is dead" announcement. Instead, only circumstantial evidence exists. Although several of the FTP mirrors include what appear to be development "snapshot" packages as recent as November of 2001, there does not appear to have been any substantial work since that time. The developers' mailing list has hardly seen a non-spam blip since 2003.

A side effect of a project abandoned that long ago is that there was no web-based source code repository at the time, even though such repositories are a fixture today, so only the tarballed releases uploaded to the FTP or HTTP download sites exist for FOSS archaeologists to examine. Similarly, a great many of the links on the official project page, including mailing list archives, external FAQ pages, and download mirrors, have succumbed to link-rot over the years and no longer provide access to useful information for those just getting started.

I'm not dead yet

Despite all this, procmail still has a loyal following. The procmail users' mailing list is actually quite active, with most of the traffic focusing on helping administrators maintain procmail installations and write or debug recipes. Reportedly, many of today's current procmail users are Internet service providers (ISPs), who naturally have an interest in maintaining their existing mail delivery tool set.

procmail's defenders usually cite its small size and its steady reliability as reasons not to abandon the package. A discussion popped up on the openSUSE mailing list in mid-November about whether or not the distribution should stop packaging procmail; Stefan Seyfried replied by saying that rather than dying ten years ago, the program was "finished" ten years ago:

In a similar vein, when Robert Holtzman asked on the procmail users' list whether or not the project was abandoned, Christopher L. Barnard replied "It works, so why mess with it? It does what in needs, no more development is needed..."

But there are risks inherent in running abandonware, even if it was of stellar quality at the last major release. First and foremost are unfixed security flaws. Mitre.org lists two vulnerabilities affecting procmail since 2001: CVE-2002-2034, which allows remote attackers to bypass the filter and execute arbitrary code by way of specially-crafted MIME attachments, and CVE-2006-5449, which uses a procmail exploit to gain access to the Horde application framework. In addition, of course, there are other bugs that remain unfixed. Matthew G. Saroff pointed out one long-standing bug, and the procmail site itself lists a dozen or so known bugs as of 2001.

Just as importantly, the email landscape and the system administration marketplace have not stood still since 2001, either. Ed Blackman noted that procmail cannot correctly handle MIME headers adhering to RFC 2047 (which include non-ASCII text), despite the fact that RFC 2047 dates back to 1996. RFC 2047-formatted headers are far from mandatory, but they do continue to rise in frequency.

Bart Schaefer notes that every now and then, someone floats the possibility of a new maintainer stepping up — but no one ever actually does so. Regardless of the theoretical questions about whether there are unfixed bugs, surely that practical reality provides the answer no one can arrive at by other logic: if no one works on the code, and no one is willing to work on the code, then surely it can be called abandoned.

What's a simple procmail veteran to do?

The most often-recommended replacement for procmail is Maildrop, an application developed by the Courier MTA project. Like procmail, Maildrop reads incoming mail on standard input and is intended to be called by the MTA, not run directly. It also requires the user to write message filters in a regular-expression-like language, but it reportedly uses an easier-to-read (and thus, easier-to-write) syntax.

The project also advertises several feature and security improvements over procmail, such as copying large messages to a temporary file before filtering them, as opposed to loading them into memory. Maildrop can also deliver messages to maildir mailboxes as well as to mbox mailboxes; procmail natively supports just mbox, although it can be patched (as distributions seem to have done) or use an external program to deliver to maildir mailboxes.

The merits of the competing filter-writing syntaxes are a bit subjective, but it is easy to see that procmail's recipe syntax is more terse, using non-alphabetic characters and absolute positioning in place of keywords like "if" and "to." For example, the Maildrop documentation provides some simple filter rules, such as this filter that is triggered by the sender address boss@domain.com and includes the string "project status" somewhere in the Subject line:

    if (/^From: *boss@domain\.com/ \ 
	&& /^Subject:.*[:wbreak:]project status[:wbreak:]/)
    {
	cc "!john"
	to Mail/project
    }

The action enclosed in curly braces routes the message to the Mail/project folder, and forwards a copy of the message to the user "john." An equivalent in procmail's recipe language might look like this instead:

    :0:
    * ^From.*boss@domain\.com
    * ^Subject:.*(project status)
    ${DEFAULT}/project
    ! john@domain.com

The first line specifies that this is a new recipe; the trailing colon tells procmail to lock the mail file, which is necessary when saving the message to disk. The asterisks and exclamation point that begin lines are operators indicating new "conditions" and the forwarding action, respectively — neither is part of a regular expression. As you can see, the Maildrop syntax is not noticeably longer, but it could be easier to mentally parse late at night — particularly if reading filters written by someone else. Regrettably there does not seem to be an active project to automatically convert procmail recipes to Maildrop filters, which means switching between the packages requires revisiting and rewriting the rules.

Maildrop is not the only actively maintained MDA capable of filling in for procmail, although it is the easiest to switch to, by virtue of running as a standard-in process. Dovecot's Local Delivery Agent (LDA) module, for instance, has a plugin that allows administrators to write filtering rules in the Sieve language (RFC 5228). Maildrop has an advantage over LDA, though, in that in addition to Courier, it is also designed to work with the Qmail and Postfix MTAs.

If you are currently running procmail without any trouble, then there is certainly no great need to abandon it and switch to Maildrop or any other competitor. OpenSUSE, for its part, eventually concluded that there was no reason to stop packaging procmail, for the very reasons outlined above: it works, and people are still using it. However, ten years is a worryingly long time to go without an update. The simple fact that there are only two CVEs related to procmail since its last release is in no way a guarantee that it is exploit- or remote-exploit-free. At the very least, if your mail server relies on the continued availability of procmail, now is a good time to start examining the alternatives. Lumbering undead projects can do a lot of damage when they trip and fall.