Re: [exim-dev] feature request for exim: query DNSBL provide…

Top Page
Delete this message
Reply to this message
Author: Phil Pennock
Date:  
To: Rob McEwen
CC: exim-dev
Subject: Re: [exim-dev] feature request for exim: query DNSBL providers' DNS servers directly
On 2017-09-09 at 14:59 -0400, Rob McEwen wrote:
> I have a feature request for Exim. Or, since Exim is clearly one of the
> world's most flexible/configurable MTAs, is... what I'm about to describe...
> already be possible with existing features?


Not quite possible, but could be a fairly small modification to the
dnsdb lookup type. But a bad idea because of Exim's architecture.

> (Ideally, Exim would internally cache the answer for the NS lookups... so
> that it wouldn't have to do this NS lookup with every single DNSBL lookup.
> But technically, that part is a bit more exotic.)


Exim forks a new process for every accepted connection and every
outbound delivery. Exim's lookup system isn't really designed for any
kind of programmable write-back caching (redis/whatever).

For the short lifetime of the process, lookup results are remembered in
an LRU, but that's about it.

Further, Exim is currently using OS native libresolv-style interfaces
and knows nothing except how to issue a query using those.

The normal approach for postmasters running mail-servers is to install a
dedicated DNS resolver either on the box, or serving the boxes, so that
all the DNS traffic from the mail-system doesn't push out of cache the
lookups which outbound query folks care about.

Then if a particular zone needs to be handled specially, that can be
configured in the DNS resolver's setup accordingly. Encapsulate the
special DNS logic in the DNS resolver.

If someone really wants something special but can't run a separate DNS
server (personal development box in colocation somewhere) then I'd look
at using pf/iptables user-based filtering to divert DNS traffic to the
resolver on port 53 to port 63 instead and run a second DNS resolver on
port 63, which is configured with a tiny cache, to forward most traffic
to the main resolver and handle the special zones accordingly.

-Phil