Anti-spam Greylisting with Postfix?

[nautical9]

I recently stumbled upon a relatively new spam-fighting technique called Greylisting, and it sounds like a very effective yet simple way to combat spam, especially when used in combination with more traditional filter-based approaches (eg. SpamAssassin).

(If you're new to greylisting and want the executive summary, skip down a bit)

However, it would appear the concept is a little too new (although I believe it was originally published circa June 2003), and the current stable release of Postfix (the MTA I use) doesn't yet have support for it.

Digging a little deeper, I found that their latest snapshot version DOES have support for greylisting, but the latest masked ebuild in the portage tree only deals with 2.0.18 ("stable"), and not 2.0.18-20040122 ("snapshot").

I've never mucked about with ebuilds before, and I'm a little nervous to cut my teeth on one such as the postfix ebuild, since it's a little larger than others, has a bunch of custom patches for ssl, ipv6, etc, and is a rather critical component for my at-home server.

I've read several posts from mail-server admins who claim the snapshots are production worthy, and since this is for my personal domain at home, 100% uptime isn't an absolute must for me, but I don't want to suffer a day or more of downtime because I b0rked up my ebuild.

Has anyone else successfully implemented Greylisting with postfix? And if so, could you share your wisdom with the class? Either the soon-to-be-supported snapshot build, or a third-party patch to the stable branch, or something entirely different, would be acceptable.



--- Greylisting Executive Summary ---

Although I'm new to it myself, the concept is really quite simple.

For every mail that comes in, it has three easy to get values: IP address of remote MTA, envelope sender ("from"), and envelope receiver ("to"). If this is the first email the greylisting MTA has seen from that triplet, it immediately denies the email with a 450 message (typically "server busy" or "service not available"). This should cause any standard sending MTA to leave the email in its outgoing spool and try again later.

The receiving MTA will only allow email from that specific triplet after a timeout period (1 hour default). Afterwards, it'll keep that triplet on record as having immediate access for all incoming emails (for a default 36 days, refreshed for every new email).

Although it's an oversimplification, that's really all there is to it.

There are some immediate benefits to this:

• It's been observed that most spammers use custom SMTP engines to send out email and typically do a "fire-and-forget" style volley, meaning they won't "spool" the message for later sending if it's denied the first time. This is fundamentally (but not entirely) what greylisting combats - any legitimate sender will keep trying to send it (default is for a couple days), while most spammers won't bother.
  
  
• It only has to listen to the first few SMTP commands from the sending MTA before it knows whether it can accept or reject, so there's a very small CPU/bandwidth requirement: <500 bytes of handshaking and a quick hash-table lookup for the triplet (and a likely insert into the hashtable).
  
  
• The bigger burden of spooling and retrying is placed on the sending mail server, whereas with a traditional filter-based approach, the email is sent in its entirety before the filter can classify it.
  
  
• Of course, some spammers use legitimate MTAs (even if they're open proxies or zombied machines), and should greylisting become common place, most spammers would wisen up to this technique and retry their failed emails exactly as the spec calls for, but fear not - greylisting also has some benefits here if used in conjunction with a traditional spam-filter:
  
  
• Since most spammers jump around on different IP's constantly to avoid being on an RBL (blacklist) for too long, the current blacklisting filters have a limited usefulness - by the time the IP is widely blacklisted, they've moved on. But with the default hour long timeout with greylisting, it affords enough time for that specific IP to be blacklisted before the email would be allowed in, only to reach the normal spam filter, which would presumably see the blacklist entry and deny it. This renders the spammer's "retry" effort moot.
  
  
• And for spammers who have an army of zombie machines to relay through, each one of them would still have a unique triplet, so each would have to wait the hour before trying again.
  
  
• This technique by itself should, in theory, produces zero false positives, as any credible MTA will retry sending email upon receiving a 450 error message, usually for a few days (but even if it's only a few hours, it shouldn't be a problem).

Obviously, there are some downsides, but most are minor (IMHO) compared to the benefits.

• A lot of emails may be delayed by an hour or (slightly) longer, but in most cases this isn't an issue. And if it is for a specific set of time-critical but known addresses, you can manually add them to a "whitelist", or decrease the 1-hour default (especially useful when first installed, in order to build up a valid whitelist quickly yet still get rid of a lot of "fire-and-forget" spammers).
  
  
• Depending on how busy your email server is, the list-management may take up quite a bit of space, but considering how much CPU/bandwidth is devoted to filtering software already, a bit of disk space is probably quite cheap comparatively. YMMV.
  

For a far better and more technical description, visit the initial greylisting proposal.

[Trejkaz]

This sounds like TMDA without the one feature which everyone always bitches about, the nagging when you send your first email to the address. And this method doesn't just store the address, it stores three values which would all need to be guessed and forged successfully for a spammer to be able to get directly into your server.

I guess if the spammer's mail servers were actually real (e.g. "legal spammers") then it will still get through, but this step would massively cut down on the amount of work left to do by real filters.

Colour me impressed!

Now the question is, how fast can the Postfix guys get it into a stable release. Get it in, guys! In! *twitch*