These are the terms and conditions for using the CBL/XBL. You are given permission to use them as long as it complies with these guidelines. Violation of this may result in revoking permission for you using the CBL/XBL.
WARNING: All of the restrictions documented in these terms and conditions apply equally to using the CBL portion of the XBL, SBL-XBL and Zen from Spamhaus. Note that the PBL has similar technical restrictions.
The CBL is operated by a group of computer security, spam and virus professionals, dedicated to developing and maintaining an anti-spam and anti-virus DNSBL of the highest possible quality and reliability, that large organizations can use with confidence.
That said, use of the CBL is at your own risk.
The CBL is primarily intended for use with email inbound to your domain's MXes. We generally prefer that email be rejected with a pointer to our site, including the listed IP, so that listings can be resolved and the problem cleared.
The CBL provides DNS TXT records that can be used directly in your rejections.
As a matter of best practise, you MUST NOT bounce (accept then queue up separate email to the sender), but instead reject (issue SMTP rejection inline). This largely prevents your filters mail bombing the victims of forgery.
If you want to use the CBL to block protocols other than SMTP on port 25 (ie: IRC), realize this is officially UNSUPPORTED by the CBL team.
We appreciate that this is a useful thing to do, but you MUST NOT mention the CBL as being the source of a block and you should be prepared to provide "first contact" assistance for users encountering a block and potentially whitelisting on your service.
It should be absolutely clear that there will be a potentially large number of affected users who, through no fault of their own, will NOT be able to delist due to NAT, dynamic IPs, or other similar issues. Anyone using the CBL for blocking IRC, blog comments or whatever needs to know that they will get collateral damage and they will either have to manage that themselves with whitelisting or live with it.
Those administrators thinking of using CBL (or XBL) from a web server to filter out "dangerous clients" will want to consider the use of mod_spamhaus_new. Unlike the standard "mod-spamhaus", mod-spamhaus-new supports whitelists.
It's a very bad idea to use the CBL on "full Received line traverse". Use the CBL only on the IP that attempts to connect to your mail servers. Trying to parse Received lines further back is seldom useful, and will yield a lot more false positives than on peer addresses only.
This is UNSUPPORTED use of the CBL. If you feel you have to do this, you MUST NOT reference the CBL in your rejection messages.
If you want to use the CBL to derive listings of other IP addresses than we explicitly list, you MUST NOT reference the CBL in your rejection messages.
For example, blocking /24s due to "greater than some threshold number of CBL entries" is actually a very effective anti-spam/virus technique (works much like a DUL), but you MUST handle complaints from users for IPs that the CBL didn't list, and potentially be prepared to whitelist individual IP addresses locally. Consider: if you blame us for a block for an IP address that we do not list, there's NOTHING we can do to assist, and the user is very unlikely to be able to "fix" the multiple CBL listings that caused their block either. Much frustration.
If you plan on using the CBL in such a way that can block your own customers relaying their outbound email through your mail servers, there are two different situations that should be handled differently. One of them is where you're some sort of email service provider or for roaming users - your user's email is traversing the Internet to get to your relay. The second is where these users are on your own network, and their email only goes through your LAN to your outbound relay.
Recognize that your users should be encouraged to use your outbound relay server.
Recognize that most of the compromises that we catch do NOT use your user's relay server settings.
Thus, by applying the CBL to your relay server for outbound email, you will be impacting legitimate email sent properly. You really don't want to discourage that. You'll even prevent your user contacting us! You can guarantee legitimate email by requiring that your users use SMTP AUTH or some other form of sender authentication, better still, not on port 25 (ie: port 587 SMTP SUBMIT).
"We block the connection before we give the user a chance to authenticate" is _not_ in compliance with this section - in fact, it's the whole point of this section!. If you're using some port other than 25 for end-user submission (such as the standard port 587 SUBMIT port), you simply don't apply the CBL to such connections, AND, force the user to authenticate. Only if the user doesn't authenticate do you refuse the email. If you force users to submit through port 25, you should delay rejection _until_ the user has a chance to authenticate and only reject if the user fails to do so.
In the first case (outbound email traverses the Internet to get to your relay), you MUST NOT apply the CBL to connections that do SMTP authentication (or some other technique that proves that the SMTP connection is from your customer). These will often be the NATs for wireless POPs or airport lounges or hotels. Because of this a roaming user (or us) is relatively unlikely to be able to contact the right people to get the listing fixed properly. So the user will just be very frustrated (and mad at both you and us).
In concrete terms: you should offer authenticated inbound email access on port 25 or port 587 (or some other port), and you MUST ignore CBL listings of connections that have authenticated. If you only allow authenticated connections on port 587 (or other non-port 25 port), you do not need to implement CBL checking on it at all.
As a corollary, you must not use the CBL to block external connections to your smarthost (technically "MSA" - Mail submission server) by your own users.
In short: implement SMTPAUTH/STARTTLS for roaming users, and do not apply the CBL to such connections.
In the second case (outbound email traverses your LAN to get to your relay), all of the argument for the first case above still applies.
However, since you likely control the IP address that's listed, this becomes an important opportunity for your support staff to disinfect the customer. Many providers do exactly that, and this is very good for the Internet. If you do choose to use the CBL in this fashion, you MUST refer your user to your support staff in the rejection, NOT the CBL.
If, inspite of 3, 4, 5 or 6 above you still want to use the CBL in an unsupported fashion (eg: block blog, web, IRC access, block on full received line traverse, derive other blocking heuristics, or block MSA submissions), you must take full responsibility yourself for the decision.
This means that you must remove all mention of the CBL (or Spamhaus) from any error messages or communications the user may see, and direct all support questions to your own support infrastructure.
The CBL assumes no responsibility whatsoever for the CBL being used in an unsupported/not-recommended fashion.
Access to the CBL/XBL databases is available, watch this space for more detail.
For the most part, CBL listings are because of virus infections of some sort or inadequately secured machines. The CBL does NOT accuse the owner of the IP as being a spammer. They probably aren't spammers, they're just hacked. Thus, termination of an account simply for a CBL listing is very rarely justified, unless they're unable to secure their machine.
Updated:
See the faq for further technical information on how to use the CBL.
The following three points apply also apply to usage constraints on the CBL.
New:
Any and all existing rsync downloads of the CBL are being transferred over to the Spamhaus distribution system. Some organizations are still entitled to free downloads of the CBL. Please see Details will be available shortly.
New:
Query limits: In the past, the CBL has not imposed query limits for normal blocklist usage. Now that the CBL is a division of the Spamhaus Project, and that usage of the CBL has become ubiquitous over the entire Internet, this has had to change somewhat. The CBL is still firmly committed to free access to small and medium sized organizations. Usage is being monitored, and it may become necessary to implement usage limits more in line with the Spamhaus Project. In the meantime, you may wish to familiarize yourself with the Spamhaus DNSBL Usage Terms and contrast "Free usage" versus "Professional usage".
The CBL lookup and removal facility are intended towards manual access by a normal web browser only. Any attempts to use the CBL lookup or removal pages in an automated fashion is strictly prohibited, and may result in listing of the offending IP address.
Automated retrieval of the CBL/XBL's statistics and other general information is allowed, but we would ask that you retrieve such data no more than once per day.
The CBL is copyrighted (see footer notice), all unauthorized copying is prohibited
Note: You MUST NOT publish information derived from the CBL zone outside of your own local organization (ie: via publicly available DNS zone of your own construction, or any other form of redistribution of the list) without prior authorization from us.
At present, the only authorized republications of the CBL are through SpamHaus XBL (via SBL-XBL and Zen), Senderbase, and McAfee. Any other public republication of the CBL is strictly prohibited.