NEW! Please see question and answer about the AUTHBL
ALWAYS go to the CBL lookup page and follow the instructions. The lookup page and this FAQ attempt to both help you delist and help you prevent it getting listed again.
You have a virus, or an open proxy, a trojan spam-sender or some other sort of security compromise, or some sort of unusual misconfiguration which is causing your IP to be relisted. Always ensure that viruses, open proxies, etc. are removed or secured before trying to delist your IP.
If you did all that but still keep getting listed, then see below for where to talk about the problem.
The CBL NEVER charges money for a delisting, and does NOT provide referrals to consultants. The CBL strongly believes in eliminating any possibility of bias, perceived or otherwise.
From time to time you may encounter claims that some person can get you delisted for a fee. The only way to get delisted and stay delisted is to identify the cause for the listing and prevent it happening again.
The CBL DOES NOT list open SMTP relays, hence open relay testers such as that at abuse.net and orbs.org are irrelevant to the CBL.
Many of our correspondents are confused by this statement, so it's a good idea to explain the difference between an open SMTP relay, and "open proxies" that we DO detect.
In a nutshell:
The CBL has been detecting something that it calls "open relay". That does not mean that the IP address we've listed is an open SMTP relay, it means that the IP address we've listed is attempting to get our spamtraps to open relay. Most of these turn out to be Cutwail infections trying to force-relay through other mail servers.
Apparently a recent upgrade/release of Merak (recent as of 2006/12/31) instantiates an open CONNECT proxy on port 32000 without warning. If you are running a recent version of Merak, please make sure that this proxy is turned off. If in doubt, do a port scan of port 32000.
While it is perfectly true that UNIX-like operating systems are almost NEVER infectable with Windows viruses, there are a number of virus-like things that UNIX-like systems are susceptible to.For example:
Some of these vulnerabilities are to the extent that a malefactor can install a full proxy/trojan spamming engine on your machine and control it remotely. Through this, they can set up spamming engines, open proxies, malware download and spam redirectors. Watch out for strange directories being created, particularly those starting with a "." in /tmp. Check for this by doing an "ls -la" in /tmp, and look for directory names starting with "." (other than "." and ".." themselves).
It is CRITICALLY IMPORTANT that all web-facing applications or application infrastructures (Wordpress, Joomla, Cpanel, etc. etc.) are kept fully patched and up-to-date. Furthmore, userid/passwords and other credentials for logging into such systems should be highly protected, require strong passwords and changed as frequently as practical/feasible. Some web hosting services have had to resort to two-factor authentication to protect themselves from stolen or spoofed authentivcations.
Such sites should consider continous monitoring of web, ftp and other subsystems.
Check that you have good remote login-capable passwords (eg: telnet, FTP, SSH), inspect your logs for large quantities of failed SSH/telnet login attempts.
Consider running a "system modification" detector such as Tripwire or rkhunter. Tripwire is designed to detect and report modifications to important system programs. Rkhunter does what Tripwire does, but looks for specific rootkits, insecure versions of system software and more.
Those will not be disclosed because it may give spammers or virus writers hints on how to avoid the CBL.
The next section provides information on how to diagnose persistent CBL relistings.
The Spamhaus AUTHBL (at present offered as DQS only, not regular DNSBL) is a specialized subset of the CBL/XBL. The AUTHBL consists of those CBL/XBL listings where the infection we've detected is, or is known to be capable of, breaking into authenticated email accounts to send or receive email. In short, we know that the IP can log into a mail account with stolen/guessed password, and fake the origin of the email. This is a very big problem across the Internet.
The AUTHBL is implemented through the CBL/XBL system and uses the same query tools, but as its expiration interval is longer than the CBL/XBL, it is possible for an IP to be listed by the AUTHBL and not the CBL/XBL, and the CBL/XBL lookup/removal page won't work for these. The Spamhaus Blocklist Removal Center can detect this issue and direct you to the right place.
Knowledge base on how to investigate persistent listings:
First, use the lookup page to look up your IP address. In a number of cases, you will get specific information related to your listing, and you should follow those instructions first. The following is more general instructions.
If this IP address is that of a Network Address Translation (NAT), or Port Address Translation (PAT) firewall, router or gateway, click here, and carefully follow the instructions. Insecure NATs are probably the leading cause of ALL CBL listings.
If this IP address is your personal computer, you must carefully check your machine for viruses, spyware, adware, open proxies and trojans and remove them. More information on scanning
If this IP is dynamically allocated, click here
If you have a wireless network/hub, see the same link as above.
If this IP address is really that of your mail server, click here
If you're being blocked with something other than email, click here
Did you get blocked when you tried to send email to us? Click if yes
If you sent email to the CBL, and got no response, chances are that you are running some sort of challenge/response filter of your own, your server blocked our email to you, or, your provider blocked your email to us without indicating that it did.
We endeavor to answer all email, so if you don't get a response within a day or two, we recommend resending your query via a freemail service such as hotmail.
The CBL team does not answer C/R challenges, so if you're using C/R, either pre-approve email back from us, or use another account.
No. (Except the standard test entry of 127.0.0.2)
If appropriate, you may wish to consider implementing your filtering in such a way that individual users can opt-in or out of filtering.
Generally speaking, we prefer users to use the SpamHaus DNSBL system to get access to the CBL, instead of the CBL directly. This has a number of benefits including more DNS servers answering queries (hence less chance of overload/delay on queries) as well as being able to query all of their DNSBLs in one query. The CBL is wholly included in (and in fact is the largest part of) the Spamhaus XBL subzone.
We recommend that you use the zen.spamhaus.org zone, see that link on how to use it.
If you use the CBL directly (or via the XBL), you should only check the IP address of the machine that connected to your mail server. Going any further back into the Received chain is officially unsupported, and will usually yield unacceptable numbers of false positives (in excess of 50% in some cases).
This is also true of _most_ DNSBLs (much of SORBs, Spamhaus PBL, WPBL, SpamCop, Barracuda BRBL etc) that tend to detect or list IPs that are likely to be spambots. Spambots don't relay through other mail servers. Hence, going back up the chain farther than the IP that connected to your mail server is unnecessary and will generally yield unacceptable numbers of false positives.
A few DNSBLs list what might call "IPs owned and operated by a spammer". Eg: Spamhaus SBL and CSS listings of snowshoers. You probably don't want to hear from those IP addresses no matter how they got to you. Those DNSBLs are appropriate for use in deep header parsing.
See also the FAQs on PBL and XBL usage at Spamhaus.
The XBL is intended to be useful in environments where you can use DNSBLs to check the URLs in email. For example, SpamAssassin's SURBL/URIDNSBL mechanisms. The following code snippit shows how to add SBL & XBL to SpamAssassin. Don't use PBL or Zen - some admins PBL-list their webservers and name servers because they don't send email, and thus using the PBL or Zen will incorrectly tag email because of URIs.
uridnsbl URIBL_SBLXBL sbl-xbl.spamhaus.org. TXT body URIBL_SBLXBL eval:check_uridnsbl('URIBL_SBLXBL') describe URIBL_SBLXBL Contains a URL listed in the SBL/XBL blocklist score URIBL_SBLXBL 4
Note: Current SpamAssassin only checks the IP addresses for the name servers of a URI's hostname. It will be better if you check the IP addresses of the hostnames too.
We believe that an effective spam filtering system is a hybrid of a number of techniques, you should never put all your eggs in one basket. See Effective Spam Filtering for an excellent discussion of modern spam fighting techniques along with other tools.
In addition to the excellent SpamHaus SBL, XBL and PBL subzones, here are a few other DNSBLs that you may wish to consider. It is extremely important that you evaluate them according to your needs. Some of these lists are NOT appropriate for certain environments.
Before using DNSBLs, we recommend becoming familiar with the DNSBL lookup tools on MXToolBox.
Jeff Makey provided a useful Blacklists Compared page, but it has not been collecting any new data in several years.
Only those DNSBLs we have personal experience with are listed here. We have good relationships with many of them, and in some cases share intelligence. While reading these, consider your options - they can either be used in a full blocking mode (a DNSBL hit means the email is blocked), or, as part of a scoring system (a DNSBL hit plus other "scores" are required for a block).
RFC6471: Overview of Best Email DNS-Based List (DNSBL) Operational Practices can be used as a guide on how to select DNSBLs.
We identified that PSKY was pirating Spamhaus DNSBL listings (and possibly other data) via unauthorized access to the infrastructure of one of Spamhaus' partners. PSKY's access to Spamhaus/CBL data has been shut off (March 23, 2017). It is not clear that PSKY is listing anything anymore.
It is recommended that users of PSKY re-evaluate their use in light of the above, and RFC6471 (link above).
The false positive rate of the BRBL is rather higher than the above lists. BRBL is also quite unhelpful in the face of FPs or other support issues. Therefore we don't recommend its use.
FYI: making sense of its web site is a bit difficult.
APEWS is reportedly blocking 2/3rds of all useable Internet IP space.
APEWS false positives in most situations are extremely high, and it should not be used except in some very specific circumstances (eg: single user systems via scoring). The main reason we mention APEWS is that several online DNSBL lookup services query APEWS listings, and it tends to alarm listees and cause long flamewars on the only places that people can find to discuss them (eg: news.admin.net-abuse.email), with no useful result. APEWS provides no mechanism for appealing listings, and we believe that is not best practise for DNSBL operation.
As far as we can determine, few (if any) mail servers actually use APEWS, so, an APEWS listing is largely meaningless. Getting out of APEWS is very difficult, and APEWS can just about be completely ignored as being irrelevant.
Note that APEWS appears to be back in operation, and is bragging about a .5% false positive rate. A FP rate that high we consider completely unacceptable.
New Note as of Sept 2018, APEWS appears to be on auto-pilot. The last update to their web pages appears to be April 2014, reporting a significant database/zone consistency problem. In particular this last quote from their blog doesn't exactly inspire one with confidence over four years later:
...but now we can see several days delay in this dataset rebuild. We have also noticed that the size of the database has increased a lot in recent months which may have something to do with it. We can't be sure that the live dataset actually reflects the recent edits, probably not.
In some cases it may be desirable to use a DNSBL that lists certain regions of the world - for example, if you don't need or want to correspond in email with anyone in China, you can use a DNSBL specifically designed to list all IPs in China.
There were a number of these lists, the best known is korea.services.net, but they only have a list for South Korea, and frankly, South Korea hasn't been an "issue" in years.
Since the time this FAQ page was written, other than korea.services.net, as of August 2018, all of the country-centric DNSBL systems appear to have shut down, in particular:
The current state-of-the-art appears to be using formal "geoip" solutions, such as the Mail::SpamAssassin::Plugin::RelayCountry2 module in SpamAssassin. The RelayCountry2 plugin relies on static tables produced by MaxMind. MaxMind permits you to download the tables once per month for free, more frequent download (more timely awareness of changes) is a commercial product. SpamAssassin's implementation seems particularly nice in that it does the downloads itself and includes the country in its Bayesian calculations, and it will "learn" itself what scoring to apply to each country.
If you're not running SpamAssassin, the most straightforward route is to download from MaxMind (or some other geolocation service) and generate your own zones suitable for your infrastructure. A local instantiation of rbldnsd is one approach that will work with any mail server that can do DNSBL lookups. This gives you the additional flexibility to in some cases score/block by province/state/city. And sometimes even building.BE AWARE that if you use such a service as a "one-strike your out" system (instead of scoring), you will get very little if any email from these regions. Secondly, even the RIRs (the entities responsible for assembling the information in the first place) aren't immune to getting country-of-origin/province/state/city wrong, and that's where almost all geoip/country-specific solutions get their data from. The data quality is quite good, but it's not perfect. This gets considerably more error-prone at province/state/city level. [At the date of this writing, Maxmind gets my city wrong. Some of the other Geo-IP solutions get the province/state wrong. None of them have me geo-located correctly within 100km. There are good reasons for this in my case, but ...] Use them at your own risk. Or in a scoring system.
If you are using the Spamhaus Zen, sbl-xbl or xbl lists, you do not need to do this.
Note if you are using the sbl-xbl list, we recommend that you switch to the Zen list. The sbl-xbl is obsoleted by Zen.
See previous section on "DNSBL Setup Recommendations".
|Query text:||URL to lookup page with IP filled in|
DO NOT set your DNS server to be cbl.abuseat.org - use your ordinary DNS servers. It's the name of the zone and the name of this website, but NOT the name of the DNS server.
Make sure you read the CBL Terms and Conditions.
The documentation for your mail server will indicate whether it supports DNSBL queries and if so, how to configure them. The CBL is a standard IP-based blocking list just like the many others available.
If possible, please configure your mail server to use the TXT record of entries in the rejection message. Otherwise, the recommended URL to include in rejections is https://lookup.cgi?ip=x.x.x.x with the IP address of the sender filled in. Always include the IP address of the sender in rejection messages.
If you have a question not answered in this FAQ or are getting caught by repeated listings that you're unable to diagnose, please contact us for assistance. We'll do our best to help - we are committed to doing that.
It is important that you follow and understand the results of a CBL lookup carefully before you contact us. If you don't follow those instructions, resolution may be delayed.
We expect you to have looked up your IP on our lookup page, read and understood the instructions, and attempted to solve the problem BEFORE contacting us.
Our email address is [email protected].
It's better to contact us about persistent listing problems than asking in other fora (such as the news.admin.net-abuse.email or news.admin.net-abuse.blocklist Usenet groups or online tech forums). The CBL is very much different than most other DNSBLs, and the advice you will get from sources other than our online information or via email from us will almost always be very very wrong. We occasionally run across such discussions (eg: via web searches while assisting someone else), usually long after the fact, and it's astonishing how wrong the advice/commentary usually is. When seeing such, we can only shake our heads and feel sorry for the person who got bad advice, because it's usually far too late for us to help.
If you do not get a response from us within 24 hours (we're usually much faster than that), please try resending your email from another account, such as a freemail account on hotmail. Your email to us may have been silently dropped by your ISP without it telling you, OR, your spam filters may have blocked our reply.
NOTE! If your mail server does SAV ("sender address verify" or "sender address verification callouts"), our mail server will probably NOT "complete" the verification, because our mail server has a long banner delay. Which means that our reply will bounce. You will either have to whitelist our mail server from your SAV, or arrange for our reply to go to some other mail server (eg: a gmail account).
The above also applies if your mail server has short (non-RFC-compliant) SMTP timeouts.
We answer all emails. If you don't get a reply, it got lost.
We view the CBL/XBL as a collaborative effort. We are always on the hunt for improved information on how to protect our users, and how listees can secure their systems to prevent being taken over.
If you know of, or have written, a blog or article or tool that helps find infected machines, disinfect infected machines, or protects machines against future infections, whether they be general, or aimed at a specific risk, please let us know at the email address given above. Good tips we'll include in our web site.
But first, see the next point:
Except where otherwise explicitly noted, the CBL/XBL does not endorse any commercial organization or any paid product, service or tool from them. Preference is always for free public information and tools that a system administrator/end-user can use to help themselves.
Where multiple commercial organizations do offer good free information and tools, we deliberately distribute our references amongst the different vendors so as to not imply favoritism for any vendor. However, some vendors will naturally appear more frequently because they have broader consistent and useful information.
Visitors to our site are presented with what we believe to be the best information possible to help them secure their computers and networks. We will gladly accept suggestions from reputable commercial organizations in this industry for tools and other information, but this does not mean that we will automatically accept them for external reference.
RFC5782: DNSBL Blacklists and Whitelists contains the DNSBL protocol standard (informational) by the Anti-Spam Research Group of the Internet Research Task Force (IRTF), all part of the IETF. This can be assistance in a deeper understanding of how DNSBLs work.
RFC6471: Overview of Best Email DNS-Based List (DNSBL) Operational Practices (DNSBL BCP) contains a DNSBL operational policy document, companion to RFC5782, also a product of the ASRG/IRTF.
The CBL provided commentary to the authors of these documents. The CBL fully supports the DNSBL BCP and is believed to be in full compliance.
From time to time we encounter claims that we charge a fee for delisting, or that certain "consultants" claim to be able to remove a CBL listing for a fee.
This is not true. The CBL NEVER charges fees. The only way to get out and stay out of the CBL is to correct the problem that got an IP listed in the first place.
The CBL believes that charging a fee for delisting is, in effect, a protection racket with all the negative connotations that implies. Even if it isn't intended that way, it causes more problems than it solves.
We will never charge a fee for delisting.
Spamhaus is one of the most respected anti-spam organizations in the world.
The CBL is now a division of Spamhaus
Note that public redistribution of the CBL in any form is prohibited without prior authorization from us. See our Terms and Conditions, last item. This restriction "survives" the XBL redistribution of the CBL, and as such, any redistribution of the XBL unauthorized by Spamhaus is also in violation of the CBL terms and conditions.
There are two exceptions:
The CBL is copyright © 2018, all unauthorized copying is prohibited.
All external web pages that the CBL pages reference are copyright by their respective owners.
It is exceedingly unlikely that the CBL will ever authorize any other public redistribution over those already in force (spamhaus.org and senderbase).
dnsbl.net.au used to have redistribution arrangement with the CBL, but dnsbl.net.au shut down in April 2009.
The Spamhaus XBL (or SBL-XBL or Zen) is a full superset of the CBL, and you SHOULD NOT USE BOTH DNSBLs at the same time. In fact, for most administrators, we strongly recommend that you use Zen instead of the CBL directly.
If you are a large organization doing several hundred thousand emails or more per day, in order to reduce DNS query loading, we recommend that you use a rsync feed of the XBL. While this is ordinarily a commercial service, in certain public interest situations, a subscription may be free.
If you are a large ISP, or sell spam filtering services, we believe that you should be supporting the anti-spam effort by purchasing a paid-for rsync feed from Spamhaus, rather than getting the CBL directly from us.
As of April 2, 2013, the abuseat.org domain was wholy acquired by the CBL, after it having been "loaned" for our use since 2003.
<< Back to the CBL home page. Updated 2017/11/10