John Levine:
> Over on another list, people were grousing that it's impossible to
> shut down a DNSBL because no matter what you do, clueless people with
> dusty mail configurations will keep hammering on it. You can list
> nothing, or list everything, or put in long delays, or return
> delegations to name servers on nonexistent networks, or return text
> records with obscene insults, but they will keep hammering. I know
> this from personal experience as I have tried to get people to stop
> querying misspelled versions of my korea.services.net BL.
Postfix has a low rate of "required" updates, so an "install and
forget" scenario is very well possible, especially when it runs on
a dedicated machine that does nothing else.
> While most Postfix users are skilled, sophisticated mail
> administrators, some aren't. It's really easy to do defensive testing
> of BLs before you use them: look up 127.0.0.2 and check that you an A
> record with an address in 127/8, and look up 127.0.0.1 and check that
> you get nothing. Then if the answers are OK you use the DNSBLs, if
> not you don't. You don't need to check very often; in my prototype I
> check once a week.
>
> It looks to me like it would be easy to do these checks in dnsblog
> each time it starts. That's probably more often than is ideal (how
> long does it typically run?) but it's way better than letting people
It terminates after 100s of idle time. On a busy server, some dnsblog
process may run for a very long time. In practice, the number of
dnsblog processes will vary with the query load.
> hammer on dead BLs. It also makes mail servers marginally more robust
> since they won't reject all the mail when the operator of a defunct BL
> gets exasperated and lists the world.
>
> Does this sound reasonable? Is there a better way to do it?
There are two DNSXL clients in Postfix: the smtpd daemons, and the
dnsblog daemons that do lookups for the event-driven postscreen
daemon. Given Postfix's architecture it would be easiest to delegate
cache management to a dedicated process.
I would do this with a small health-check daemon that manages a
small persistent status cache, that is occasionally queried by the
Postfix DNSXL clients. When the answer is not cached, or when a
cached answer is past a certain age, this health-check daemon could
ask dnsblog to do your 127.0.0.2 and 127.0.0.1 probes.
Just like the verify daemon for sender or recipient email addresses,
the health check daemon could update a cached result well before
it expires, so that an occasional network outage has no effect.
This should be simpler than the verify client and server, which
amount to about 450 lines of code, K&R style, excluding test driver,
comments, and documentation. That gives a solution that is totally
integrated with the rest of Postfix, i.e. install and forget.
Wietse
