Postfix email server spam reduction using DNSRBL services for both blacklisting and greylisting

Submitted by Kamal Wickramanayake on Tue, 11/17/2020 - 01:25

Even if DNS Real-time Blackhole Lists (DNSRBL) are used to blacklist the IP addresses of e-mail spammers, spammers could change to unlisted IP addresses and continue spamming. While greylisting reduces the spam since spammers don't always reattempt to send the same e-mails, it also has the advantage that the delay introduced gives some time for the DNSRBL services to blacklist the IPs of bad senders. However, greylisting could delay legitimate messages. An improvement is to apply greylisting only for the e-mails sent from suspected IP addresses.

How to greylist e-mails sent from suspected IP addresses, but allow other legitimate e-mails be accepted without delay? I am experimenting with these three ways to identify the IP addresses that could send spam:

  1. Automatically create a list of IP subnets using the IP addresses that are blocked by DNSRBL services.
  2. If ever a spam e-mail is received, add a subnet which includes the sender IP address to a list.
  3. Use some DNSRBL services that list the whole network blocks of IP addresses of spammers.

To have such filtering in my Postfix e-mail servers, I use postfwd, the Postfix Firewall Daemon. Below is a slightly different version of the postfwd configuration file I use:



        action=REJECT Listed on dnsbl




The file "postfwd-blacklist-manual" contains the IP addresses of spammers that are manually add if I see spam in my inbox. The file "postfwd-greylist-manual" contains the /24 subnets that include those IP addresses. Adding entries to those two files however has been made simple. In Thunderbird e-mail client, I simply use a keyboard shortcut that eventually update the two files in the primary and secondary e-mail servers. Also, I have made the entries in those files to expire after a few days.

I use and DNSRBL services to blacklist the spamming IP addresses. When an e-mail from such an IP is received and blocked, one of my scripts automatically add the sender's /24 subnet to the "postfwd-greylist-auto" file. Such entries are also to expire after a few days.

At the end, I use DNSRBL service to greylist. This DNSRBL service lists the IP addresses of non-spammers as well. Hence it is not ideal to be used in the blacklisting configuration. But it does appear to list IP addresses of potential spammers - probably by listing spammer's IP address blocks.

Lines "action=ask(" trigger Postgrey, the email greylisting software that I have installed in my e-mail servers. Since not all e-mails are greylisted, I use a greater greylist delay in Postgrey - that gives more time for the DNSRBL services to blacklist the suspected IP addresses if they were actually sending spam.

Here's a fragment from the Postfix log file that indicates the postfwd filtering progress:

Feb 13 13:20:18 svr1 postfwd2/master[1767]: [STATS]   59 matches for id:  GREY_RBL
Feb 13 13:20:18 svr1 postfwd2/master[1767]: [STATS]   57 matches for id:  BLACK_RBL
Feb 13 13:20:18 svr1 postfwd2/master[1767]: [STATS]   11 matches for id:  GREY_FILE_AUTO
Feb 13 13:20:18 svr1 postfwd2/master[1767]: [STATS]    8 matches for id:  GREY_FILE_MANUAL
Feb 13 13:20:18 svr1 postfwd2/master[1767]: [STATS]    7 matches for id:  WHITE_FILE_FIXED

In addition to the above configurations, I have configured the mail servers to use the Sender Policy Framework (SPF) and also use another black list containing e-mail address and domain names of unwanted e-mail senders.

Using the DNSRBL services for both blacklisting and greylisting combined with additional measures as described above has brought down the spam problem. I continue to receive spam, but very infrequently. On some days I receive one or two spam e-mails instead of a few tens per day as it was used to be before the greylisting was introduced.