Greylisting (or graylisting) is a new anti-spam measure implemented on email servers. It's starting to become more widespread, and if you don't run your own email server, your service might be greylisting (or might add it soon) without your knowledge or permission.

It has the potential to destroy a fundamental function of email in a futile attempt for service providers to save money, yet nobody knows about it.

It's very, very annoying. Much more annoying than spam.

What is greylisting?

Email servers work by accepting messages, figuring out where they need to go, and sending them along their way (or to another intermediate server) until they reach the destination. It was designed to be robust and accommodate unreliable servers, so if a destination server isn't available or temporarily refuses to accept a message, the sending server will try again later.

It's like getting a package delivered when there's nobody home to accept it: the delivery guy tries to deliver it for a few days before assuming you're dead and returning it to the sender.

Greylisting tricks the sending servers into an intentional delay: for every incoming message, a greylisting mail server says "I'm too busy - try again soon!" It's not too busy - it just inserts this intentional delay to see if the sending server will try again. Then it accepts the message if the sending server retries after a minimum delay (usually a few minutes).

Theory

Greylisting is supposed to reduce spam. Supposedly, spam-sending email software won't properly accept the "I'm too busy" messages and try again later, as requested — instead, it will assume that the message's recipient is not a valid email address, and remove it from further spam attempts.

This isn't to reduce the amount of spam that gets to the users — it's to reduce the amount of spam that the server's spam-filtering software needs to analyze (which can be very resource-intensive for a busy server). This is why it's in your email provider's best interest to implement greylisting: they can save money on servers.

Reality

It doesn't work. Plenty of spam still gets through. What's stopping the spam-sending servers from properly obeying the delay and sending the message again? Spammers have found ways around almost everything we've come up with. Why does anyone think they won't be able to figure this out?

We don't need it. Modern spam filtering is highly sophisticated and extremely accurate. Greylisting does nothing to detect spam: it only slightly delays spam delivery.

But that's not the worst part. If it didn't affect my life as an email user, I wouldn't care enough to write this article.

The worst part is that email is no longer instant. In some cases, it's not even close.

The email-delivery protocol (SMTP) doesn't have a standard way for greylisting servers to tell sending servers when to try again. Some wait 15 minutes, some wait an hour, and some wait a day.

This means that if your email provider uses greylisting, there's no guarantee that a message will get to you in a reasonable amount of time.

So what happens?

You can't email someone a link or text blob for their immediate use (like if they're in the same office). You can't email something to someone as you're on the phone with them for collaboration. Websites can't use email activation to reduce spam or verify correct contact information.

I've frequently seen 24-hour delivery delays on greylisted emails. On the internet, that's an eternity. You might as well use paper.

Greylisting destroys email as an instant communication medium.

Spam reduces the efficiency of reading email, but greylisting removes much of its legitimate use completely. At least spam filters only prevent me from talking to my friends about taking viagra while refinancing my mortgage with the cash I made at home by investing in diet-pill stocks.

I'd rather get more spam.

More information

Spread the word to prevent greylisting. Digg this story.

Update: Response to comments

It tells me a lot that the huge influx of comment authors (trolls from Reddit) who argue for greylisting are predominantly server administrators who have enabled it for their users.

Their users have been suspiciously absent from this discussion, probably because they have no idea why it takes forever to get their email. They chalk it up to another random disappointment with computers, or "the network" being slow, or various other mythical computer problems.

In the case of account-activation emails from websites, they email the website operator to find out why their activation email hasn't yet arrived after 10 minutes. How do I know this? Because I administer some big sites that have this problem, and I get the "bug" reports when users complain that the emails aren't being sent. Every time, I find the section of the mail log for their email address, and 75% of the time, it's the recipient's greylisting that's delaying mail from a very legitimate, fully compliant Postfix server hosted in a major datacenter. (Most of the remaining 25% are email address typos.)

They don't know that the problem is on their end, and was probably imposed by a short-sighted (or simply cheap) server administrator. They, like me, expect email to arrive within a minute, and assume that if it hasn't arrived by then, there's something wrong. There's no technological limitation to prevent most messages from being delivered within 10 seconds.

Greylisting can be configured to be slightly less annoying by having a generous whitelist (a list of senders whose messages aren't delayed), or by only delaying suspected-spam IP ranges such as broadband home users or most of Russia. But this still imposes the delay on a lot of legitimate email (at least one message from every sender), and most importantly, it relies too much on the server administrators to get things exactly right.

There are a lot of good server administrators out there, but like any job, the majority of them are mediocre at best. The administrators at FastMail, for example, never whitelisted the Marco.org server, despite repeated conversations in which I informed them that Rackspace is not a dial-up ISP and should therefore be eligible for their IP whitelist. (Yes, Rackspace. I was dumbfounded. A sysadmin who's never heard of Rackspace is like a mechanic who's never heard of Ferrari.) Rackspace servers still never get whitelisted by FastMail's greylisting, so every message is delayed regardless of the sender's history.

Many readers criticized me for my high expectations of email, claiming that I should use instant messaging for communication intended for rapid delivery. This doesn't really work either:

Both parties must be members of the same IM networks.

Each party must know the other's screen name. This requirement renders IMs useless for websites trying to validate their users.

Both parties must be running their IM clients, and must be signed in at that moment. I work with a lot of people with laptops who travel through various networks every day, so this just isn't realistic. Any laptop user will understand.

Ever try sending a file through IM? By the time you figure out how to get through the NAT on both ends, a greylisted email may have arrived.

IMs only work gracefully when the recipient is one person.

We already have a near-instantaneous communication protocol with minimal requirements on either end that's very tolerant of NAT and irregular connectivity, accessible by everyone running any software on any platform.

It's called email.

Stop ruining it.