RBLs and URIBLs

Real-time Blackhole Lists, or Remote Block Lists, (RBLs) and URI Blacklists (URIBLs) are publicly accessible lists of known spam sources. An RBL is queried using the connecting server's IP address, while a URIBL is queried using domain names and URLs found within the body of a message. Each list is managed and maintained independently, and each has its own criteria for listing an IP address or domain as a source of spam. SmarterMail ships with a number of RBLs and URIBLs already configured, so system administrators can simply enable or disable the default lists they want to use for protecting against spam. In addition, system administrators can add their own RBLs or URIBLs, including paid/commercial feeds, as they see fit.

Functionally, an RBL check works by reversing the octets of the sender's IP address and prepending them to the list's hostname, then performing a DNS "A" record lookup against that constructed hostname (for example, checking whether 192.0.2.10 is listed with zen.spamhaus.org results in a lookup of 10.2.0.192.zen.spamhaus.org). If the lookup returns an IP address, the sender is considered listed with that provider. A URIBL check works similarly, except that it's the domain names and URLs found in the message body that get queried against the list's hostname, rather than the sender's IP.

Because these DNS lookups can introduce delivery delays — especially when many RBLs and/or URIBLs are enabled at once — SmarterMail checks every enabled RBL for a message in parallel, as independent asynchronous tasks, rather than working through the list one hostname at a time. This means the extra delay added to a message's delivery is roughly bounded by whichever single list responds slowest, not by the sum of every list's response time. In addition, SmarterMail imposes a built-in DNS lookup timeout of 10 seconds on every RBL/URIBL query; if a list hasn't returned a result within that window, the lookup is abandoned and logged as a timeout so that a single unresponsive or slow provider can't stall message delivery or cause the connecting server to time out.

The RBL/URIBL Grid

The landing pages for both RBLs and URIBLs display the lists that have been configured on the server. Details of each include:

• Name - The list's friendly name, as configured by the system administrator.
• Average Time - The average time, in milliseconds (ms), that it takes for a DNS response to come back when this specific list is queried. This is a live, rolling statistic maintained in memory by the mail service: it only reflects lookups performed within roughly the last hour, older samples are continually aged out, and recent results are weighted more heavily than older ones so the number reflects current provider performance rather than a flat historical average. Because it resets whenever the mail service restarts, a newly restarted server will show no data here until the list has been queried a few times. Should a specific list consistently show an inordinate average time, it could indicate that provider is having problems, and that particular check could be disabled until the issue is resolved to protect the timely delivery of email.
• Timeouts - A rolling count, over that same roughly one-hour window, of how many lookups against this list failed to return a usable result — whether because the 10-second timeout was reached, the DNS query itself failed, or the lookup was otherwise cancelled. Like Average Time, this counter is kept in memory and resets on service restart, so it's best used as a near real-time health indicator for a list rather than a permanent record. A list with a persistently high or climbing Timeouts count is a strong candidate for being temporarily disabled.
• Host - The hostname of the list, as provided by the list's maintainer (for example, zen.spamhaus.org).
• Weight - The weight (or range of weights, for lists with multiple lookup values configured) assigned to this list.
• Spool Filtering - A checkmark appears if the list is enabled and being used as part of the overall spam score assigned to a message.
• Inbound SMTP - A checkmark appears if the list (RBLs only) is being used to block connections at the SMTP level for messages sent TO the server. This column never applies to URIBLs: an RBL only needs the connecting IP address, which SmarterMail already has the moment a remote server connects, but a URIBL needs to inspect URLs found in the message body, and the message body isn't available until after it has been fully received. Because of this, URIBL-based SMTP-level rejection simply isn't possible — URIBLs can only contribute to a message's spam score after the fact, through Spool Filtering.
• Outbound SMTP - A checkmark appears if the list is being used to check messages sent FROM the server.

Managing a List

Clicking on a specific list opens up a modal window. Here, system administrators can edit the list's details as needed. Depending on the list selected, the following settings are available:

