The best thing about maildrop is that when you haven't looked at the recipe in six months, it only takes a few seconds to figure out what you were doing and how you want to do a new thing.

Here's my "90% of everything anybody ever wants to do in a filter" example:

xfilter "/usr/bin/spamc -U /var/lib/spamassassin/socket"
     if (/^X-Spam-Status: Yes/:h)
     {   
       to Maildir/spam/
     }

`reformail -D 16000 duplicate.cache`
  if ( $RETURNCODE == 0 )
      exit

if (/^X-Facebook.*/:h)
      to Maildir/facebook/

if (/^Subject: \[Slack\] Notifications.*/:h)
      to Maildir/slack/

I've been seeing comments about Procmail's bitrot (I'm reluctant to call it death) for a while now too.

I'm probably one of the heaviest users of Procmail that I know. (I believe in making the computer do things for me.)

% egrep "^\s*:" ~/.procmailrc.d/* | wc -l
566

(Yes, I INCLUDERC multiple files in a subdirectory to make sorting & maintaining recipes easier.)

Almost all of them are doing a relatively simple test that I expect maildrop could also do. (I've not looked.)

I do use Message-ID caches within folders, but do not like to use them for all of my email because I want copies of messages from mailing lists not copies that were sent to me directly (via To: / CC: / BCC:). Seeing as how the direct copy almost always arrives first, a simple caching technique would do the opposite of what I want. So, I pipe copies of messages from mailing lists to external programs that will remove messages from my inbox that contain the message ID. (They actually move it from my Inbox to Trash and mark the message as read.)

I've also done things like taking copies of messages from RSS feeds (via rss2email) and piped them into custom scripts that would extract URLs for images and feed them into something that would pre-cache them in my local caching proxy. (This was mostly when I was on slow DSL and is not much of an issue now.)

One of the other probably strange things that I do with Procmail is have it apply a RegEx to email looking for ${Bounding}${KeyWords}${Bounding} and set a variable in Procmail. I do this multiple times, each match appending the topic to the variable. Finally, I call formail to add said topic(s) to the Keywords: header.

I add the X-Priority: header with a value of 3 (normal) if it's not there already.

I also have a number of mailing lists that I add the List-Post: header so that my MUA behaves the way that I like.

Suffice it to say that I'm quite entrenched in Procmail. I have yet to see anything that can qualify as a drop in replacement for me.

Dovecot has its own LDA (although I see they now recommend the LMTP server version) that features a Sieve plugin with vendor extensions to call external programs. I can't see anything about MH support though.

I've recently seen FDM recommended, although I haven't looked at it yet myself. I suppose I should start said looking. My group makes use of it which, while light and relatively trivial, is currently integral to our workflow.

Have you seen my article on that? The gist is just use a basic MDA that dumps your mail into a Maildir spool; then you can write yourself one or more programs in your favourite language that kick the mail from there to wherever you want it to end up. The entirety of the job of such code is opening and reading files and then moving them, for which any language whatsoever will do, so the only concern is how far you want to library up your mail parsing.

I like your approach in the abstract, but in practice I currently think it would have two flaws for me. The first is that I would have to put together (and probably create) a mail filtering environment that either interpreted filtering rules or directly embodied those rules in programs. I'm not terribly enthused about doing this myself; I really want a canned environment that someone else reliably maintains and that I just write rules for. The second is that my entire current mail environment is oriented around mbox format files and MH folders; nothing understands Maildir. So I'd be writing to Maildir, manipulating it, and then probably reconstructing mbox files so I could feed them to other tools, which feels at best awkward.

D’oh. You have mentioned MH so often, I should have remembered. No matter though – it is a one-file-per-mail format, just like Maildir, so all arguments and conclusions apply equally to it. Mbox OTOH would be a lot more annoying to deal with, that is true. (Esp. if you get mail delivered into Mbox files…)

As for a canned environment, there really isn’t much of it to can (given a one-file-per-mail format): looping over a directory’s entries, reading each and/or passing to a parser, and ultimately moving the file wherever it’s supposed to go. It’s just a couple lines of scaffolding, the rest of the code is rules. But instead of someone’s weird special-purpose language, you get to write them in whichever plain-jane language you use every day, so there’s never a question of whether you’ll be able to do some unusual thing, and much less of a question of whether you’ll be able to reconstruct its operation half a decade later.

I don’t know if this approach is right for you, but if it weren’t for the Mbox question, I’d suggest you test it out and see how it feels. With Mbox in the mix… could be that it’s not worth it then. For me, it has completely removed the quiet irritation with my mail filtering setup from my life.