History: RFC-Ignorant.org, rfc-ignorant.de, and why it ended

Summary

RFC-Ignorant.org was a DNS-based blacklist (DNSBL) with an unusual mission: it did not primarily hunt spam sources—it hunted silence. If a domain ran mail but failed to provide working postmaster@ and abuse@ contacts, it could end up on the list. The idea was simple: operational responsibility starts with being reachable.

This page tells the story as a dramatized field report—an “agent story” built around the real mechanics and the real arguments. Names and scenes are fictional; the protocol hygiene lesson is not. Mail breaks in boring ways, and boring failures scale into expensive incidents.

Origins and scope

It began, as most infrastructure failures do, with something nobody wanted to read: a bounce message.

550 5.1.1. Recipient unknown. The complaint had been polite—almost apologetic—yet it came back like a door slammed in the face. The report said a domain was spewing junk mail, and the only thing more predictable than the spam was the silence on the other end.

In the early 2000s the mail world was a patchwork of small operators. Everyone had a slightly different MTA, slightly different policies, and the same two shared nightmares: being used as a spam cannon, and being blamed for it. The unglamorous truth was that most “security incidents” in mail operations were really contact problems. Somebody tried to do the right thing, and the system offered no place to land the message.

Our protagonist—call him M., because every field report deserves an initial—was not a hero. He was an administrator with a habit of reading RFCs like they were wiring diagrams. He knew that SMTP was not a moral system. It was a delivery system. And delivery systems need emergency exits.

Those exits had names. They were boring, standardized names:

• postmaster@ — the mailbox that must exist for SMTP operations to function sanely.
• abuse@ — the mailbox that keeps small fires from becoming continent-sized ones.

M. had seen the failure mode too many times: a compromised web host, a stolen credential, a misconfigured relay. Somebody notices. Somebody sends an alert. The alert bounces. The domain keeps burning. The rest of the Internet pays the smoke tax.

He could have written yet another angry essay. He could have joined the long, ritual debate about “what operators should do”. Instead, he built a lever. And because the mail ecosystem is built from levers, it moved.

The lever was a DNS zone. A DNSBL.

DNSBLs are dead simple in concept and terrifying in effect. You turn a judgment into a DNS lookup. You reverse an address or encode a token, you query a zone, and you treat a positive answer as a signal: mark, score, throttle, reject—whatever your policy engine will do with a binary hint.

M. chose a hint that wasn’t about the content of mail, nor even about the source IP. It was about reachability.

He wrote a testing harness that behaved like an overly persistent operator:

• Fetch the domain’s MX.
• Open an SMTP session.
• Ask: RCPT TO:<postmaster@domain>
• Ask: RCPT TO:<abuse@domain>
• Interpret the answer.

If the server said “no such user” for the very mailboxes meant to handle problems, that domain was, operationally speaking, a black hole. M. didn’t call it “evil”. He called it what it was: ignorant—not in the insulting sense, but in the literal sense of “ignoring the baseline duties of operating mail”.

The first entries on the list were predictable: half-abandoned domains with legacy MX records, small businesses with hosted mail nobody had documented, providers that offered mail as a checkbox and forgot the obligations that came with it. Then the list started catching bigger names. The network has a sense of humor: the larger the organization, the more likely it is that nobody owns the small, unsexy details.

Once those names appeared, the list stopped being a tool and became a message.

Mail admins began to query the zone. Some only tagged. Some raised scores. Some rejected outright, because “why deliver to people who can’t be reached when it breaks?” It wasn’t universal, but it didn’t need to be. Infrastructure pressure works like gravity: it’s weak per transaction and overwhelming in aggregate.

And so the operation had its first real success: domains began to fix their contact mailboxes. Not because they had suddenly discovered virtue, but because they had discovered consequences.

In a different line of work you would call that coercion. In mail operations it’s called “getting things done before the next incident.”

Of course, every lever attracts hands that want to pull it for their own reasons. Every list becomes a battlefield. And every battlefield eventually produces propaganda.

Criticism and shutdown

The first serious pushback did not come from spammers. It came from operators.

Some of them were principled: “A volunteer-run DNSBL should not be able to influence policy at scale.” Others were pragmatic: “False positives will happen, and the Internet will treat this as gospel.” A few were simply furious that a missing alias could suddenly become a reputational event.