• Name - The friendly name for the list that will help you and your customers identify it.
• Description - Any additional information about the list.
• Hostname - The hostname of the RBL/URIBL, exactly as provided by the list's moderators (for example, bl.spamcop.net).
• Lookup Prefix - An optional value that SmarterMail inserts as an extra label directly in front of the reversed IP address (for RBLs) or the domain being checked (for URIBLs) when it builds the DNS query. Under normal circumstances, with no prefix configured, a query is built as <reversed-ip-octets>.<hostname> (for example, 2.0.0.127.zen.spamhaus.org). When a Lookup Prefix is supplied, the query instead becomes <prefix>.<reversed-ip-octets>.<hostname>. This field exists for RBL/URIBL providers whose feeds require a unique, subscriber-specific token to be embedded in every DNS query — a common example is Spamhaus's paid Data Query Service (DQS), which requires each lookup to include an account-issued key so that queries are matched to the subscriber (something like yourkey.zen.dq.spamhaus.net, rather than the free public zen.spamhaus.org zone). If your organization subscribes to an authenticated feed like this, enter the key or prefix segment the provider issued into this field; for standard, free public lists this field should be left blank.
• Enable Spool Filtering - When enabled, the weight assigned for the spam check is added to the message and used as part of its overall spam score. SmarterMail then handles the message based on the spam settings configured for a domain.
• Enable Inbound SMTP blocking - Only available for RBLs (see the note on the Inbound SMTP grid column, above, for why URIBLs cannot use this option). This option is used in conjunction with the SMTP Blocking settings configured in Antispam Options. When enabled, this RBL is counted toward the weight threshold for the blocking of incoming emails at the connection level.
• Enable for Outbound SMTP blocking - This option is used in conjunction with the SMTP Blocking settings configured in Antispam Options. When enabled, this RBL/URIBL is counted toward the weight threshold for the blocking of outgoing emails.
• Required Lookup Values

  Every RBL/URIBL entry needs at least one lookup value defined, but a single list is not limited to just one. Additional IP Address/Weight pairs can be added (and removed) as needed, which matters because many real-world lists don't use one single response code for every kind of listing — different response codes often represent different categories or severities of listing, and system administrators can assign each one its own weight. SmarterMail's built-in Spamhaus entry (zen.spamhaus.org) is a good illustration of this: it defines separate weights for each of the distinct 127.0.0.x response codes Spamhaus can return (differentiating, for example, its SBL, XBL, and PBL sub-lists), and it also maps Spamhaus's own error-response codes (127.255.255.252, 127.255.255.254 and 127.255.255.255) to a weight of 0, so that a misconfigured or throttled query never mistakenly inflates a message's spam score.

  • IP Address - The exact IP address that's returned by the list's DNS response when the queried sender's IP (or, for a URIBL, domain) is listed with the provider. This value is published in the setup documentation from the RBL/URIBL provider. A wildcard value of * can be used to match any returned IP address, which is useful for lists (such as UCEProtect) that only ever return one generic "listed" response rather than distinguishing between listing categories.
  • Weight - The weight assigned to this specific lookup value. If the sender's IP (or a URL found in the message) matches this particular IP Address entry, this is the value that gets added to the message's total spam weight. For URIBLs, a companion Max Weight field is also available for each lookup value, capping the total weight that a single response code can contribute even if multiple matching URLs are found in the same message.

Adding New RBLs or URIBLs

Adding a new RBL or URIBL is as simple as clicking the New button. The same modal opens as described above. System administrators simply need to fill out the relevant information in order to get the new list in the lineup. Complete documentation on how to include the list should be made available by the list provider. For example, here is the information for the SpamCop Blocking List. It clearly states the hostname to use (bl.spamcop.net) and IP that's returned (127.0.0.2). From there, system administrators simply need to fill out the other options.

Example (RBL with multiple lookup values): Spamhaus's zen.spamhaus.org feed doesn't return a single catch-all response — it returns different 127.0.0.x addresses depending on why an IP was listed (for example, 127.0.0.4 and 127.0.0.5 indicate a listing on Spamhaus's XBL exploit-based sub-list, while 127.0.0.10 and 127.0.0.11 indicate a Policy Block List entry for dynamic/residential IP space). Rather than treating every listing the same, a system administrator can add a separate Required Lookup Value row for each response code Spamhaus documents, assigning a higher Weight to codes that indicate a confirmed spam source and a lower Weight to codes that simply flag dynamic IP space, giving much finer control over how heavily each type of listing influences a message's spam score.

Example (URIBL): The URIBL Black list (multi.uribl.com) checks domains found in message bodies rather than the sending IP. Because it's a URIBL, it can only be used for Spool Filtering (and Outbound SMTP blocking) — Inbound SMTP blocking is never available for it, since the domains being checked can't be known until the full message has been received. When a message contains a link to a domain listed on multi.uribl.com, the matching Weight for that response code is added to the message's overall spam score, which is then evaluated according to the domain's configured spam probability thresholds.