For When You Can't Have The Real Thing
[ start | index | login ]
start > Greylisting's Effect

Greylisting's Effect

Created by dave. Last edited by dave, 11 years and 336 days ago. Viewed 4,162 times. #3
[diff] [history] [edit] [rdf]
(19 March 2012)

Last year when I rebuilt my server I had the opportunity to see specifically what effect greylisting was having on my inbox.

Right now my mailbox is stored on a Gmail account. However I handle the MX for my zone directly, and then send the incoming messages off to Google where I actually read it. So I end up with three layers of antispam defenses:

  • fakemx, which is a mx service. You add it as the least-priority MX for your zone, and it will tempfail any connections it gets. The theory being that A) many spam systems smart enough to prefer the least-priority MX are not smart enough to then try a higher-priority server; while B) real servers are smart enough to wait and then try the MX list again later;
  • milter-greylist, which tempfails incoming servers for a configurable amount of time, on the theory that many spam systems just try once and then give up, while a real server will come back later; and
  • GMail's spam content filtering.
The FakeMX bit is relatively new (I'm going to say January) and really has not made too much difference that I can see.

But the point of this article is Greylisting. When my server died in September, I made the decision to rebuild it with CentOS 6 on the theory that it was The New Hotness(tm) and I'd better start learning it. As a side-effect, the milter-greylist that I was using at the time was source-built and the source code was long gone. After a bit of fumbling around looking for an alternative, I decided to just run without it for a while since there were other things on my mind at the time.

Now while the Greylisting was running, the Spam folder in GMail would run about 50 messages or so, where messages older than about 20 days are automatically deleted. This is a manageable size such that I can look through it once a week or so to make sure I have not lost something to a false-positive.

Without Greylisting, this blew up to around 2200 messages, or approximately 100 per day. This is too much to go through looking for false positives.

This motivated me to get back on figuring this out, and I resorted to building it from source. I don't really like building from source, it makes updates later harder. But right now there's no alternative that I know.

Mail Flow

Writing this all out makes me realize that remote sites have to try to deliver things to me four times:

  • first to me, which gets greylisted;
  • then to my secondary MX, which is also using greylisting;
  • then to FakeMX, which just tempfails them;
  • then after their retry period, back to me again -- and that only works if their retry period is longer than my greylisting period (currently 15 minutes), otherwise they have to go through the other MXs again too!
Once I have seen them, though, they get whitelisted for some period of time (7 days I think?) and the counter on that period resets if they send me something in that time period.

Update 5 April 2012: an earlier version of this page mentioned that I found a rpm for CentOS 6 for milter-greylist. Unfortunately I was wrong, and in the intervening time had forgotten about it and just assumed that a RPM had been found. Digging around in my build trees, I see there is a .spec file included in the source distribution which may or may not generate a suitable RPM.
no comments | post comment
This is a collection of techical information, much of it learned the hard way. Consider it a lab book or a /info directory. I doubt much of it will be of use to anyone else.

Useful: | Copyright 2000-2002 Matthias L. Jugel and Stephan J. Schmidt