What are RBLs¶

RBLs are "Real time Blacklists/Blocklists"

This is to say that it is mechanism for checking the reputation of an email sender or content element at the exact time that a message is scanned, rather than relying on a user-maintained list of untrusted senders or content.

There are several different entities over the world who maintain lists of bad domains, email addresses, URLs, bitcoin addresses and many other identifiers which they think belong to spammers. Each MailCleaner installation is configured with a number of these reputation lists which can be utilized in a few ways.

Reject mail listed by an RBL¶

In the Incoming SMTP stage, a message can be directly refused if it is listed by an RBL.

This is the most strict possible action and should be reserved for RBL sources which provide a very low false-positive rate. Since the message is rejected outright as soon as the relevant content is seen, this spares unnecessary CPU, RAM and Disk space usage. Note that the savings in disk space is because the message is not quarantined and thus it cannot be recover.

Also not that because the message is rejected during the SMTP phase, the sender is made aware that the message was not delivered using a 5xx SMTP code. For false-positives, this is good because the sender will receive a bounce email. For true-positives, this is potentially bad because it informs a spammer that they need to change their tactics.

To configure RBLs to be able to reject messages outright, select them from Configuration->SMTP->SMTP Checks, then restart the Incoming MTA.

Hold messages listed by an RBL in the spam quarantine¶

There are two modules in Configuration->Anti-spam which relate to RBLs. PreRBLs and UriRBLs. The former applies to the IP address of the host which sent the message and the latter applies to the reputation of domains which are listed as the destination hosts for any links within the message (either a HTTP hyperlink, or simply a valid, plain-text domain name).

If a listing is found for an RBL in either of these modules, it will flag the message as spam so that it will definitely get quarantined (or tagged), except in the case of a sender whitelist.

This option is 'safer' when it comes to false-positives because the message is recoverable from the spam quarantine, but it also means that resources are used to scan the message and the sender is not informed that the message was held in the quarantine. RBL sources with occasional false-positives and/or a fast review and de-listing process when they occur should be used at this level.

Increase the chances that a message will we held as spam¶

This option does not guarantee that an item will be held if an RBL listing is found for any of the PreRBL or UriRBL lists. This is to enable the lists as contributors to the SpamC score in Configuration->Anti-spam->SpamC.

The SpamC module uses a large variety of tests to determine whether a message is spam. When an RBL is enabled in this configuration, it is simply considered as one of many aspects which could indicate that the message is spam. In general, this will add a couple of points to the sum of all other tests. If a message receives 5 or more points total, the message is held as spam. This will often allow for borderline spam messages to be blocked while otherwise safe-looking messages can still get through despite the listing.

This option is the least strict and hence most tolerant to false-positives. It should be used when the RBL source makes no guarantees about false-positives or when the list has a lengthy removal process (eg. a minimum listing period before automatic removal).

As suggested by these options, each option is irrelevant if the same RBL is enabled by one of the prior options since the more strict options have higher precedence or occur earlier in the scanning process.

RBL Whitelists¶

Note that there are a few sources listed in the Configuration->Anti-spam->TrustedSources module. These use the same technology, but the RBLs there have listings for IPs that are known to be trustworthy. If these are enabled, the message is treated the same as if the sender had been whitelisted. This is to say that it will override any results from the remaining Anti-spam modules and the mail will be delivered. However, because this also happens after the SMTP phase, if the same IP is listed by one of the RBLs in Configuration->SMTP->SMTP Checks, then it will be rejected prior to that whitelist being seen.

Logs¶

If you search for any message in Managment->Tracing, or in the /var/mailcleaner/log/mailscanner/ logs, you will see several different logs related to RBLs. Here is an explanation of those logs:

Jan  1 00:00:00 mailcleaner MailScanner[25226]: PreRBLs found sender hostname: hostname.domain.com for x.x.x.x on message 1nldZQ-0001GN-Q4

This line is for information purposes only. It is simply providing information on the correlation of hostnames and IP address at the time that the DNS information was checked.

Jan  1 00:00:00 mailcleaner MailScanner[25226]: PreRBLs (1nldZQ-0001GN-Q4) x.x.x.x SORBS => Hit 127.0.0.6

This line indicates that a RBL lookup actually found a match. This usually means that the message will go on to be blocked, since only the enabled RBLs at any given stage are actually checked. The example above indicates that the IP x.x.x.x was checked against the SORBS RBL and resulted in finding a listing with response 127.0.0.6. Those response codes are discussed below.

Note that the only timen that this will appear and the message is not determined to be spam will be if there was a whitelist which overrides the result, or if that Anti-spam module is enabled but not 'decisive' (ie. unable to impact the filtering result; a sort of debugging/dryrun mode).

Jan  1 00:00:00 mailcleaner MailScanner[25226]: PreRBLs result is spam (SORBS) for 1nldZQ-0001GN-Q4

This is the actual result logged by the relevant Anti-spam module. Unlike the previous, it lacks additional information on which IP and the exact return code. It will only appear if the module is decisive.

Jan  1 00:00:00 mailcleaner MailScanner[25226]: Message 1nldZQ-0001GN-Q4 from x.x.x.x (sender@domain.com) to recipient@mydomain.com is spam, Newsl (score=0.0, required=5.0, position : 0, not decisive), NiceBayes (0.0%, position : 6, not decisive), PreRBLs (SORBS, position : 8, spam decisive)

This is the final decision by MailScanner after considering all other modules. In this example it shows that despite other modules not perceiving the message to be spam, the listing by SORBS is decisive.

RBL return codes¶

The return codes for different RBL sources are not typically of interest to users; if it has a 'Hit' listed at all, it is considered spam, regardless of the code. However, since the detail is provided and it can differ slightly per source, more information is provided here.

In general, the convention is to always list an IP in the 'local' space (127.0.0.X). This is because it ensures that no real, resolvable, IP address is used. With some, the final octet of the returned IP is significant. It may indicate the age of the listing, the precision (exact hostname vs. a different subdomain of a blocked root domain), or other factors.

For the first two methods - SMTP Checks and dedicated Anti-spam modules - the result is seen as binary for MailCleaner. In the case that a certain return code is innocuous (eg. previously listed), that code is simply ignored. Otherwise, if there is any return code, it is treated as spam.

For SpamC, each RBL source is capable of having a different set of rules hit with a different score. So, the severity of the listing can impact the number of points that are applied.