M. had anticipated the debate but underestimated the volume. DNSBLs don’t live as web pages; they live inside pipelines. They are called automatically, thousands of times an hour, and whatever they output becomes part of automated judgment. A subtle, nuanced intent—“this is a signal”—gets flattened into a boolean—“block it.”

Two criticisms came up again and again:

• Stale data — if your retests lag, you punish the fixed and forgive the broken.
• Opaque logic — if people can’t reproduce your decisions, they won’t trust you (and they will still use you).

Both are fair. Both are also symptoms of the same disease: operating a DNSBL is not a weekend project. It’s infrastructure. Infrastructure demands money, monitoring, redundancy, and most brutally of all: time.

Time was the resource the project never truly had.

Meanwhile, the list created its own strange side effects. The moment operators started adding working abuse@ addresses, those mailboxes began to receive a second stream: not just incident reports, but spam, garbage, and opportunistic harassment. Some domains “fixed” the issue by deleting the mailbox again. They would vanish from the list briefly, then reappear. The list did not debate; it measured. The SMTP server answered what it answered.

In the middle of the noise, M. tried to keep one principle intact: the test must be reproducible. A domain should be able to see the exact failure. If you run mail, you should be able to run the check.

# Minimal reproducible check (conceptual)
# 1) discover MX
dig +short MX example.org | sort -n

# 2) test recipient acceptance against a chosen MX
# (Any equivalent SMTP client will do; the point is the RCPT response.)
# EHLO
# MAIL FROM
# RCPT TO:<postmaster@example.org>
# RCPT TO:<abuse@example.org>

But reproducible does not mean universally interpretable. Some MTAs accept recipients and bounce later. Some rate-limit probes. Some deliberately refuse directory-style validation to prevent address harvesting. Some domains never intended to accept mail at all and still had stray MX records. The world is messy; SMTP merely exposes the mess with an unusually honest error code.

Then the ecosystem shifted under everyone’s feet. Large providers grew larger. Centralized mail platforms ate the long tail. Abuse handling moved into ticket portals, internal trust & safety teams, automated takedown pipelines, and feedback loops that a small DNSBL could not see—let alone influence.

What had once been a sharp tool began to blunt. The list could still shame a small domain into creating aliases, but the domains that moved the most mail increasingly lived behind provider boundaries. The people who could fix things were not always the people being listed.

And then the ending arrived the way it usually does in operations: not as a dramatic defeat, but as a maintenance window that never reopened.

By the early 2010s the maintainers publicly pointed at the same unglamorous constraints that kill most volunteer infrastructure: aging hardware, operational burden, and diminishing time. There was talk of successor ideas. There were domain registrations. There were plans. But plans don’t answer DNS queries. The DNSBL stopped being updated. And a DNSBL that cannot stay current is worse than useless—it becomes collateral damage.

So the service ended. Quietly. Responsibly. The lever was set down.

Status today

The DNSBL is gone. What remains is the lesson—and the lesson is annoyingly timeless.

If you run mail (directly or through a provider), you are part of an incident-response mesh. Other operators will notice your failures, your compromises, your misconfigurations. Sometimes they will even try to help you. That help needs a landing pad.

Reachable contact points are not a courtesy. They are part of the protocol hygiene that keeps the ecosystem from turning every small compromise into a multi-week cleanup operation. In practice that means:

• postmaster@ exists, accepts mail, and is monitored.
• abuse@ exists, accepts mail, and is monitored.
• Inbound filtering and rate limits are fine; “user unknown” is not, if you claim to operate mail.
• Routing to a ticket system is fine; a black hole is not.

RFC-Ignorant is therefore best remembered as a peculiar kind of “agent operation”: not spying on content, not breaking systems, but using the simplest possible measurement—an SMTP recipient check—and turning it into visible pressure via DNS.

It was controversial because it worked, and it was fragile because all volunteer infrastructure is fragile. The modern ecosystem has other mechanisms, but none of them remove the basic requirement: when something breaks, other people must be able to reach you.

This site is documentation only. It does not operate any DNS blacklist (DNSBL/RBL). Consider it a declassified file: a reminder that the boring parts of standards are the parts that keep the lights on.

Further reading (German)

RFC-Ignorant.de ist weg – kernel-error.de

Keywords

RFC-Ignorant, DNSBL, RBL, mail operations, history