I blogged about the RFC Ignorant blocking list back in 2006.
As of late April, 2012, any attempt to look up an entry on the list results in output indicating that "The blackholes.five-ten-sg.com list is retired. No ip address is listed here." Meaning, the list is no longer in operation.
I had previously written about this list back in October, 2007, and my 2007-2008 DNSBL statistics project data showed that the list may not be suitable for broad production use if one wishes to receive requested email messages. The list has been up and down at various other times, most recently being taken offline for a period in November 2010.
(Hat tip: Word to the Wise)
Today, reader John Carver kindly wrote in to let me know that this blocking list is indeed defunct and has "listed the world," installing a wildcard DNS record with the result that if you use ybl.megacity.org in your mail server configuration, you're going to reject 100% of your mail. Query of any domain or IP address under ybl.megacity.org will result in a "127.0.0.2" positive response, that will make a mail server think it should reject the email message in question.
If you use ybl.megacity.org as a DNSBL list in your mail server configuration, I strongly recommend you remove it immediately. The list is long dead, and use of the list will result in you accidentally rejecting 100% of inbound mail.
As recently as 2006, the DNSBL also responded with text warning that it was defunct: "521 The IP
Karmasphere has indicated that the feed service will be discontinued on November 16, 2009. It's very important that all Karmasphere-using mail administrators remove any Karmasphere-hosted DNSBLs from their configuration before that date, else inbound receipt of legitimate email messages could be delayed or otherwise impacted.
For more information, click on over to Spam Resource to read a copy of the Karmasphere notice.
Today, the website warns that the rbl.cluecentral.net service is closed. Sabri notes that "[it has become] more and more difficult and time-consuming to maintain a trustworthy list I started to notice more and more errors. The list is no longer of the quality needed to use in a production environment."
The website warns that if DNS queries continue at a high level, the DNS servers are likely to be configured in a way that will cause 100% of inbound mail attempts to be rejected, for all mail servers still using rbl.cluecentral.net. This makes it imperative that you remove any rbl.cluecentral.net zones from your mail server configuration, as soon as possible.
"Since that time, all queries to vox.schpider.com have timed out. I made an attempt to bring the domain name back up in 2008, only to find that people are still trying to query the domain name. [...] Because of that, I see no other option than to start returning positives for *any* query issued to vox.schpider.com, beginning 10/16/2009. If you happen to be trying to use a dead DNSBL, please update your mail server configuration."
Scott indicates that random mail administrators are still "pounding the hell" out of his DNSBL hundreds fo times per second, all day and all night, ever day. Not cool.
If you're still querying this DNSBL, it's important that you immediately remove it from your mail server configuration. As of October 16th, use of this DNSBL will result in you rejecting 100% of your inbound email.
The Open Whois list appears to have been created in 2007, with a goal of promoting transparency in domain registrations. According to the (now deceased) website, "It is a list of domains which are privately (or anonymously) registered, e.g. through services such as Domains By Proxy, or Moniker Privacy Protection."
As of July 18, 2009, it appears that a squatter has taken over the open-whois.org domain name. At first, the new owner of the domain used a "wildcard" DNS record, resulting in the return of a positive response for any DNS query. The net effect is that every domain checked against this blocking list results in a DNS response that makes your spam filter think that the domain is listed, usually incorrectly so.
Since the issue was first observed, the squatter must have noticed all of this DNS traffic coming from SpamAssassin users and decided that the traffic was undesirable, so they've modified the domain in whois so that its name servers point at obviously invalid IP addresses.
That's good, because it means there shouldn't be any more false positive issues, for now. But, it does mean that your SpamAssassin checks take longer than usual, as queries against this dead list will time out. (And who is to say the squatter won't resurrect the domain with valid DNS servers and perhaps another DNS wildcard, causing a whole new batch of false positives for a whole bunch of SpamAssassin users.)
If you're a SpamAssassin user, it would be wise to remove or disable the SpamAssassin rule that check for that list. The rule you're looking for is located in the "72_active.cf" file in the rules subdirectory of your SA installation.
To disable this check in your SpamAssassin installation (manually), move or delete the "72_active.cf" file from your rules directory. Where this directory is exactly located is going to depend on your installation. On my friend's Linux installation, the directory path is /etc/mail/spamassassin/rules .
The better thing to do, I was advised by friendly SpamAssassin user Phil Randal, is to run sa-update. It's best practice for SA users to run sa-update every week or few to load the latest "in between-release" updates. Running sa-update will ensure that the bl.open-whois.org check is disabled.
I suspect that this blocking list check will be removed from SpamAssassin in future releases, but as of today (8/18/2009), the check is still in the most recent version available for download (3.2.5). As long as you run sa-update or manually disable this check, you should be all set.
As of this writing on April 29th, 2009, I do still see active entries when querying via DNS, but I assume that these are likely to go away soon. If you utilize this list, I'd recommend removing it from your MTA or spam filter configuration.
ORDB is a long dead blocking list, gone for more than a year.
Recently, they started "listing the world" -- meaning everybody using ORDB is now blocking 100% of inbound mail. Blocking lists do this to shed themselves of any excess DNS query traffic from sites who haven't yet ceased querying their data. It can very much be considered a slap in the face -- hey, we tried shutting down the nice way, but since you're not listening, we're going to make all your mail bounce.
But what does that mean? Why am I listed?
You're not actually listed on ORDB. ORDB is returning a "yup, they're listed" answer for any IP address that people check. Meaning the whole world is listed. Everybody, not just you. It's not because they hate you, it's because they want people to stop querying their DNSBL.
If you received bounces from somebody that suggests that you're listed on ORDB, here's what to do:
- Call that person on the phone, if you can. Tell them all of their inbound mail is probably not working, and won't work, until they stop using ORDB. Point them to this page for more information.
- Don't worry. The person who bounced your mail is suddenly now having problems receiving any mail at all. They're likely to figure this out very quickly and fix it. Try your mail again, in a day or two.
Host blacklisted - Found on Realtime Black List server blocklist.address.is.wrong.spamhaus.org
I received a report today indicating that a mail administrator has been unable to reliably query the blackhole.securitysage.com DNSBL zone. With the help of my friends, I was able to confirm this issue.
It looks to be a DNS issue. What we see from here is that the zone blackhole.securitysage.com is delegated to nameserver blackhole.securitysage.com. The two DNS "glue entries" for the zone are servers that aren't configured to be authoritative for the zone, so no results are returned. Ultimately, this points toward a DNS configuration issue with this domain and/or sub-domain.
The popular anti-spam filter SpamAssassin has been tracking this issue since at least October 8, 2007. On October 17th, SpamAssassin decide to remove support for this list (implemented in the DNS_FROM_SECURITYSAGE rule), due to the ongoing issues with accessing this DNSBL.
As a result of this ongoing issue, I recommend against using the blackhole.securitysage.com blocking list. If you continue to check against this list; queries are likely to time out and it could delay the receipt of inbound mail. Use of this list while this issue persists is likely to provide no blocking or filtering benefit.
I, and others, have contacted Security Sage and Mr. Posluns, making him aware of the issue and asking for more information. I'll be sure to update this page with more information as I have it.
11/03/2007 update: I've seen no response to my email to Mr. Posluns, nor to a friend's email to Security Sage's support address. I emailed that support address today, and my attempt bounced. The error message suggested an SPF failure. The fact that I publish a working SPF record, and other information in the bounce, suggest that it is in error. I guess that means either nobody's home, or they don't want anyone to contact them.
5/26/2008 update: Way back in November, I talked to Jeffrey Posluns. He is no longer actively involved with Security Sage, but was kind enough to nudge the folks running things, in hopes of making things better. It fell off my radar, until a few days ago, when I was alerted to the fact that Security Sage's domains have expired.
Net result: Broken blocklist. Has a wildcard listing, meaning that if you use their list, you're probably negatively impacting your own email delivery.
My recommendation: Stop using this blocklist immediately and permanently. Even if they do somehow manage to pull things back together, they don't have a good track record of staying online.
Previous updates follow.
The real problem was for potential SORBS users – if they followed the instructions verbatim, they ended up rejecting 100% of your inbound mail. Sadly, I've seen traffic, which implies that this has happened to some degree. If you're going to use the SORBS blocklist, be very careful to make sure you've implemented it correctly. Both this, and SORBS' claim that dnsbl.sorbs.net is an unsafe zone to use, suggest that the SORBS' list may not be a wise starting point for those looking to simply, safely block spam. More information on SORBS can be found here.
There has never been a blocklist with a zone name of dnsbl.radparker.com -- and if you type that into the DNSBL section of your mail server config, you will break your inability to receive inbound mail.