I am very fond of the exim MTA. Its extremely flexible configuration file format may just be Turing-complete, and it allows me to play with my email in just about any way I like.

In one way, though, exim is strangely limited. When I think of the many intersections between email and DNS, I expect an MTA to have many varied ways to access DNS information. Exim uses DNS widely, of course, as it must, but it can only access it the “dog standard” way, through the stub resolver in the C runtime (ie. the gethostbyname library function). It doesn’t use any of the modern alternative DNS libraries such as ares. As a consequence, it is not possible to specify an alternative nameserver, nor an alternative port number for DNS queries.

Another place where I often feel exim slightly deficient is in the choices it offers for storing data sets of IP addresses (usually called lookups in the exim world). Such data sets are needed, to give just the most basic example, for blocking SMTP connections from known active spam bots. There are really only two ways of storing such data built directly into exim: flat files accessed via linear search, and hashed key-value stores such as the legendary Berkeley DB, now owned and maintained by Oracle.

But hashing is not the most natural data structure for IP address data. For most purposes one doesn’t want to store individual addresses but rather CIDR ranges, ie. parts of IP space carved by fixing some number of most significant bits and letting the least significant bits vary. And this shape of data is a great fit for a radix tree structure, or a trie which is bascially a radix tree cleverly optimized by path compression.

corkipset

One library that offers this kind of storage and functions to query it is corkipset. But there are still two problems with getting exim to use it:

• Unless one’s ready to locally hack on exim code¹ it’s necessary to use “dlopening” ie. runtime loading of shared libraries. This has uncomfortable security connotations, as in most installations exim runs setuid root, for rather complex reasons.
• Because the exim daemon spawns a worker process to handle each email message, and each worker process calls the exec syscall to restart the exim program image from scratch, there can be no permanently accessible data available to the worker processes. Instead each worker process must open the necessary data files anew. This is not a problem for small files and pieces of data but is clearly inefficient for huge data such as spammer block lists, especially when it must be parsed anew every time from a human-readable format.

rbldnsd

rbldnsd is a nice solution to the last problem I wrote above. It is an extremely lightweight daemon which stores sets of CIDR ranges in its working memory and answers queries about them on a socket. But, conveniently or not depending on situation and point of view, the socket is an UDP one and the protocol spoken is DNS. For example, to query if the address 12.34.56.78 is in the dataset, or to get the value associated to it, we must make a DNS A record query for

78.56.34.12.ds.rbl.example.net

where ds.rbl.example.net is the DNS zone for which rbldnsd is made authoritative. The result of this is, if we wanted to query rbldnsd directly from exim, using the native way exim does DNS, we’d have to let rbldnsd use port 53 for its listening socket, and make the listening address the systemwide resolver address, ie. put it on the nameserver line in /etc/resolv.conf. This is clearly impossible for any number of reasons.

Stub zones

Fortunately there is a workaround. Recursive DNS resolver daemons such as unbound have a concept of stub zones. For example, we can configure the ds.rbl.example.net zone to be a stub zone in unbound, which means unbound will delegate to another fixed nameserver any query for the zone if it cannot find the answer in its own cache. The only remaining problem is to find an address and a port for rbldnsd to listen on such that it doesn’t clash with the system resolver. This can be done in a couple of different ways; I have found it easiest to use an IPv6 address, because I have a huge supply of them while I only have a single IPv4 address for the only interface on my VPS (other than loopback).