8

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

George M
  • 13,589
  • 4
  • 43
  • 53
Cory Klein
  • 18,391
  • 26
  • 81
  • 93
  • 1
    have a look at https://lists.debian.org/debian-user/2006/06/msg00716.html – Ulrich Dangel Jun 29 '12 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 Jun 29 '12 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. – Ulrich Dangel Jun 30 '12 at 00:24

4 Answers4

3

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

George M
  • 13,589
  • 4
  • 43
  • 53
2

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:

muttrc:

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/

Community
  • 1
user3630647
  • 21
  • 1
2

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.

Jake
  • 231
  • 2
  • 6
  • 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 Feb 26 '13 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 Dec 31 '17 at 07: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. – Rudolf Adamkovic Apr 13 '21 at 22:26
1

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.

cnst
  • 3,223
  • 2
  • 23
  • 44