For When You Can't Have The Real Thing
[ start | index | login ]
start > DNSBL Running Wild

DNSBL Running Wild

Created by dave. Last edited by dave, 11 years and 319 days ago. Viewed 2,359 times. #3
[diff] [history] [edit] [rdf]
(24 January 2012)

So years ago we get called into this small company working out of I don't remember where. We were doing some network discovery so that we could estimate some professional services work, mostly Windows work, which is why I wasn't involved.

All of a sudden their inbound sendmail server starts bouncing every incoming message as spam. My bosses, seeing an opportunity to provide value, send me in to figure out what is wrong so that I could fix it.

After much poking around, I concluded:

  • the timestamps on the and friends was several months old;
  • the timestamps on the relevant files in the /etc tree were also seven months old and no different from the configuration that had worked the previous day (and indeed, over the previous six months); and
  • the computer had been running quite happily for a couple of months, with the sendmail process having apparently been started at boot time and run without interruption since.
So. Nothing has changed, and suddenly everything is getting bounced as spam.

Close examination of the logs showed that it was a DNS black hole test that was marking the inbound messages as spam. And after much staring at that, I discovered that the problem was that the name of the dns black hole domain was typo-spelled.

The way black hole lists work is the receiving computer does a lookup against $IP.listname (where $IP is the address of the sending computer), and if they get an answer back, the message is to be blocked. If there's no record, you get an authoritative no-such-record response, which tells you that the message passes (this paper bag test anyways).

You might accidentally define your black hole for as This can be easy to do if you are using lists with either european or clever names and the spelling isn't intuitive to you. This used to be fairly harmless. What would happen is you'd have a DNS timeout on every inbound message as it tried to look up $ and failed, which is functionally the same as a no-such-record. Inbound mail would be slightly delayed, but not so much that anyone would ever notice.

But what started happening is that hosting providers started including wildcard records in hosted domains by default.

And yesterday, some hosting provider went live with an actual zone, which means all the lookups for $ now return records, which sendmail interprets as "block".

The solution was to correct the typo, re-make the config file, and bump sendmail.

no comments | post comment
This is a collection of techical information, much of it learned the hard way. Consider it a lab book or a /info directory. I doubt much of it will be of use to anyone else.

Useful: | Copyright 2000-2002 Matthias L. Jugel and Stephan J. Schmidt