SpamCannibal comes back to life, starts spam-blocking everyone

What happens when anti-spam blocklists domains die?

Blocklisting servers, known more formally as Domain Name System-based Blackhole Lists (DNSBLs) or Real-time Blackhole Lists (RBLs), exist to provide high-speed answers to “is this site a known spammer?” queries, answering “yes” or “no” as rapidly as possible.

If there is a service problem, and the server goes offline, the service will stop responding to queries altogether, which means the DNSBL itself is down.

That’s what happened to the SpamCannibal.org blocklist, which operated from 2003 until August 2017, at which point it abruptly disappeared, apparently never to return.

Except that this week, on 30 May 2018, SpamCannibal came back from the dead and started sending “block this” replies to all spam queries sent to it, essentially reporting that everyone in the world was a spammer.

Unwelcome and chaotic, but at least it indicated the service had a problem.  

At the same time, however, SpamCannibal reportedly started forwarding web visitors to a domain parking site pushing a potentially malicious Flash plug-in.

The original owner of the domain had, it seemed, allowed the domain registration to lapse, allowing a squatter to take it over and bring it back to life this week.

Said Martijn Grooten of Virus Bulletin, who analysed the site’s second coming:

As is typical in the takeover of expired domains, it was pointed to a dodgy-looking (but not necessarily malicious) parking site. What was worse – though again not uncommon – was that a wildcard DNS was pointed to this parking site.

A day later and it looks as if someone, possibly the original domain owner, has mounted a rescue mission and returned SpamCannibal to its dormant state.

Said Grooten:

It still isn’t responding to any queries to its blocklist, but that is a lot better than responding to all queries.

The first issue raised by this incident is that a lot of software is still using SpamCannibal, even though it was unofficially retired nine months ago.

This can be mitigated by developers using a ‘health check’ function to verify that a DNSRBL is responding sensibly to spam queries.

Meanwhile, anyone running a spam blocklist should shut it down gracefully according to section 3.4 of the IETF’s RFC6471 to avoid any chaos of this nature. For example:

The DNSBL operator MUST issue impending shutdown warnings (on the DNSBL website, appropriate mailing lists, newsgroups, vendor newsletters, etc.).

And, pertinently in this case:

The base domain name SHOULD be registered indefinitely, so as to prevent the domain name from being a “booby trap” for future owners, and/or to prevent a new owner from maliciously listing the entire internet.

Alternatively, domains should be donated or handed over to someone trustworthy to look after.

General MacArthur wasn’t talking about spam blocklists when he famously said “old soldiers never die, they just fade away,” but in this case, the sentiment seems appropriate.