Woody's SMTP Blacklist: a dormant list that still shows up in checkers

Woody's SMTP Blacklist is a small, personally maintained DNSBL that published three zones: blacklist.woody.ch for IPv4, ipv6.blacklist.woody.ch for IPv6, and uri.blacklist.woody.ch for domains found in message links. Entries were added manually by the maintainer, aided by a spam-trap address. It is included in the large aggregate checkers, which is why most people ever hear of it.

What is verifiable today is less flattering than the guides suggest. Public DNSBL trackers that monitor zone health show no listing activity on these zones for years — their records of the last observed listing fall in 2021 and 2022 — and show the standard 127.0.0.2 test entry failing, which is the conventional signal that a zone is not being maintained correctly. The nameservers still answer queries.

Draw the practical conclusion: treat a row for this list as a prompt to check the list's status, not as an incident. That is not a dismissal of the operator's work, it is a statement about what a listing on a dormant zone can cost you, which is close to nothing.

Why dormant zones still matter a little

Two risks are real and worth understanding, because they apply to the entire long tail of small DNSBLs.

Stale configurations. Mail servers configured in 2015 are still running. If one of your recipients' servers queries a dormant zone and that zone has a years-old entry for your IP, your mail is refused by that server with no path to appeal, because nobody is processing removals.

Repurposed or broken zones. This is the one to actually watch for. If an abandoned DNSBL's domain lapses or its wildcard behaviour breaks, the zone can start answering "listed" for *every* query. Receivers still consulting it then reject everything. It has happened to other retired lists, which is why responsible operators publish a formal shutdown notice and return NXDOMAIN — and why a sudden "listed on everything" result from one small zone is a sign the zone has failed, not that you have.

The precedent worth remembering: SORBS, a genuinely significant list, was shut down by Proofpoint on 5 June 2024, and checkers kept showing rows against it long after.

What to do if a checker flags you here

1. Confirm which zone and which object. Query it directly rather than trusting the checker's label:

dig +short 9.113.0.203.blacklist.woody.ch       # reversed octets of 203.0.113.9
dig +short -t txt 9.113.0.203.blacklist.woody.ch
dig +short yourdomain.com.uri.blacklist.woody.ch

1. Sanity-check the zone. Query the standard test entries: 2.0.0.127 should answer listed and 1.0.0.127 should answer nothing. If both answer, or neither does, the zone is misbehaving and your result is meaningless.

1. Check when the zone was last actually updated. A SOA query gives you the zone's serial number and refresh interval, independent of any single IP lookup:

dig +short SOA blacklist.woody.ch

A serial number that encodes a date years in the past, alongside a failing test entry, is two independent signals pointing the same way: nobody is maintaining this zone day to day.

1. Check whether it is affecting anything. Any real block names the list in the rejection text. If no rejection mentions this zone, nothing is being blocked by it.
2. Check the lists that matter instead. Spamhaus, Barracuda, SpamCop, SURBL and URIBL, plus your own per-provider placement. If one of those is also red, that is your actual problem and it probably explains the small-list row too.
3. If you genuinely need removal, the contact path for a one-person list is an email to the maintainer, polite and specific: the IP or domain, the date, what changed. Expect that a dormant list may not answer, and do not escalate.

What not to do

• Do not spend an afternoon on it. Opportunity cost is the real damage small-list rows cause.
• Do not report it to your ESP as a block. They will ask which rejection named it, and there will not be one.
• Do not pay any service to remove you. Nothing legitimate charges for delisting, and nobody but the operator can do it.
• Do not change your sending domain or rotate IPs over a long-tail listing. You would be trading a cosmetic problem for a real reputation reset.
• Do not conclude that all small lists are irrelevant. Invaluement is small and matters a great deal, because enterprise filters subscribe to it. Reach is about who queries the zone, not how many entries it holds.

A better default for checker noise

Decide once which lists you will act on — the handful that receivers actually consult — and treat everything else as information. Then put your monitoring effort where the signal is: are messages arriving, at which providers, in which folder. A listing matters only in so far as it changes that.

MailPilot checks the lists receivers actually use against your sending domains and IPs and measures per-provider inbox placement daily from a seed-inbox network, so you can tell the difference between a dormant-zone row and a real delivery problem in minutes rather than an afternoon.