Woody's SMTP Blacklist: The Delisting Route Refuses

Every page that ranks for Woody's SMTP Blacklist tells the reader to submit a delisting request to the operator, and several give advice on how to word it. On 2 September 2026 the operator's removal endpoint returned HTTP 403, its lookup page returned unprocessed source code with the check and removal forms sealed inside a comment, and its public database rendered as a table with column headings and no rows.

That is the useful finding about this list, and it changes what a Woody's row on a report is worth.

What the list is, and who runs it

Woody's SMTP Blacklist is a personally operated DNS blocklist rather than a commercial service. Its own site is a personal homepage in German, which describes the blacklist as now part of the SWINOG blacklists, and the lookup page directs questions about the SWINOG lists to an abuse address at a Swiss network operator. The name on the top hundred page belongs to an individual rather than a company.

The scale matters for how to read the row, and it is worth saying without editorialising. This is one person's spam-trap data published as a DNS zone. That is a legitimate thing to run and several long-standing lists began that way. It is also a very different object from a service with a support queue.

MXToolbox describes it the same way. Its problem page for the list opens by saying that Woody's SMTP Blacklist "is a personal blacklist", that a listing means an address was caught by its spam trap, and that "One of the targets of this list is spammers who collect email addresses via email harvester software." That last clause is the closest thing to a published listing criterion anywhere, and it comes from MXToolbox rather than from the operator.

What the operator does publish

The lookup page carries a short changes list, and three items on it are citable mechanics.

Three zones, not one. The page names an IPv4 zone under blacklist.woody.ch, an IPv6 form under an ipv6 label on the same domain, and a URI list under a uri label, with a worked example for each of the last two, among them "URIBL support: example: bigspamer.com.uri.blacklist.woody.ch". An aggregated checker reporting a single Woody's row rarely says which of the three fired, and a URI listing names a domain in your message body rather than your sending address, which is a different diagnosis entirely. The general form of that distinction is worked through in which of your domains got listed.

Published expiry times. The same list gives them on one line, "Expire Times: Bounces: 1 hour | Spam: 24 hour | DB Entry: 14 days", so a bounce entry clears within the hour and a database entry within a fortnight. The line carries a date in 2010, so it is a durable statement of policy rather than a current status, and it is the only removal-adjacent figure the operator publishes.

Entries expire. The page states in the same changes list that entries "are delisted after a defined time", which is the closest thing to a removal policy anywhere on the site.

Taken together, the operator's own position is that listings expire on a timer. That is the opposite of the advice on every page ranking for the term.

What the operator's surfaces actually return

This section is a measurement rather than an argument, taken on 2 September 2026, path by path.

The lookup page at rblcheck.php3 returns HTTP 200 and 1,945 bytes. The bytes are unprocessed PHP source rather than a rendered page, so the check form, the add form and the removal form are all present in the file and all sealed inside an HTML comment, which means no visitor can use any of them.

The removal endpoint the page's own form points at returns HTTP 403.

The public database dump returns HTTP 200 at 227 bytes: a table carrying the column headings the operator designed, and no rows.

The top hundred entries page returns HTTP 200 at 1,015 bytes, with its own explanatory paragraph intact and an empty table under the heading.

The top autonomous systems page and the top bouncer page both return HTTP 500.

What each Woody's SMTP Blacklist page returned

• ~Depends: The lookup page returns 200, as unprocessed source with its check and removal forms inside a comment
• ✕No: The removal endpoint the form posts to returns 403
• ~Depends: The public database dump returns 200 with column headings and no rows
• ~Depends: The top hundred entries page returns 200 with an empty table
• ✕No: The top autonomous systems and top bouncer pages both return 500
• ✓Yes: The site root returns 200 and serves a personal homepage naming the blacklist

What none of that establishes is that the DNS zone has stopped answering. A web interface and a published zone are separate things, a zone can serve while a website rots, and a checker returning a Woody's row is reporting a DNS answer rather than reading the site. Saying more than that would be an inference beyond what was measured. What it does establish is that the delisting route every competing page describes could not be reached on the day it was tried.

