Greylisting

Greylisting

DRAFT RELEASE pending further improvement of this document.

Overview

Greylisting can greatly reduce the incidence of spam being received, almost if not theoretically to zero. Greylisting uses a type of combined whitelist and blacklist, and by temporarily rejecting every email message received, the originating mail server is forced to retry the sending at a later time. Legitimate & well behaving mail servers will do this reliably, and on the second delivery attempt the receiving server will accept the message. Spam servers tend not to retry sending (as they are so busy sending thousands of spam messages already), so when the spam email is blocked the first time, then it is usually not resent. All of this happens behind the scenes without the end recipient being aware. There is usually a delay in receiving an email the very first time a user sends a message, while waiting for the sending server to retry sending. Regular senders are automatically added to a whitelist, so they are not blocked in normal operation. Problems can arise and mail can be lost, where sending servers are not compliant with RFC rules on retry attempts, so there is a small risk of mail loss depending on where your mail comes from. There can also be problems with mail coming from large corporate mail systems that have many mail servers using different IP addresses, as the delivery retry can come from a different server, resulting in that message being rejected again, so it may not get reliably delivered. Permanent whitelists can be used to work around these situations.

Some users report problems with mail servers that do not behave correctly regarding delivery retry times. Other users say Greylisting works very well for them. It would appear that Greylisting works the best and with least administrator maintenance in situations where there is a mostly stable base of sending mail servers.

Here is a link to a forum post, which also then links to other posts, detailing steps to configure Greylisting using qpsmtpd plugin http://forums.contribs.org/index.php/topic,44032.msg211152.html#msg211152

Also refer to http://www.greylisting.org/

Intending users should search on greylisting in the SME server forums, and familiarise themselves with the benefits and disadvantages of using greylisting, before they implement it. The maintenance issues associated with permanent whitelists and the monitoring of email to ensure arrival in all cases, may not suit some administrators policies.

Enable Greylisting

First create a location for the dbm file

mkdir -p /var/lib/qpsmtpd/greylisting
chown qpsmtpd:qpsmtpd /var/lib/qpsmtpd/greylisting

Create location for Whitelist Host file. This is templated. (These are IP addresses of hosts that dont retry nicely e.g. bigpond.com has numerous outgoing mail servers retries can come from any one of these...)

mkdir -p /etc/e-smith/templates-custom/var/service/qpsmtpd/config/whitelisthosts

N.B you now need to add whitelisted host IP addresses, one per line in files there e.g.

echo 123.123.123.123 >>/etc/e-smith/templates-custom/var/service/qpsmtpd/config/whitelisthosts/10whitelisthosts

then create the file

expand-template /var/service/qpsmtpd/config/whitelisthosts

Create a custom template entry to get greylisting added to the runtime config

mkdir -p /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/0

Create entry to enable Whitelisting to deal with mail servers that dont behave as we want.

echo whitelist_soft > /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/0/05whitelist_soft

Enable greylisting with modified options

echo greylisting black_timeout 60 db_dir /var/lib/qpsmtpd/greylisting > /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/0/10greylisting
/sbin/e-smith/expand-template /var/service/qpsmtpd/config/peers/0
signal-event email-update

---