Mail Applications
Greylisting
Overview
Greylisting is a simple trick to catch, it turns out, the majority of spamming software. It works based on the simple premise that spamming software has too big a job as it is throwing emails out that the last thing it wants to do is re-queue a (temporarily) bounced message. All real MTAs will re-queue a (temporarily) bounced message and so that's where greylisting comes in.
On the arrival of an email a unique key is generated and checked for in a database. If it exists (and some other conditions exist, eg. it's been more than five minutes) then you're free to pass, otherwise this is the first time we've seen you, you will be bounced.
It works astonishingly well.
Implementation
Postfix includes some sample greylisting softare but we'll use a shoo-in alternative, David Schweikert's Postgrey.
Postgrey has better database locking/maintenance and supports whitelisting and even auto-whitelisting.
Installation
Is pretty straightforward:
Extract the software somewhere
Install any Perl modules you are missing
Create postgrey user and group
Create the Postgrey database directory /var/spool/postfix/postgrey
Create an init script or SMF startup script and config
A suitable invocation might be:
postgrey --inet=10023 -d --pidfile=/var/run/postgrey.pid --user=postgrey --group=postgrey --auto-whitelist-clients
Copy the default postgrey whitelist files to /etc/postfix
Tweak main.cf:
- Modify smtpd_recipient_restrictions to have check_policy_service inet:127.0.0.1:10023 after reject_unauth_destination
Start Postgrey
Restart Postfix
Observations
The unique key is partly based on the information regarding the client's (ie. sender's) details. This usually works but in my case my backup mail servers catch mail for me. It is their details that are then used to generate the key when they forward the mail, not those of the original client.
It's not a big deal but something to be aware of when you're checking the effectiveness, your own backup mail servers defeat the functionality.
Document Actions