Last night I subscribed to a mailing list, and discovered this morning that my procmail filter didn't apply to many of the mailing list messages. Now I have loads of less-important mailing list messages interspersed with my more-important work emails sitting in my inbox.

Is it possible to rerun all the emails in my inbox through my procmail filters again?

Note: I am using the maildir format

  • 1
    have a look at lists.debian.org/debian-user/2006/06/msg00716.html Commented Jun 29, 2012 at 20:12
  • That presents a partial solution. In this case, some emails would most definitely be routed back into the inbox. It seems like there should already be some *nux solution to this problem that I am just not aware of, instead of writing a script to simulate the existing mail delivery process.
    – Cory Klein
    Commented Jun 29, 2012 at 20:33
  • The problem is procmail only works on mail messages, it does not work on folders, mboxes or anything else - this means you'll have to either simulate the delivery or use something like thunderbird and filter it there. Commented Jun 30, 2012 at 0:24

4 Answers 4


I believe this will work. You need to run formail to reformat the mail and send it back through procmail.

From the Maildir directory:

cat * | formail -s procmail

  • 3
    Does this actually work? Wouldn't it leave all the old messages where they were?
    – cnst
    Commented Feb 26, 2013 at 20:49

you might be able to do it in place, like this:

$ for m in Mail/{cur,new}/*; do echo $m; procmail <$m; rm $m; done

You have to remove each original email afterwards, or else procmail will duplicate it.

It will also record everything as new. I'm not sure of a good way to handle that.

  • This would seem wasteful on disc io: procmail filtering is usually only done based on headers, but such piping will cause the whole message to be read and written to disc all over again. Besides, should procmail run out of memory or encounter some other issue, you still unconditionally remove the file (ouch!), which seems pretty scary, too. I would say that this is a completely unacceptable solution as far as maildir goes.
    – cnst
    Commented Feb 26, 2013 at 20:56
  • 1
    This could be incrementally improved by doing procmail < $m && rm $m instead of procmail < $m ; rm $m so at least the message isn't removed if procmail fails.
    – rrauenza
    Commented Dec 31, 2017 at 7:15
  • Executing rm after ; is extremely unsafe. Why not use && instead? That way, rm will run if and only if procmail processed the message successfully. Commented Apr 13, 2021 at 22:26

If you are using mutt, you can pipe the email through procmail and also delete the original from your inbox with a key command something like this:


macro index y '<enter-command>unset wait_key<enter><tag-prefix><pipe-entry>/usr/bin/procmail /home/user/.procmailrc<enter><tag-prefix><delete-message><enter-command>set wait_key<enter>'

macro pager y '<enter-command>unset wait_key<enter><pipe-entry>/usr/bin/procmail /home/user/.procmailrc<enter><delete-message><enter-command>set wait_key<enter>'

found on https://mikeburnscoder.wordpress.com/2011/06/12/one-big-mutt-inbox-filtered-after-the-fact-using-procmail/


It seems like there is no good solution for this: procmail only seems to accept mail input from stdin, which limits maildir applications.

I faced a similar situation, and the best solution that fit my needs was simply duplicating what I wanted procmail to do, but what it most definitely cannot do, with my own little script, which should be sufficient if you only have one or two simple rules that you need to take care of:

cd ~/Maildir/
sh -c 'for i in `egrep -l "^Delivered-To: [email protected]" cur/*`; \
    do mv $i .FreeBSD.perforce/$i; done'

This is not optimal, either, but at least it should not suffer from needless IO and potential data loss issues.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .