A few months ago, I grew sufficiently tired of wading through the enormous quantities of spam I was receiving (about a thousand junk emails per day) that I decided to experiment with a technique called greylisting to see if it would reduce the amount of junk email I received.
My first choice was a program called postgrey, but when I tried to install it, I realised that my mail server box was running a version of Postfix that couldn’t work with postgrey.
After a few weeks, I found time to upgrade the mail server, but on Robert’s recommendation, I gave a different tool, called tumgreyspf, a try instead.
Although it initially seemed like a wonderful tool–it reduced the amount of incoming spam by 90%, to a mere hundred messages a day–three things soured me on tumgreyspf pretty quickly.
The first problem was the useless overhead the damn thing imposes. For some reason, instead of running as a daemon, it runs a new copy of itself for every incoming message. This meant that the load on my mail server went from about zero prior to installing tumgreyspf, to around 3 with it running, with frequent huge spikes, up to 20. (If you don’t know what “load” is in Unix parlance, a load of one approximately means that the CPU is 100% busy.)
Here’s an image of the load on Robert’s mail server box that spans the end of tumgreyspf’s tenure on his system (his volume of incoming spam is about a fifth of mine, if I recall correctly), and his switchover to postgrey. It’s not hard to tell where the cutoff lies.
The second, and much worse, problem came when tumgreyspf completely buggered things up when my mail server was hit by a dictionary spam attack (“let’s send mail to every conceivable address here”). Normally, I don’t even notice attacks of this kind, but this one drove my load through the roof; worse, it caused a local denial of service: tumgreyspf thereafter caused Postfix to reject all incoming mail, apparently because some state directory had gotten too full.
Once the denial of service occurred, I canned tumgreyspf almost immediately. Of course, I didn’t even realise that the problem was even happening for several days, until I got a phone call from a friend who let me know that my incoming mail was bouncing.
After I gave tumgreyspf the boot and installed postgrey, as had been my original intention, sanity returned. So far, postgrey has consumed negligible resources, while refraining from screwing up my mail configuration. It’s quite charming, really.
The final nail in tumgreyspf’s coffin came posthumously, after I had already decided it was a piece of shit and replaced it. Instead of storing its state in a database, it uses the filesystem, creating several directories and a file for each remote address that tries to send mail. While this sounds like a nice, simple Unixy approach, it is in practice a terrible idea.
Although I only ran tumgreyspf for a few weeks, it consumed over half a million inodes during that time. A filesystem typically has a table of tens of millions of inodes, so this isn’t a problem in principle. However, keeping vast numbers of inodes in use massively increases the time it takes to index the data on a disk, and to perform housecleaning operations and backups.
I normally try not to spew invective about any particular piece of free software, because no matter what I might think of it, someone spent time writing it and released it to the world with no warranty that it would ever work well at anything. However, I’ll make an exception for tumgreyspf, as it is worse than useless. If you’re using it, find an alternative before it rears up and bites you.
Leave a Reply