Frequently Asked Questions

Query Service or Rsync Service, which should I choose?

The choice of which service to apply for, Datafeed Query Service or Datafeed Rsync Service, depends on how big your network is and how high your email traffic is.

If you have 1,000's of users and very high email traffic or you want to serve our DNSBL data locally to multiple mail servers on your network, we recommend you use the Rsync Service. The Rsync Service requires some setup on your end (requires you also set up Rbldnsd) and usually a dedicated server (although you can also run Rbldnsd on the same machine as your DNS server). So only take the Rsync Service if you understand why you want Rsync/Rbldnsd.

If your network is medium-sized, small, or you want a non-complicated solution with no software to install, the best choice is the Datafeed Query Service. With this service the Datafeed Service Group assigns you a unique account ID and access to a set of private Datafeed Query Service servers. The Query Service is very simple to install (it should take you literally one minute to set up on most moderns mail servers). It requires no extra software or servers.

Instructions for using the Datafeed Query Service with Microsoft Exchange 2007 (PDF. 166 KB) have been published by MXTools.

Both services perform the same. You can switch from Query Service to Rsync Service later on if you find reason to need Rsync Service.

Datafeed Query Service: possible problems with Cisco ASA

We received reports from users that the Datafeed Query Service is not working behind some Cisco ASA appliances configured with DNS inspection turned on. Since DNSBL A queries are rather similar to PTR queries (reverse DNS), it may be possible that this issue is related with the CSCue87407 bug reported by Cisco and affecting ASA 9.0(2), 9.1(1) and 9.1(2). See also this discussion.

Datafeed Query Service: I have problems with Kerio Connect

When using the Datafeed Query Service in a Kerio Connect installation, it is crucial that the "Ask the blacklist DNS server directly" option is NOT selected, otherwise Kerio Connect will not be able to do lookups.

See also this Kerio forum topic.

Datafeed Rsync Service: How do I set this service up?

The Datafeed Rsync Service can be installed on nearly any Unix-based machine (Linux, FreeBSD, OpenBSD, NetBSD, Mac OS X, Solaris, Tru64, HPUX, AIX, Irix, etc.). The memory and CPU requirements are usually modest, so that old PCs are typically up to the task. An Internet bandwidth of at least 512 kbps is required.

Datafeed Rsync Service utilizes 2 free programs, Rsync and Rbldnsd. Both of them are usually also available as packages for the various operating systems. Nowadays, rsync is often part of the base distribution.

Spamhaus supplies an Installation Manual with the Datafeed Rsync service, giving instructions for how to install and set the Datafeed up. The manual covers:

  1. installing rsync
  2. installing rbldnsd and prepare it for running
  3. configuring your local DNS resolver
  4. configuring your mail servers

The manual is supplied only after you apply for the Datafeed service, or a free trial of the datafeed service, and it is linked from the account page on the SpamTeq.com web site.

Datafeed Rsync Service: With what domain should I connect the zones locally?

While it is technically possible (by using forwarding in your DNS resolver) to run the sbl, pbl, xbl, zen, dbl local zones under the spamhaus.org domain, we recommend to use a different domain for your local zones. By doing so, you will be sure that queries really stay local rather than being sent to the Spamhaus public servers as a consequence of a configuration error.

The preferred solution is that of running the Spamhaus zones under a local domain unreachable from the rest of the Internet. For instance, you can use a local domain called "dnsbl", referring to the zones as "sbl.dnsbl", "pbl.dnsbl", "xbl.dnsbl", "zen.dnsbl", "dbl.dnsbl" in your mail servers. With a Bind DNS resolver, this can be done be defining in named.conf

zone "dnsbl" {
        type forward;
        forward only;
        forwarders {
                1.2.3.4;
        };
};
						

where 1.2.3.4 is the IP address of the rbldnsd server (on the same or on another host).

Datafeed Rsync Service: How can I use Rbldnsd and BIND together?

You can run rbldnsd on the same system/IP as an existing BIND 9.x DNS server acting as resolver in your network. For instance, the rbldnsd option "-b 127.0.0.1/54" tells rbldnsd to listen on the IP address 127.0.0.1, UDP port 54.

