Using Real-Time Blackhole Lists (RBL) to Filter Email From Your Exchange Server

Many of today's spammers use multiple unsecured 3rd party SMTP servers to send large amounts of unsolicited email at a relatively low cost. One of the most effective ways to combat this growing problem is through the use of Real-Time Blackhole Lists (RBL, also known as DNS Black Lists or DNSBL).

A Real-Time Blackhole List is a Domain Name Server (DNS) that contains the IP addresses of SMTP servers that either originate spam, or are considered to be spam open relay hosts. One of the most common methods for sending spam, open relays are servers with insufficient security or other loopholes that allow anyone who knows how to tap into them, and use them for mass mailings of anonymous email.

RBL filtering operates on the IP address of the SMTP server sending an inbound email, reversing it and using it according to the RBL rule for a DNS look-up against the RBL DNS server. If the DNS look-up resolves to an IP address, the email is then considered to be spam.

Free vs. Subscription-Based RBLs

Each RBL fits some organizations better than others, however, so it's important to make sure the RBL lists you rely on match your needs and circumstances. One such question is cost vs. availability.

Free RBL servers, such as http://www.spamcop.net and http://www.dsbl.org , are available on the Web at no cost. During periods of peak email traffic, however, free RBL servers can become very busy, and will slow down or even fail to respond to DNS queries.

Subscription-based RBL servers such as http://www.mail-abuse.org/, http:// www.postfixgate.com/ and http://www.maildeflector.net/ are available to subscribers for a fee. These RBLs make DNS queries and DNS transfers available to the local DNS server of paying customers. RBL queries are then made to the local DNS server, thereby removing the dependence on public RBL servers - or Internet bandwidth.

RBL features for improved speed, bandwidth and administration

RBL servers must also be self-updating in order to ensure they keep up with the latest instances of reported or suspected spam relay hosts. In addition, to realize enhanced speed, reduced bandwidth, reduce false positives and improved administration, products that communicate with RBL providers should utilize a number of key features, including:

• RBL Weighting
  
  Different RBLs employ different policies detailing how an SMTP server qualifies as a spam relay host. These can range from confirmed or unconfirmed reports from spam recipients, to automated testing of SMTP servers, flagging of IP ranges for countries suspected of sending spam or even spam trap reports, which consist of mail sent to non-existent email addresses set up by an RBL site
  
  Aggressive RBL policies such as unconfirmed reports and automated testing filter out almost all spam, but also tend to result in a high level of false positives, including identifying such non-spam vehicles as large Internet Service Providers on their lists. Policies based only on confirmed reports, on the other hand, catch less spam in their nets, but also trigger fewer false positives.
  
  The most effective solution to reduce both spam and the number of false positives is therefore to adopt a simple weighting procedure, assigning three weight levels to reliable, potential and unconfirmed categorization. A message triggering a single RBL with a weight of "reliable," for example, would therefore always be considered as spam, but a message without a reliable trigger might instead require 3 RBLs with a weight of "potential," or 5 RBLs with a weight of "unconfirmed," to be classified as spam and treated accordingly.

   

• Asynchronous RBL Queries
  
  Synchronous queries occur sequentially, increasing the filtering for each email time to the total of each DNS look-up response. Asynchronous RBL queries, however, occur simultaneously, thereby reducing the filtering time for each email. Email from spam relays will then be filtered on the fastest RBL result, indicating a spam relay, while email from legitimate SMTP servers will be filtered on the slowest DNS look-up response.
  
  
• Dropping the SMTP Session
  
  RBL filtering operates on the IP address of the server, initiating an SMTP session with the recipient SMTP server. The server initiating the session is considered a spam relay if a RBL DNS look-up resolves to an IP address. Once the server is considered a spam relay, the SMTP session can then be dropped before the message header and body are downloaded.

  To find valid users, spammers address email to domains with popular aliases. Known as a "dictionary attack", this method finds valid addresses that don't return Non Delivery Reports (NDR). During dictionary attacks, dropping the communication saves bandwidth, whereas other methods (such as address or content filtering) require the message header and body to be downloaded before the message can be identified and filtered as spam.

• Excluding Friendly IPs
  
  Legitimate customers may have unsecured SMTP servers that are relaying spam from a third party. To solve this problem, notify the customer's email administrator and add the problem server as a temporary Friendly IP, allowing it to bypass the RBL filter. For customers with a group of unsecured SMTP servers, specify the Friendly IP with a netmask. Spammers typically falsify their originating SMTP address, so basing exceptions on the originating SMTP address is a potential security risk.
  
  
• Operates with or without firewalls, appliances, or managed services
  
  When a product is operating behind a firewall, appliance, proxy gateway, or other mail delivery product, the IP address of the sending SMTP host will be that of the firewall and not of the originating SMTP host.  In order to verify the IP address in a RBL provider, the actual IP address of the sender must be used.  A product that provides a means to "look back" at the path an email has travelled is the only way RBL lookups can be used when operating behind a mail appliance of firewall.
  
  
• Exchange Server Integration
  
  By selecting a software tool such as Nemx SecurExchange Perimeter that can be "bolted-on" directly to the SMTP/Internet Connector and MTA, all configuration and operation can be performed as a straightforward add-in to the Exchange server, through Exchange's native facilities, services and connectors. Spam filtering then becomes synchronous with the message flow, honoring your security settings, enabling seamless, uncompromised support in a single application, and improving performance, reliability and ease of administration.
  

Find out more
To find out more about how to protect your Exchange server from these and other spam techniques, visit:

Nemx products
Nemx solutions
Or contact us