About Archive Tags RSS Feed

 

Replacing ugly things would save the world many hours

5 March 2014 21:50

There are some tools that we use daily, whether we realize it or not, that are unduly ugly. Over time you learn to use them and you forget just how hard they are to learn, and you take it for granted.

Today I had to guide somebody through using procmail, and I'd forgotten how annoying it is.

In brief I use procmail in three ways, each of which I had to document:

  • Run a command, given a new email, and replace the original email with the output of that command.
  • Run a command, silently. Just for fun.
  • Match a regular expression on a header-field, and file accordingly.
    • Later extended to matching regexps on multiple headers. ("AND" + "OR" )

There are some projects that are too entrenched to ever be replaced ("make", I'm looking at you), but procmail? I reckon there's a chance a replacement would be useful, quickly.

Then again, maybe I'm biased.

| 11 comments

 

Comments on this entry

icon smcv at 21:11 on 4 March 2014
http://smcv.pseudorandom.co.uk/

The post right below yours on Planet Debian () describes a setup including delivery through Dovecot's LDA, which reads Sieve filters. I use something similar myself, but with Postfix instead of Exim - Sieve is basically "procmail, but sane".

icon Tom Murphy at 22:56 on 4 March 2014
http://google.com

"make" may be a lot less irreplaceable than you think!

Take a look at Shake (https://github.com/ndmitchell/shake) -- more powerful, much less annoying, and can even run many Makefiles (http://neilmitchell.blogspot.com/2014/01/running-makefiles-with-shake.html). With some work, Shake could replace make even in large projects with existing Makefiles!

icon Steve Kemp at 23:16 on 4 March 2014
http://www.steve.org.uk/
icon cstamas at 06:49 on 5 March 2014
http://cstamas.hu

Courier's MDA is also a good alternative to procmail (which is horrible in many ways).

I also agree that Dovecot is the best in this regard.

icon Steve Kemp at 07:35 on 5 March 2014
http://www.steve.org.uk/

Although I do have dovecot setup for remote IMAP access you might remember that my email client doesn't support IMAP...


icon foobar at 08:04 on 5 March 2014

Take a look at https://github.com/teythoon/afew

icon Steve Kemp at 08:06 on 5 March 2014
http://www.steve.org.uk/

Thanks for the link.

My own notes are here:

icon Peter Pentchev at 15:59 on 5 March 2014
http://extelligence.ringlet.net/roam/

I assume that you are already aware of maildrop? Well, it is an improvement over procmail, at least in terms of syntax and reliability. It sounds as though you're thinking of a replacement in broader terms, but still it might be worth it to take a look at maildrop, see if you can't switch to it with some (even if minor) immediate benefits, and then again consider the broader picture :)

icon Steve Kemp at 16:03 on 5 March 2014
http://www.steve.org.uk/

Thanks for the pointer to maildrop - at the moment I'm investigating it, along with:

I do like the idea of Lua, but if I have to "program" in Perl, Python, or similar, then that isn't the end of the world.

icon -dsr- at 20:19 on 6 March 2014

I came here to say good things about maildrop, but I see someone has already. Instead, I'll point out that I used to futz around with Mail::Audit (and prior to that, procmail) and just about everything is less aggravating to do in maildrop.

I am implementing sieve for people at work, but the kind of people who could write their own sieve recipes are the kind of people I won't mind allowing to ssh in to the mail server and edit their maildrop recipes.

icon Wouter Verhelst at 09:32 on 7 March 2014
http://grep.be/

The only reason you should still be using procmail today is "I'm too lazy to replace it". There are several alternatives:

- maildrop
- Sieve (which is actually an RFC-defined protocol, not a file format, and is supported by many IMAP-speaking MUAs)
- My personal favourite: if you use exim as MTA, you can use exim filter files. See http://www.exim.org/exim-html-current/doc/html/spec_html/filter.html for the spec.