Home // Postfix Guides // RHSBLs


RBLs are most often available via DNS, and will contain a list of IP addresses that are commonly used by spammers, open relays, systems that are non-conformant to RFC, or whatever criteria the people running them choose to use.

An RHSBL, like an RBL, is usually available via DNS, but contains a list of domain names (as opposed to IP addresses) that can be checked against the client domain of an email, as well as the domain portion (after the @) of the sender and recipient addresses.

The main issues when dealing with an access file when there are thousands of servers who update it regularly, is that some servers will be a few days (or even weeks) behind if their system administrators don’t have the time to update the files regularly, and/or either don’t want to or can not (due to policies) set an automated task to update the file. In order to address this issue, RHSBLs were made out of the original access filters and have grown into very large projects over the past few years.

The first thing to consider when implementing the an RHSBL is whether to keep an access file in use. Being as an RHSBL should contain all of the domains listed in the access file, and can filter clients, senders, and recipients, you may want to use a usernames-only version of an access file. If this is the case, you can download a sample version of an usernames-only access file here, and you will need to use the following in your main.cf smtpd_recipient_restrictions list:

check_sender_access hash:/etc/postfix/maps/access_usernames,
check_recipient_access hash:/etc/postfix/maps/access_usernames,

Note that there is (as of late 2005) no reject_rhsbl_helo option, so if you would like to still reject domains based on the helo information, you’ll need to keep updating an access file, and leave the following in your main.cf smtpd_recipient_restrictions list:

check_helo_access hash:/etc/postfix/maps/access,

Now that you’ve decided what to keep in the way of access files, you can implement an RHSBL as follows:

Postfix 2.0 & Later:
Add the following to your main.cf smtpd_recipient_restrictions list:

reject_rhsbl_client host.rhsbl-domain.com,
reject_rhsbl_sender host.rhsbl-domain.com,

NOTE: host.rhsbl-domain.com is not a real server. Replace that with the name of the RHSBL that you are implementing.

You can also use reject_rhsbl_recipient host.rhsbl-domain.com, but we’ve found that it will not catch anything that hasn’t already been caught by other anti-spam / anti-relaying mechanisms..

NOTE:  The information below is an example that can be used for other RHSBLs.

SpamAssassin typically places its configuration files in /etc/mail/spamassassin and will read any file in that directory that ends with .cf. You can either add the below to the existing file (probably named local.cf) or create a new file with this content. If you do create a new file, make sure that the file ends with .cf

header BLACKHOLE_POSLUNS eval:check_rbl_from_host(‘ssage’, ‘blackhole.posluns.com’)
describe BLACKHOLE_POSLUNS Blacklisted as per blackhole.posluns.com

Note that you will probably want to change the score number for a custom entry. When Jeff was running his own RHSBL (since he was the one who created it), he set it to a higher score.

NOTE: The below information is not longer applicable to the example RHSBL, as it is not currently being maintained.  The information below is being left on this page as an example that can be used for other RHSBLs.

If you would like to secondary a DNS zone file (by performing zone transfers) so that your own DNS server can be queried instead of the public ones for the RHSBL (which will reduce internet traffic, and probably speed up your rhsbl checks), you can add a statement like following to your Bind configuration:

// Slave server for blackhole.posluns.com
zone “blackhole.posluns.com” {
type slave;
masters {; };
file “slave/db.blackhole.posluns.com”;

If you would like to secondary the server, and have other servers on the internet query yours (which will save the RHSBL organization’s bandwidth and help the rest of the world), please let the RHSBL administrators know and they may add an NS record for your server to the zone file once they make sure that your server is operating properly.

Each RHSBL will have its own listing and removal criteria.

Leave a Reply

Your email address will not be published. Required fields are marked *