Good Mail Sorting

plasmasturm.org

15 points·nnutter··4 comments

Any typo that aborts program execution will cost you mail. Any bug that manifests someday in the future will cost you mail. [...] For over a decade, I was so fixated on doing the mail processing during delivery that I was blind to the much simpler approach that was staring me right in the face.

So, why not even go a step further and treat maildir as append-only storage? Do the deletions, mark-as-read, and attachment inspection using notmuch. This is one of the really cool things about notmuch: it gives you a mutable view of 'immutable' mail storage.

Back when I was running a disposable email service called dodgeit.com I settled on a similar approach. I would just have postfix drop the mail in Maildir style files, then had a perl script parse the messages one by one. I didn't even call it from cron--it would just finish traversing then start over again after sleeping for a second. This effectively scaled to thousands of messages an hour on a single dedicated host.

I played around with a number of approaches, like the author here. But the one that just trusted the mail daemon to do its thing and the Linux filesystem to do its thing worked best for me.

Seems a bit inefficient to scan through all files all the time, doesn't it? I suppose with SSD:s and enough RAM it won't do terrible things to the usability of the computer while doing a scan, but still. If I did something like this I'd probably pair it with a database of received_at + path mappings that's populated when mail is received.

He mentioned Sieve in passing, I wonder what the problem with it is. I use Dovecot and Sieve, and have never had a single problem, apart from mis-written sieve rules. The syntax isn't the most concise, but how much worse could it be compared to a hand-rolled sorting program?

Reply on news.ycombinator.com