Intelligent Message Filter, Content Filter, can do more...

WinDeveloper IMF Tune
WinDeveloper IMF Tune

Checking RBL Provider Policies

Alexander Zammit

Alexander Zammit Photo

Software Development Consultant. Involved in the development of various Enterprise software solutions. Today focused on Blockchain and DLT technologies.

  • Published: Oct 16, 2007
  • Category: Anti-Spam
  • Votes: 4.7 out of 5 - 3 Votes
Cast your Vote
Poor Excellent

Would you trust someone external to your organization to set a critical email policy for you? Someone who gives you a free, no obligations service, to decide who can or cannot send you emails?

Would you trust someone external to your organization to set a critical email policy for you? Someone who gives you a free, no obligations service, to decide who can or cannot send you emails? Would you trust that one actually enforces the policy diligently?

Many administrators in practice give a positive answer to these questions. This is fine as long as the answer is the result of an educated decision. Considering how critical email services are to an organization, underlining the need for education does not hurt.

Real-Time Block Lists in Exchange 2003 explored the technical aspects of configuring RBLs. Today we revisit the topic from a completely different angle. We focus on choosing an RBL provider based on his policies.

To clarify what we are talking about, an RBL here is a list of host IPs. On receiving an inbound SMTP connection, the foreign host IP is verified against the RBL. If listed, an email filtering application may block delivery. RBLs only provide information. The actual email filtering takes place on the email servers choosing to consult these lists.

Anyone looking for an RBL provider quickly realizes a good number of these are available. Thus choosing a provider can be challenging. Taking a closer look will show us that not all providers are the same. Looking at things like their listing criteria, delisting procedure and their reputation is a good starting point.

Listing Criteria

It is not uncommon to find administrators believing that whoever is listed at an RBL is a spammer. As the providers themselves say, this is far from the truth.

A list will indeed normally contain hosts known to be currently under the control of spammers and maleware/virus distributors. Also listed we normally find open relays and open proxies that are one step away from joining the junk distribution network. As long as the listing is accurate I am sure many are happy to block all of these.

However it is good to know that some providers do go a step further. For example, one provider (maybe more) in his criteria claims to list servers that are not RFC compliant. A host could be listed if it does not accept postmaster@domain as per RFC. Rejecting emails based on this criterion is of course ridiculous.

Another criterion some providers adopt is to list organizations who threaten to take legal action against the provider regarding their listing. This listing remains even if the organization resolves any configuration problems that might have triggered the listing. I find such a listing criterion to be at least questionable from the RBL user point of view.

Although not a spam list, backscatterer is another good example. As I said earlier some administrators equate any list to be the same as a spammer's list. As explained at backscatterer.org this is not the case. Backscatterer lists host IPs generating NDRs to foreign domains. It aims to combat the generation of NDRs in response to spam sent to invalid recipients. The logic behind this list is clearly documented. Because of sender address spoofing, the NDRs could end up bombarding other hosts. So the list is targeting servers that generate these NDRs and not spammers.

So the question here is whether we really want to adopt the provider listing criteria. Providers supporting multiple criteria often allow for choosing which of these to enforce. In general this is achieved in one of two ways:

  1. Providers may publish IPs based on different listing criteria on separate DNS servers. In this case we just need to point our filtering software to the right list.
  2. When queried, the list (DNS) may return different results allowing us to identify the listing criteria on the fly. A filter can then choose whether to actually reject the email based on this return value. Real-Time Block Lists in Exchange 2003 discussed handling RBL responses in more detail.

Delisting Procedure

Another important aspect is the process for removing IPs from a blacklist. In this context it is important to keep in mind that mistakes do happen. Apart from plain simple erroneous listings, there is the much more common case where providers simply list an IP range despite knowing that not all of these are under spammer control. This is done to pressure an ISP to take action against abusers. However at the same time other well behaving organizations are kept at ransom. The idea to pressure ISPs has some valid grounds. On the other hand well behaving organization can end up in the difficult position to either somehow force the ISP to clamp down on abusers or to seek a new provider. Both options do not come for free certainly in terms of wasted time and lost business emails.

One more point to keep in mind here is that populating a list with IPs is not that difficult. The difficult part is retaining the list quality over time. Supporting a rigorous delisting procedure can be expensive. In my opinion a provider who does not tackle delisting seriously is not really investing in a high quality list.

Another questionable practice some providers adopt is requiring payment in order to expedite delisting. True, delisting may involve manual intervention i.e. cost. However charging organizations that never sent spam for delisting is still unacceptable to me. I can understand charging for the use of a service but cannot understand charging for repairing a damage the list provider himself is causing. Here again I want to stress that we are discussing the listing of IPs from organizations not involved in any spam, malware or virus distribution.

The bottom line is that if the delisting procedure is unfair, too complex, long winded or even worst missing, we may again end up rejecting legitimate emails. A key question to ask is: Should I reject legitimate emails in order to participate in the process of pressuring ISPs? Should I reject emails to force potential clients/business partners to pay for expedite delisting?

Reputation

As in many other areas, reputation can be extremely helpful in selecting a provider. It is worth researching:

  • How long has the service been running?

  • What are others saying? Of course we will find horror stories on most list providers. So taking these with a pinch of salt is a must.

  • Is it a free or paid service? Being free does not mean the list is of bad quality. However it is worth seeing if the provider has the resources for such a service.

Final Tips

Today we looked at some points to consider when selecting an RBL provider. There are certainly more aspects worth considering. For example we did not discuss the mechanisms adopted for collecting IPs to be blacklisted. There are also other listing criteria we did not mention but that might not be acceptable to an organization where email is a business critical service.

When choosing any email hygiene solution one should not forget the key requirements, that of receiving legitimate emails and dumping garbage. Like any other anti-spam solution, RBL effectiveness could be measured in terms of false positives. However in order to do this we must be able to see exactly what is being rejected. This can be challenging especially in solutions where emails are rejected at a very early stage of the SMTP session. Of course the earlier an email is rejected the less information we have, limiting our ability to judge whether or not the email was legitimate.

Some list providers tend to be over paternalistic, expecting to tell everyone what is wrong or right and being insensitive towards anyone in the crossfire. Policies intended for the "common good" may cause too many casualties losing their true benefit.

References

Real-Time Block Lists in Exchange 2003

Copyright © 2005 - 2024 All rights reserved. ExchangeInbox.com is not affiliated with Microsoft Corporation