How Are Blacklists Used? (Part 2)

Originally posted on RBLTracker Blacklist Check Service blog.

In Part 1 of our series we talked about what RBLs are, and the different types of RBLs. In this article, we’ll talk more about how they can be used by administrators to control the flow of SPAM into their networks.

How Are They Used?

Most mail server software can be configured to make requests against DNSBLs, and reject or accept mail, based on if the sending mail servers IP address is listed in the DNSBL. Or in the case of URIBLs, if a domain name or website URL found in the body of the message is listed.

Example

As a quick example, the Exim mail transfer agent (MTA) supports specifying one or more DNSBLs during the ACL processing of an inbound SMTP message.

exim_rbl

Exim will make a DNS lookup request on the sending mail servers’ IP address, and if found in the DNSBL, can reject the message with a specific error message.

The Postfix MTA allows administrator to add one or more DNSBLs using the reject_rbl_client configuration option in the smtpd_recipient_restrictions option.

postfix_rbl

You can also do a simple check on Windows, Mac, and Unix, using the command line nslookup tool. Simply reverse the digits in your IP address, and prefix it to one of the DNSBL host names.

So for example, if your IP address was 127.0.0.2 and you wanted to check the bl.spamcop.net DNSBL, you would do a DNS lookup on: 2.0.0.127.bl.spamcop.net:

manual_lookup

Check back for Part 3 of our series where I talk about how RBLs affect organizations, and why they can be an important part of your day-to-day administration.

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.

URIBLs

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.

RBLTracker.com: Now with DNSSEC and TLSA

The RBLTracker domain is now signed with DNSSEC, and we’ve published the website certificate fingerprint via a TLSA record (also known as DANE), so that you can be 100% sure you’re interacting with the RBLTracker servers. dnssec

This can be validated through the Verisign Labs Test Tool.

What is DNSSEC, and why do I care?

The point of DNSSEC is to provide a way for DNS records to be trusted by whoever receives them. The key innovation of DNSSEC is the use of public key cryptography to ensure that DNS records are authentic.

DNSSEC not only allows a DNS server to prove the authenticity of the records it returns. It also allows the assertion of “non-existence of records”.

What about DANE, what’s that all about?

DANE, or “DNS-based Authentication of Named Entities”, is a way for domain and website owners to publish SSL certificate fingerprints, so that visitors can validate that the certificate being used on a website is valid for that site.

Over the last few years, there have been several security breaches with Certificate Signing Authorities (CA’s)- companies that sign certificates that you use for your secure website- allowing the issuance of certificates for domains, not owned by the domain owners.

Using DANE, you can define exactly which certificate or CA is valid for your website, restricting the ability for a would-be hacker to masquerade as your website, by gaining access to your CA.

This obviously only makes sense in tandem with DNSSEC, as you need to validate that the DNS information providing the certificate fingerprint is valid, and not modified along the way.

How can I tell if a site is using DNSSEC/DANE?

Until there is more mainstream support for DNSSEC/DANE- for example, building support for it directly in the OS layer and in web browsers- there is a great browser plugin by cz.nic, that will show you when a site is protected with DNSSEC and DANE.

RBLTracker: Two-factor Authentication using Clef

clef2You can now log in to your RBLTracker account using secure, two-factor authentication using Clef.

Clef is secure two-factor authentication using your mobile device, with no passwords or tokens, and no personal data is shared between RBLTracker and Clef.

Simply download the Clef Mobile App, and then register your RBLTracker account with Clef from the Profile page of your RBLTracker account.

Once registered, you can log in and log out of the RBLTracker interface using your mobile device- it’s that easy! If you have any questions or comments about using Clef, please let us know @ info@rbltracker.com

Two-factor authentication is available to all RBLTracker accounts. Sign up Today!

Net_DNS2 Moved to GitHub

I’ve never been a bit fan of git- I’ve got used to using SVN over the years, and never saw a compelling reason to change- until now- that Google is shutting down the Google Code service- so I’m forced to move.

Luckily I can still keep using SVN with GitHub- I can put off actually using git for the foreseeable future!

The new Net_DNS2 repository is officially moved to GitHub:

https://github.com/mikepultz/netdns2