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.
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.
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
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.
[See the last two paragraphs of 5 above]. The best way to
use the CBL to find (so you can disinfect) infected machines
in your network is to rsync the CBL periodically and scan
it for entries in your IP ranges. This is better than waiting
for your users to encounter problems with sending email.
Many ISPs do this, and it is "good for the Internet".
The "grepcidr" tool (google for it) is quite useful in this
In some cases you'll clearly need timestamps so you can
identify who was using the IP at the time of detection. You
can get those by going to our web site and doing a query
for the listed IP. As a security measure, we round off the
detection time to the nearest half hour, but if a more
accurate timestamp is needed for an individual listing,
contact us. But we'd prefer you didn't have to.
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.
See the faq for
further technical information on how to use the CBL.
The following two points apply also apply to usage constraints on
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
for further details and registration.
Query limits: In the past, the CBL has not imposed query limits.
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
may have to change somewhat.
The CBL is still firmly committed to free access to small and medium
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
The CBL is copyright © 2003-2015, all unauthorized copying
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
The CBL and web pages are copyright ©
2003-2015, all unauthorized copying is prohibited