Running a large farm of heavily modified MailScanner instances for high-volume customers exposes a number of problems when dealing with spammers.

Recently, some of the more irritating spammers appear to be leaning on bounces for delivery from reputable sources rather than proxies or direct delivery from botnets. For this kind of spammer, connecting to your load balanced cluster and delivering 10,000 messages in a single SMTP conversation isn't out of the ordinary.

For most customers, you verify the recipients enumerated to make sure each one exists for delivery before accepting the messages.

If your customer doesn't want to to reject any received mail for their domain for whatever reason (argh!), but just want you to identify spam for them and ship it off to a spam jail so their (broken) mail system won't choke on the volume, you end up queueing up every one of those 10,000 messages to process - wether there is a real person to receive it or not.

It might help in this instance to use the greylisting trick of initially returning a "temporary error" for each incoming message. Blind spammers simply don't seem to want to re-send a temporarily rejected message. Real mail servers don't have this problem, and happily retry 5-15 minutes later without issue.

If your customer also doesn't understand the value of greylisting, and is adamant against rejecting mail for whatever reason, you're stuck in a rather messy position. All mail must be accepted, queued, and processed.

This means, across your farm of hundreds of mailscanner servers, you end up with a handful of servers chewing through 10,000+ message backlogs, and the rest of the servers in your cluster are chewing through _nothing. After moving those queue files between servers for a while, you realize that you're losing the battle....

That is, unless you're clever.

Enter: the greypit.

The idea behind greypitting is to try and balance incoming messages across your load balanced cluster of mail servers.

It would be nice to accept only the first N messages in an SMTP connection. Once the limit is reached, simply return a "temporary failure" to the remote MTA. Actual RFC valid MTAs will give up and attempt to retry in the near future (5-15 minutes).

Greylisting is the act of returining these temporary failures immediately, but recording the IP/senders/recipients triplet and accepting the messages when they are resent. A greypit keeps no triplet, and accepts the first N messages without interfering at all.

The fun bit here: the spammers ignore the SMTP return codes. They happily continue to blindly hammer away sending message after message, each which is being rejected with a temporary failure.

So, after the first "temporary failure" result, what if we start to sleep a given number of second for each successive MAIL FROM: beyond the initial limit of 10 messages (in addition to not accepting those messages for delivery)? The spammers get a taste of tarpit.

The cluster now balances evenly. Only 10 messages from that evil spammer actually make it through to be scanned, the remainder cause the spammer to tarpit themselves into oblivion.

So, here is the Sendmail Milter source for a little project I call greypit:

greypit.c - v1.0 C daemon source.

To build the daemon, link with libmilter and libpthread:

gcc -o greypit greypit.c -lmilter -lpthread

You will also need to add a line to sendmail.mc to use this milter:

INPUT_MAIL_FILTER(`greypit', `S=local:/var/run/greypit/sock, F=')

And create the /var/run/greypit directory for the socket.

Simple. Elegant. Hacktastik. But it works.