Removal, and how to think about it now

Three honest options, in order of how much work they cost.

Wait. The operator's own page says entries are delisted after a defined time and publishes the periods. If the listing is a database entry it expires on a fortnight, and if it is a bounce or spam entry it expires much faster. Doing nothing is a strategy the operator has documented.

Try the operator anyway, and read what comes back. The lookup page still names a contact route for questions about the SWINOG lists. A request that names the address, the approximate date and what was actually fixed is the one worth sending, and repeat submissions on the same address are the fastest way to be ignored by any list operator.

Weight the row and move on. This is the option that fits most cold outbound programmes, and the next section is why.

A commercially operated listStaff, a queue and a contract

• A published removal route with a stated turnaround
• A lookup that answers from the live zone
• Subscribers who can be asked which lists they consult
• A support path when the route itself breaks
• An incentive to keep false positives low, because subscribers leave

A personally operated listOne estate, one set of traps

• A removal route that exists at the maintainer's discretion
• Interfaces that may age faster than the zone behind them
• Consumers who are unlikely to appear in your own bounce strings
• No escalation path when a page stops responding
• Trap data that can still be accurate while the website is not

What it means for a cold outbound programme

Read the row through the same test every row on an aggregated report deserves, which is whether anything has ever bounced you for it.

An aggregated checker queries dozens of zones in one pass, and a hit on one that no rejection string has ever named has probably never cost a send. MXToolbox publishes its own version of that argument on its UCEPROTECTL2 problem page, describing a reputation score whose low end means, in its words, "few inbox providers use this list to evaluate inbound email", and advising a sender troubleshooting a delivery problem to ask the recipient which lists they use. Reading a long multi-list report without over-reacting to it is the subject of how to read MXToolbox like a deliverability engineer.

Two things are still worth taking seriously.

The trap mechanism is real even if the interface is not. The listing criterion MXToolbox reports is spam traps, with harvested addresses named as a target. An outbound programme that reaches a trap address has a list-source problem regardless of which zone happened to notice, and that problem shows up in the bounce figure first. Compare against published bounce rate benchmarks and fix the source rather than the symptom.

A row you cannot clear is an argument for capacity, not for effort. The whole point of holding spare warmed sending capacity is that an address with a listing nobody can lift stops being an emergency, because it is replaced rather than rescued. That posture is the same one that turns a UCEPROTECT Level 2 allocation listing into a routing decision, and it is set out in checking and recovering from a blacklisting.

The one thing not to do is spend a morning composing a carefully worded delisting request for a form that returns 403.

The short version

Woody's SMTP Blacklist is a personally operated DNS blocklist, described by MXToolbox as a personal blacklist fed by a spam trap, and by the operator's own site as part of the SWINOG blacklists.

The operator publishes three zones rather than one, covering IPv4 addresses, IPv6 addresses and URIs, so an aggregated row that does not say which fired is not yet a diagnosis. It also publishes expiry periods: one hour for bounces, 24 hours for spam, and 14 days for a database entry.

Measured on 2 September 2026, the operator's lookup page served unprocessed source with its forms inside a comment, the removal endpoint returned 403, the public database and top hundred pages rendered empty, and two further pages returned 500. That says the delisting route described by every page ranking for this term could not be reached. It does not say the DNS zone has stopped answering, which is a separate question and was not tested.

The practical reading is to weight the row by whether any rejection has ever named it, fix any list-source problem the trap hit implies, and let the published expiry run.

If you would rather run outbound with enough spare warmed capacity that an unclearable listing is a swap rather than an outage, we plan the first campaign for free.

The zone names, the expiry periods and the SWINOG association are taken from blacklist.woody.ch's own lookup page and site root, fetched 2 September 2026. The personal blacklist description, the spam trap criterion and the reputation-score reasoning are taken from MXToolbox's problem pages, fetched the same day. The HTTP results for each operator path were measured first-hand on that date and stand as measurements rather than as conclusions about the DNS zone. Verify current list behaviour with the operator before relying on it.