To Greylist or Not to Greylist?

I’ve been thinking a lot about Greylisting lately and a post by Rogers Cadenhead in Watching the Watchers on alternative methods of stopping spammers (more on this below) got my mind going even more. Now, please bear with me as I dive deep into this concept, which I admit, can get pretty complex.

Among available methods of protection against spammers, Greylisting is a pretty old one and is considered to be efficient by many of its users. I’ve seen this method used a lot by universities, and several of my friends having their own mail servers are also very fond of this method for reducing spam volumes. Personally, I tried this method on my home mail server, but gave up after finding it to be too annoying due in part to its design.

First, what exactly is Greylisting?

Greylisting is a method for which a mail server will initially not accept an email from an unknown source (usually identified by its IP address and the sending email address), and then after some time (usually 5 to 30 minutes) it is eventually accepted. The idea behind Greylisting is that Zombie networks used by spammers will stop trying to resend their spam messages once the messages are rejected.

In my conversations with Mail Administrators it seems as though this method does indeed reduce the volume of unwanted messages. However, the design of blocking messages on systems using Greylisting can also cause delivery problems for legitimate email – this is where my “annoyance” lies:

• As a sender, I sometimes send messages to a destination that is using Greylisting. In these cases it often takes a half an hour for the message to be delivered to its final recipient. If complaints are logged to the Mail Admin the typical response is “email is not instant messaging,” and they are right, but sometimes it is nice to have short delivery times.
• As a recipient of a message on an infrastructure that is using Greylisting I might even be more annoyed. Again, the typical response from the Administrator would be the same argument- this is not instant messaging. And again, this is true, but think about a very typical use case where a user registers for something on a website and has to wait a half hour or more for the registration confirmation email to arrive. This does not provide a very good user experience.

Furthermore, Greylisting can even become more complicated to manage when there are many mail servers handling incoming mail. Unless Greylisting is setup using centralized or shared databases of senders, messages are at risk of being Greylisted by server 1, then half an hour later by server2, and so on. Delivery could end up taking a really long time. You would also have a difficult time if you change the sending IP address for a blocked message, as this would become a new Greylisting entry (this is rare, but I’ve seen it done by some ISPs).

As I said earlier, there is another interesting alternative that was discussed by Rogers Cadenhead in his Watching the Watchers post, “Deterring Spammers with Fake MX Records”. This method requires setting up fake MX records in the DNS and then assumes that spammers (or their software) will hit a fake MX record and then stop trying to send the message. This method lets legitimate senders immediately fall back to a valid MX record for sending the message and therefore reduces the volume of spam. The risk with this method is that some legitimate client software would stop parsing the list of MX records if the first one encountered is invalid (which is different from getting a DNS temporary error).

Another alternative, very similar to this, but eventually requiring more resources, is to setup real MX records which point to non-mail servers. This could be a Honeypot machine where port 25 is refusing connections, or where a small but efficient program returns temporary failure messages. For example, you could have in your DNS:

In this scenario, only the second server is a valid mail server. This does however bring up a question – does the valid server have to be in second position? What are spammers trying first? The first MX record, the last one, any other? A good reading on this can be found here: http://nolisting.org/ or on Wikipedia http://en.wikipedia.org/wiki/Nolisting.

The downside is that both the Greylisting and Nolisting methods have been discovered by spammers and they are now taking these defensive measures into account. In addition, some software randomly hits any MX record, so the example above using 3 MX records the spammer has a 33% chance of delivering the message in only one attempt.

So, what do I think the method is? Without trying to sound *too* self serving, the Sendmail Sentrion Appliance provides a good alternative and more efficient ways for protecting the Mail Infrastructure from such kind of attacks. By combining the use of the Sentrion Messaging Directory and the Connection Control application (part of the core Sentrion Message Processing Engine), Mail Administrators can setup protection of their assets in these ways:

• A directory containing all valid email addresses is the best way to reject messages sent to invalid recipients on the incoming point and particularly if you have many incoming servers.
• The Sentrion Connection Control Application efficiently verifies valid emails by leveraging the Directory and also counts the number of invalid tentative and wrong addresses while providing the ability to block incoming traffic at the IP level (at the operating system or central firewall level) for offending senders. For example, one can configure “if I get more than 5 invalid recipients per 10 minutes, then block the sending IP address for 1 hour (during which any incoming SMTP connections from the offending address will not be handed off to the MTA.”
• The Sentrion Connection Control Application goes even beyond this simple protection as administrators can setup general protection patterns to protect their servers from being flooded by messages from the Internet. For example “do not allow more than 10 MB per hour per IP address,” or “do not allow more than 100 messages per minute per single address,” etc.

Such granularity goes beyond the simple Greylisting concept, and while Greylisting is a nice method, it might become a little bit more complex in a large enterprise’s infrastructure (or even when more than a few incoming servers are needed) as it requires some centralization of shared databases for handling Greylisted addresses. The Fake MX or Nolisting methods are nice as it would eventually require no additional system administration, but it doesn’t provide the advanced features of a Messaging Infrastructure Appliance like Sendmail’s Sentrion.

Speaking of granularity, did you see what SC Magazine had to say about Sentrion? Check it out.

That was a lot of info to digest, and I would love to hear your thoughts as well. Please let me know what you think.