A private non-profit registered in Andorra maintains a list of networks the internet is asked not to route at all. The list is called DROP — Do not Route Or Peer. The wording is absolute: not tag a message, not file it as spam, but do not carry the traffic.
It is a strong claim. The boring, awkward question worth asking of any such claim is simply: who actually obeys? Not who could, not who ought to in principle, but who does, today, in the wires.
We measured it. Not with opinion, with sockets.
Who keeps the list
The Spamhaus Project was founded by Steve Linford in London in 1998. Today it is The Spamhaus Project SLU, a not-for-profit company registered in Andorra under number 18159. It compiles and publishes reputation lists free of charge: SBL, XBL, PBL, DROP and others.
Alongside it stands a second entity — Spamhaus Technology Ltd, a commercial company in London. In the organisation's own words, as "requests grew for real-time delivery at volume, we made this data available via a partner, Spamhaus Technology." A non-profit produces the lists; a commercial company sells industrial access to them.
That is not an accusation. It is a structure, and worth holding in mind when reading reach figures: the organisation states it protects 4.5 billion users. That number describes the potential reach of the data, not the number of networks that enforce its harshest recommendation.
What DROP actually means
SBL is a manual listing for spam and abuse. DROP is a subset of it: blocks Spamhaus considers wholly under criminal control, with a recommendation neither to route nor to peer. It is published in machine-readable form, today as drop_v4.json.
Two blocks anchor this measurement:
- 91.240.118.0/24 — ticket SBL636085, the entire /24 under one record. All 256 addresses answer identically: SBL, DROP and PBL.
- 109.238.86.0/23 — ticket SBL696993, likewise wholly in DROP.
One detail matters: a single ticket covering an entire block means what is listed is not "a few dirty addresses" but the network as a whole. This is the harshest form of listing Spamhaus issues.
The rig: one host, two addresses
The usual flaw in such checks is comparing different machines and charging to reputation what is really geography, provider and route. That flaw is absent here.
Both addresses live on the same border server, leave through the same uplink, the same default route, the same network stack. Exactly one variable differs — which source address is bound to the socket:
- 109.238.87.33 — inside SBL696993, in DROP;
- 152.232.134.114 — listed nowhere.
Anything that diverges between them is pure address reputation, with nothing mixed in. Fifty-seven destinations, one hundred sixty-eight connections in total.
Routing: the recommendation is not enforced
The strongest claim made about DROP is that the list reaches the BGP filters of transit carriers and the prefix stops being visible. That is directly testable: how many full-feed RIPE RIS peers see the announcement.
| Prefix | Status | Visibility |
|---|---|---|
| 91.240.118.0/24 | SBL + DROP | 322/328 — 98.2% |
| 109.238.87.0/24 | SBL + DROP | 324/328 — 98.8% |
| 212.116.240.0/24 | clean | 328/328 — 100% |
| 1.1.1.0/24 (Cloudflare) | benchmark | 84/85 — 98.8% |
A block flagged "do not route or peer" is visible in the global routing table exactly as well as a Cloudflare prefix. The difference is a fraction of a percent, the noise of a few private peers.
Not one transit carrier present in RIS enforces the recommendation. The loudest word on the list is, in practice, backed by nothing.
Reachability: one hit out of forty-five
Then the applied part. Forty-five destinations: package repositories, CDNs, payment systems, public APIs, Russian banks and state services, ordinary large sites. Each tested over TCP, TLS and HTTP from both addresses back to back.
Almost everything matched. GitHub, Docker Hub, Debian, PyPI, Let's Encrypt, Stripe, PayPal, Telegram, Gosuslugi, Sberbank, T-Bank — identical answers from the listed and the clean address, byte for byte. Where a refusal came back, it came back to both alike: that is the sites' own behaviour, not a reaction to the source.
Exactly one destination diverged — and it diverged reliably.
hetzner.com returns 403 Forbidden to the DROP address and 200 OK to the clean one. On retest: ten out of ten, without a single exception.
This is not a flap or load-balancer roulette but a deterministic decision on source reputation. And it is telling who makes it: a hosting provider. Not a bank, not a state service, not a payment processor — an infrastructure company, the kind that runs reputation feeds as a matter of profession.
So here is the honest scale of DROP's power: 2% of destinations, and those two percent sit inside the very industry that sells infrastructure.
And one case running the other way
Reddit consistently, seven runs out of seven, returns 403 Blocked to the clean address and 200 OK to the listed one.
That is worth absorbing. A site that decides who gets in looked at two addresses and blocked the one with the clean reputation. Its scoring weighs ASN, geography, request history, client fingerprint — anything except DROP. For a large share of the modern web's reputation layer, this list simply does not exist.
No cascade
A separate fear is that a Spamhaus listing drags an address through the rest of the blocklist landscape. Sixteen lists were checked: Barracuda, SpamCop, SORBS, UCEPROTECT at three levels, PSBL, blocklist.de, DroneBL, CBL, GBUdb, Interserver and others.
Both listed addresses appeared in exactly one list out of sixteen — Spamhaus itself. No snowball occurs.
What this measurement did not show
The limits of a method must be stated aloud, or it stops being research and becomes advocacy.
Mail was not measured. Port 25 on the test machine is closed by the provider for every address at once — the timeout is identical for the listed and the clean one. That the uplink is the cause was confirmed from a third machine on a different provider, where mail server banners arrive normally. Nothing about SMTP follows from this rig — though there was no argument here in the first place: any mail server that consults SBL will refuse the connection. That is not a hypothesis but the way the list is built, and the purpose it was built for.
Corporate perimeters were not measured. Inbound traffic into networks running pfBlockerNG, CrowdSec, FortiGuard and similar feeds cannot be tested from outside at all; that requires being inside. This part remains not refuted but genuinely unexamined. The indirect argument in its favour is the hetzner.com finding: if one hosting provider behaves this way in a sample of forty-five sites, the share of such perimeters is not zero.
Our note
Our note: the most durable form of power in a network is not the rule that is enforced but the rule people believe is enforced. DROP says "do not route." No transit carrier listens. Yet the sentence works without enforcement: a host refuses a customer, a marketplace declines a block, a buyer talks the price down, an engineer designs a detour around a wall that is not there. The power lies not in the filter but in the filter's reputation.
This is the plain mechanics of Isfet — disorder wearing the clothes of order. Not a valve that stops the flow, but a rumour of a valve that makes the flow turn aside on its own. The elegance of the arrangement is that it needs no coercion, no budget and no consent from any network: it is enough that people repeat it to one another as fact.
Maat begins with something small and dull: measurement. To weigh the heart is to put a claim on the scales and watch the needle rather than the speaker. Spamhaus does necessary work and has done it for a long time; the question is not their good faith but our habit of taking scale on trust. A verified claim and a repeated claim are different things, even when they are spoken in the same words.
What it means in practice
For an operator who runs networks, the conclusion is concrete:
- Transit is unaffected by the listing — the prefix is announced and seen.
- Web, VPN, nodes and APIs work: forty-four destinations out of forty-five are indistinguishable from the clean address.
- Mail will not leave such a block. This is the one area where the list works as designed and at full strength.
- Point refusals will occur — and they will come from infrastructure companies rather than mass-market services.
- Removing a DROP record without changing the block's holder at the RIR is effectively impossible: the ticket is written against the whole network.
A block in DROP is therefore not a dead block. It is a block with a known defect: unusable for mail, usable for everything else, with a two-percent tail of point refusals. Whether to buy or run one is a question of price, not a verdict.
How to check it yourself
One practical mine sinks most self-run checks: Spamhaus blocks queries made through public resolvers. Ask via 1.1.1.1 or 8.8.8.8 and the answer is 127.255.255.254 — an error code meaning "query via public resolver," and very easily mistaken for "the address is clean."
To confirm a resolver is usable, the test address must return three codes:
dig +short @<resolver> 2.0.0.127.zen.spamhaus.org A
→ 127.0.0.2, 127.0.0.4, 127.0.0.10
An empty answer means the problem is the resolver, not the address. The measurement itself reproduces with raw sockets bound to the chosen source address: it is the socket binding, not running from different machines, that makes the comparison honest.
Sources
- The Spamhaus Project — Organization: founding in London in 1998, base in Andorra, the split between the Project and Spamhaus Technology.
- Spamhaus — Terms & Conditions: details of The Spamhaus Project SLU, Andorra, registration number 18159, and Spamhaus Technology Ltd, London.
- Spamhaus DROP, machine-readable list: records SBL636085 and SBL696993, retrieved 23 August 2026.
- RIPEstat, routing-status: prefix visibility in RIPE RIS, retrieved 23 August 2026.
- Editorial measurement: 57 destinations, 168 connections from two addresses on a single border node, 23 August 2026.