Tag Archives: blacklist

Blacklist Monitoring for Cloud Hosting

Originally Posted on Blacklist Monitoring with RBLTracker.

Since our inception, we’ve helped thousands of companies and individuals, from all around the world, stay on top of day-to-day threats related to their email and websites. Recently, with the addition of our Facebook Threat Exchange monitoring, we’re helping those same customers battle social media related threats.

Some of our earliest customers have been cloud hosting and cloud computing companies- companies that provide the backbone of the Internet as we know it today.

Cloud Hosting Providers

One specific challenge with this type of company, is the sheer number of IP addresses and domains to monitor, and the regular re-use of these IP addresses. The last thing you want, is a brand new customer getting an IP address that is already blacklisted because of something the last owner did.

Another key challenge, is making sure that resources are used “only as needed”. Let’s face it- you don’t want to pay to monitor hosts that aren’t being used- and you shouldn’t have to.

We offer a few key features that makes blacklist monitoring for cloud hosting providers, easier and more affordable.

IP Range Host Type

Normally customers add IP addresses and domains (aka “Hosts”) to the RBLTracker portal individually. If you have 10 to 15 Hosts, this isn’t really a big deal. You can add hosts using our bulk loader, or individually. You can also add Hosts as a range or CIDR block (x.x.x.x/y).

But what if you have thousands of Hosts to monitor? At some point it’s going to become unwieldy to provision, and impossible to manage.

To support this, we built a custom “IP Range” Host type. This lets you add IP addresses as a range or CIDR block, but rather than thousands of IP addresses showing under your account, a single Host entry is shown. Our system will still monitor every single IP address individually– but the full block of IP addresses can be managed as a single entry.


So whether you have a few /24’s or a whole /18- you can easily manage the full IP block with ease.


API Provisioning

Loading all your IP addresses into the system is great, but what if you only want to monitor a sub-set of those hosts? Or if you only want to enable monitoring for hosts that are currently in-use?

Several of our customers have opted to integrate with our web-based API, to provision monitoring on IP addresses as they’re allocated to their customers. That way only active IP addresses are being monitored. This ensures that you’re only paying for monitoring that matters- that will actually impact your business or your customers.

The RBLTracker API is easily integrated into any provisioning or monitoring platform, with just a few simple lines of code:

# wget --post-data="type=rbl&name=Test&host=" -qO- https://rbltrack.com/api/host/add.json?api_token=x

    "status_code": 200,
    "status_message": "Hosts added successfully.",
    "data": [
            "id": "37c46a725dd8adab28d35b9f200c198d",
            "host": "",
            "name": "Test"
    "version": "2.0"

Easily enable monitoring on a Host when it’s allocated to a customer, and then disable it when it’s de-allocated- it’s a simple as that.

Contact Groups

When we identify an issue with any of your Hosts, we’ll immediately notify you via several different notification methods. These contacts can be broken down into custom contact groups, and assigned to Host. The end result, is that you can have a unique contact for every host under your account:


Cloud Hosting companies can optionally send alerts directly to their customers, notifying them about issues with their IP addresses and domains, and alleviating some of the burden from their network operations staff.

We regularly add new features and tools to make managing and provisioning monitoring services, easier and more effective for our customers.

What are Blacklists and How Do They Work? (Part 1)

Originally Posted on RBLTracker Blacklist Check Service

Real-Time Blacklists (RBL) are a simple but effective way for organizations around the world, to share the location (in this case, the IP addresses) of email systems that are reputed to send email SPAM.

The most common implementation of these lists are distributed via DNS, and referred to as DNS-based Blacklists (DNSBL). Distributing this data via DNS makes perfect sense; it’s a technology that already exists, and servers all already have access to. It’s fast, and the data (IP addresses and domains) is well suited for DNS.

Types of RBLs

There are hundreds of RBLs available worldwide, managed by hundreds of organizations and individuals. Most RBLs are free to use, some are pay-to-use, and they all have their own methodologies for compiling their databases, and their own processes for being delisted.

Two of the most common and reliable methodologies for collecting data for RBLs, are based on user input, or something they call a “honey pot”.

Crowd Sourced

RBLs based on user input are the most common, and often most reliable. This data is effectively crowd sourced. When an email recipient receives a SPAM message (assuming their system supports it), they can “flag this message as SPAM”. If enough recipients flag the same message as SPAM, the IP address of the sender will be added to the RBL database.

This is common in free email services like Hotmail and Gmail.

Honey Pots

Another common source for RBL data is something called a honey pot. These are basically email addresses that are never used for any legitimate email purposes, and aren’t owned by any end users. They simply exist out on the Internet in places where robots and SPAM aggregators collect email addresses.

Any email that comes to these addresses is by definition unsolicited, and considered SPAM, and will land you on an RBL.


Another type of RBL is the URI Blacklist (URIBL). This is used for distributing domain names of websites that are reputed to send SPAM or to be involved in phishing schemes. So this doesn’t just affect organizations that run their own mail servers, but anyone that has a website as well.

There are definitely RBLs that are more reputable than others; there are some that have no process for being delisted, and others where you have to pay to be delisted. In my opinion, the pay-to-delist RBLs should not be considered reputable, and should not be used by mail system administrators.

Stay tuned for Part 2 of this series, where I’ll talk about how these RBLs are used by organizations, and give you some real-world examples of how RBLs can help you combat SPAM.