You then configure the BIND server your mail server(s) use, to forward queries for the Spamhaus DNSBLs to rbldnsd by adding the following to named.conf:

zone "dnsbl" {
        type forward;
        forward only;
        forwarders {
                127.0.0.1 port 54;
        };
};
						

This port forwarding option is not supported in BIND 8.x. (For BIND 8.x, you need to dedicate an IP address to rbldnsd and configure BIND to not listen on that IP - by telling it which IPs to listen on).

Datafeed Rsync Service: What kind of rbldnsd dataset types should I use?

Rbldnsd defines a few different dataset types. To optimize performance and memory usage, we recommend Datafeed users to choose ip4set for SBL and SWL, ip4trie for PBL, and ip4tset for XBL.

However, using ip4tset will result in a return code 127.0.0.4 for all XBL listings. In the majority of cases this is acceptable, but if you need to distinguish between the different XBL return codes you should use ip4set also for XBL.

DBL and DWL must always use the dnset dataset type.

Public mirrors are required to use ip4set for all the IP zones, and dnset for DBL and DWL.

Datafeed Rsync Service: On the rsync server I don't see a combined zen zone file...

The combined 'zen' zone (which we publish to reduce the global DNS traffic on our public nameservers) does not exist as a file. The sbl, pbl and xbl files can be combined into a single "zen" zone by running rbldnsd in this way:

rbldnsd (options) \
	zen.dnsbl:ip4set:sbl \
	zen.dnsbl:ip4trie:pbl \
	zen.dnsbl:ip4tset:xbl \
	...
						

That is, the combined zone is built 'on the fly' by rbldnsd from the three files. Datafeed users may choose to run the individual zones, the combined zone, or both. Since all queries are local, the performance advantage of the combined zone is usually negligible unless your mail traffic is really massive.

The dbl zonefile must not be included in zen: it is a domain zone, not an IP zone, and should never receive queries relative to IP addresses. The two whitelists swl and dwl must also, of course, be individual zones.

How do I test to see if my setup is working?

Once you have set up/configured your mail server (or tools such as SpamAssassin) to use the Datafeed service, you can test to see if the Spamhaus blocking is working by sending an email (any email) to: [email protected] (you must send the email from the mail server which you wish to test). The Crynwr system robot will answer you to tell you if your server is correctly blocking SBL-listed IPs or not.

Similar tests are available for PBL and XBL.

I need to test the Datafeed service first, before ordering it

If you're not sure how well the Spamhaus DNSBLs will perform to reduce incoming spam on your network, and your email traffic is too high to test using our free public DNS mirrors, you can test the Datafeed service offered by Spamhaus Technology for 30 days, free of charge and with no obligations.

Details are available on the Spamhaus Technology web site.

What is the application process?

The application process is designed to allow organizations to initiate an application without committing to taking the service or making a payment until they are first satisfied with the service and have agreed to the service terms. The process is:

  1. Use the Free Trial form on the Spamhaus Technology web site to request a 30 day trial of one or more of our services.
  2. Fill out the Datafeed Application Form.

Your application is then submitted to Spamhaus for approval (Spamhaus wants to ensure it does not grant access to its data to organizations involved in spamming). This can take a few hours. Once approved, your Application is handled by an Authorized Datafeed Vendor who will create a Datafeed account for you and email the account information to you. In your Datafeed account area you will then find installation instructions, a Service Agreement (for you to agree), payment options, and technical support contacts.

(Note that you contract the Datafeed Service directly with the Authorized Datafeed Vendor, not with Spamhaus Project, as Spamhaus Project does not have any commercial activities.)

I need to see the Service Agreement contract text before applying for the service

Spamhaus wants to ensure that its data is only given to reputable qualified organizations, we therefore need to know who you are before offering you access to Spamhaus data.

