Wandering Thoughts archives

2020-09-02

Why I want something like Procmail with a dedicated mail filtering language

A couple of years ago I wrote about discovering that procmail development is basically dead and wondering out loud what I might switch to. In some comments on that entry, Aristotle Pagaltzis suggested that in an environment (such as MH) with one message per file, well, let me quote:

[...], 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.

My reply (in another comment on that entry) was that I wanted a system where I directly wrote mail filtering rules, as is the case in procmail, not a system where I wrote filtering rules in some general purpose programming language. But I never explained why I wanted a special purpose language for this.

My reason for this is that writing mail filtering in a special purpose language removes (or rather hides) all of the plumbing that is otherwise necessary. The result may have obscure syntax (procmail certainly does), but almost everything it says is about what mail filtering is happening, not the structure of getting it to happen (both at the large scale level of opening files, parsing them, moving them around, and at the small scale level of executing or otherwise matching rules). This makes it much easier to come back later to pull out 'what is this filtering' from the system; the configuration file you read is all about that. With a general purpose programming language, coming back in six months or a year requires essentially reverse engineering your entire program, because you have to find the filtering rules in the rest of the code (and understand how they're executed).

(In theory you can avoid some of this if you write good enough documentation for your personal filtering setup. In practice it's pretty unlikely that you will, or that this documentation will be well tested enough (because you need to test documentation). An open source mail filtering system with a dedicated filtering language is much more likely to have good documentation that lets you drop right into understanding your filtering rules again.)

This is a subtle advantage of DSLs (Domain Specific Languages) in general. In a good DSL, much like with wikitext, almost everything you write is real 'content' (here, real filtering rules), and very little of it is scaffolding. A general purpose language necessarily isn't that focused on your specific problem area, and so making it focus that way requires a bunch of scaffolding. At the extreme, you wind up building your own language that's implemented in the general purpose language.

(This may be literal, with a parser and everything, or it may be in the form of a set of stylized and standard function calls or method calls you make to embody your real work.)

WhyMailFilteringLanguage written at 23:46:24; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.