Tip of the Trade: Postgrey

by Carla Schroder

Who knew such a small Perl script add-on could be so powerful? Postgrey Greylisting Policy Server is a simple hack that shoos spam away from the Postfix MTA by reacting to behavior, not content.

Admins, as a general rule, spend far too much time and energy trying to keep spam out of the networks. Until technology is developed to reach out and touch spammers — forcefully — spam will be an unfortunate and expensive fact of life. Fortunately, some simple hacks can be applied at the server level to derail a significant amount of spam. For Postfix admins, for example, there is the Postgrey Greylisting Policy Server.

Postgrey is a small Perl script add-on for the Postfix MTA. It uses an ingenious, low-overhead method of shooing spam away, reacting to behavior rather than content. This has a number of advantages: Content filtering is slow, error-prone, and uses significant CPU cycles. It is also completely ineffective on encrypted messages. Postgrey operates at the SMTP level, which is low-overhead and fast.

The first time Postgrey sees a message from a new CLIENT_IP/SENDER/RECIPIENT combination, it is bounced with a "450 mailbox unavailable" error. 450 errors are not permanent. The sending server, according to correct behavior, should re-send the message. Legitimate mail servers will do this, but spam and virus servers rarely do. If the sending server is still trying after five minutes, Postfix accepts the message and adds the sender information to its whitelist database. So the biggest cost is to users, who will see a five-minute delay the first time they receive a message from a new source. At least for now, this derails a significant amount of spam for a very low cost — a few lines in main.cf, and virtually no load on the server.

Postgrey is commonly used in combination with RBLs and the usual batch of Postfix header checks. See the Postfix SMTPD Policy Readme and Postgrey - Postfix Greylisting Policy Server to learn more.

This article was originally published on Tuesday Aug 1st 2006
Mobile Site | Full Site