The Datafeed Service Agreement is between you and a 3rd party contractor (Authorized Datafeed Vendor) authorized by Spamhaus to sell and manage the Datafeed service. The Authorized Datafeed Vendor's Agreement therefore is only made available to you once you first complete the Datafeed Application Form which is first vetted by Spamhaus to ensure the application for access to its data is acceptable to Spamhaus.

Completing the Datafeed Application Form does not commit you to anything.

Who do I contract the Datafeed service from?

The Datafeed service is sold, supplied and managed by Authorized Datafeed Vendors, independent resellers of Spamhaus Technology (UK), licensed by The Spamhaus Project to include realtime Spamhaus data in a Datafeed service format.

You therefore contract the Datafeed Service directly with an Authorized Datafeed Vendor and not with Spamhaus Project (as Spamhaus Project does not have any commercial activities). The Authorized Datafeed Vendor is also responsible for first-line technical support.

The Spamhaus Project retains responsibility for initial vetting of your Datafeed application (to weed out any suspect applications by spam firms attempting to gain access to the data and to disallow supply of the service to networks engaged in spam service or support activities).

Why is there a charge for this service?

In 2004 Spamhaus introduced the Datafeed service to replace the former free but simple Rsync service. The change from free to subscription-based became necessary in 2004 in order to handle the exponential growth of the service. Thousands of networks take synchronized transfers of Spamhaus DNSBL data, it is therefore a resource-intensive service that demanded its own separate and independent management, servers and support infrastructure.

To guarantee the availability of the service, provide support and maintain the equipment and redundency behind it, Spamhaus decided in 2004 to move the provision of the service to authorized Datafeed contractors who manage, sell and support the Datafeed service.

The announcement of the service change, and reasons for moving it to a charged annual subscription, was made in Spamhaus's 2004 "A Blueprint for the future" document outlining the future of Spamhaus: Futureproofing Spamhaus.

Does the pricing change?

Yes, approximately every two years the service price may be adjusted in line with inflation and market value.

I don't need this service, I got a Barracuda instead!

The major part of spam filtering done by appliances such as the Barracuda is in fact DNSBL filtering using among other things the Spamhaus DNSBLs and other data from Spamhaus. If you are using any Spamhaus lookup in any part of a Barracuda or similar spam filter appliance you must ensure you have a current Spamhaus Datafeed subscription from a Spamhaus Authorized Datafeed Vendor.

If you do not have a current Spamhaus Datafeed subscription, then you are abusing Spamhaus's public DNSBL servers. If your email volume is big enough that you need a Barracuda or similar spam filter appliance, then you certainly CAN NOT use Spamhaus's free public DNSBL servers.

Because Spamhaus's public DNSBL servers get heavily abused by companies with spam filter appliances, mostly Barracuda appliances, Spamhaus has implemented a control system on the public DNSBL servers to flag and firewall such users and Barracuda appliances in particular.

Please ensure that if you are using Spamhaus DNSBLs in any part of your corporate spam filtering setup, you have a Spamhaus Datafeed subscription in place first.

Service Restrictions

Spamhaus evaluates every Datafeed service application to ensure the applicant is bona fide and is not involved in the provision or support of spam services.

The Datafeed service is refused to any ISP with excessive SBL listings, bad enough to be listed in the Spamhaus 'TOP 10 Worst Spam ISPs' chart. Spamhaus considers an ISP whose spam control practices are so bad that the ISP is listed in our "TOP 10" to be "knowingly facilitating spam operations (for profit)". The consensus is that such ISPs should be putting far greater efforts into reducing the spam problems they cause and that it is hypocritical to attempt to reduce incoming spam to their own customers much of which is caused by them in the first place.

Get in touch


Latest News

Join us at Infosecurity Europe, London Olympia

Spamhaus Technology will be presenting the latest trends to beat spammers and we’ll be showcasing botnet choking threat intelligence at Infosecurity Europe.

Read more

Join us at World Hosting Days, Germany

Spamhaus Technology and partner MXTools will be showing how to beat the scourge of the hosting industry at World Hosting Days, Germany March 28-30th.

Read more

Connect with Spamhaus Technology

Keep up to date with the latest news at Spamhaus Technology.