Lessons of Greylisting
MPP v3.2 has introduced Greylisting via our implementation of a Postfix Policy Server. MPP is the only integrated pre and post-queue filtering solution available for Postfix, either open source or commercial. Since we have introduced greylisting we have learned some lessons that are worth sharing.
First of all, a brief description of greylisting. The idea is to send a temporary failure message to every new smtp client that an smtp server sees. A real email server will retry their message after a temp fail message, but most spam drones go away and never retry. Supposedly spam drones are wising up to this, but so far we don’t see a lot of evidence of this. See http://greylisting.org has more details.
In our very small environment we have found some astounding stats in 3 weeks; 47615 remote smtp clients have tried to send our email server. Of this number, 45149 clients never tried to resend again, in other words 94% of the remote clients were spam drones and just went away. Only 274 remote clients were legit, or less than 1%! That is an astounding number if you ask me, which you didn’t 
Not everyone likes greylisting because it delays email. Since 94% of clients simply give up after the first failure, even a retry delay of 1 second can still be very effective. The problem is that how long it takes for a remote email server to resend after a tempfail message is entirely up to the remote server. If you allow hosts to resend 1second after their first attempt and the remote host will retry in 20 minutes the recipient of the email sees a 20 minute delay and yells at the admin when they need something fast. The good thing for MPP users is that greylisting can be enabled on a per-policy basis so that it can be easily turned off for domains or users that don’t want it. This is a pain to do in most policy-server implementations and is a huge plus for MPP.
Greylisting can work on a gateway or on an email server, but care must be taken when deployed on an email server since email clients use smtp to send email. It is a pretty simple workaround to not perform greylist checks if all hosts are on known networks, but it some environments this is not known information and problems can arise. Specifically, clients will see failure messages when sending email and will get angry. So if you are implementing greylisting on your email server and not on your smtp gateway be careful to whitelist local networks from greylist checks.
Our solution uses MySQL as a backend to store remote host information and this database can become quite huge in large environments. We have seen about 1 million remote hosts in a few days in large environments and 95% were drones. This becomes a very large database, especially with the innodb storage engine so if you plant to use greylisting be very careful to properly size your database server in a large environment.
The spam and phishes that passes greylist checks are sophisticated and are caught at about a 50% rate by content scanners. So while a content scanner may be 95% accurate on all traffic, it becomes about 50% accurate on spam that passes greylist checks. Mostly phishes and some image spam will get through the greylist checks.
That’s all for now, please check out http://messagepartners.com for more on MPP and our greylisting capabilities.
Technorati Tags: MPP, antispam, postfix, greylisting, spam, email security, email