Email incident report: njabl.org

The spam DNSBL server at njabl.org went no-op in 2013 and dark in 2023, and starting at around 21:00 PST on January 1, 2024, was taken over by new controllers who began to inadvertently reject all email.

Introductory information

A DNS blocklist (DNSBL) is a service used primarily to mitigate email spam. Historically these have tracked email servers which have been subject to spam abuse, either due to lax abuse policies or due to being an open relay.

The way they work is when an email is received from a server, the receiver checks one or more DNSBLs by looking up their address. For example, if an email comes from 127.0.0.9 and the receiver is configured to use blocklist.example.com, the receiver checks the address 127.0.0.9.blocklist.example.com. If the DNSBL server responds with an address record, that means that the address is known to be a spammer.

This approach has a few nice attributes, such as DNS being a very lightweight service with pervasive global caching, and the typical failure mode for a server going down or being decommissioned is for future queries to all either come up with no response or NXDOMAIN, which is a fail-safe in the case of querying for blocklist inclusion.

NJABL incident

NJABL was a freely-available DNSBL which was advertised in several large and trusted lists. However, it was shut down in 2013, and put into a “fail-safe” mode where it would simply respond to all queries with “no such host,” making it essentially a no-op.

For a brief period in August 2023, the NJABL blocklist DNS servers were inaccessible entirely, but then were restored to their no-op functionality.

At the end of January 1, 2024, the domain began being served by a domain squatter, and this squatter also added a wildcard DNS which caused all subdomains of njabl.org to return an address, making it effectively act as a “block all email” DNSBL.

Mitigations

For the immediate term, anyone running their own incoming email server must ensure that the njabl.org DNSBLs are not listed in their configurations.

For example, in Postfix, you would edit your /etc/postfix/main.cf and remove the clause reject_rbl_client combined.njabl.org (or similar) from the smtpd_relay_restrictions configuration, for example changing

/etc/postfix/main.cf

smtpd_relay_restrictions = permit_mynetworks,
    permit_sasl_authenticated,
    reject_rbl_client dul.dnsbl.sorbs.net,
    reject_rbl_client cbl.abuseat.org,
    reject_rbl_client sbl-xbl.spamhaus.org,
    reject_rbl_client korea.services.net,
    reject_rbl_client combined.njabl.org,
    reject_unauth_destination

to

/etc/postfix/main.cf

smtpd_relay_restrictions = permit_mynetworks,
    permit_sasl_authenticated,
    reject_rbl_client dul.dnsbl.sorbs.net,
    reject_rbl_client cbl.abuseat.org,
    reject_rbl_client sbl-xbl.spamhaus.org,
    reject_rbl_client korea.services.net,
    reject_unauth_destination

However, for the longer term, it is advisable to realize that any domain not under your own control may be taken over by a bad actor in the future. DNSBLs also are subject to data pollution which can cause other problems.

It is advised that people running incoming email servers should only use a DNSBL as a signal to a spam filter, rather than an outright cause of sever-level rejection. For example, SpamAssassin can be configured as such, and also provides finer-grained control over spam filtering than simply “yes” or “no.”

Comments

Before commenting, please read the comment policy.

Avatars provided via Libravatar