Over the past several years, greylisting has become increasing popular among mail server administrators in an effort to combat spam. It works by having the server temporarily reject any email message from a sender that it does not recognize. This will cause the sender’s mail server to wait for a while and then attempt to resend the message. On the subsequent attempt, the recipient’s mail server will recognize the sender, accept the message and deliver it. The reason that greylisting works is because most spamware doesn’t behave like a standard mail server and won’t attempt to resend messages that have been rejected. It’s an attractive option for many mail server administrators because it’s relatively easy to implement and doesn’t require much in the way of maintenance. There are no rule tables to update, no scripts to write and no Bayesian filters to train to recognize new spam. However, greylisting can introduce new problems of its own.
Because greylisting temporarily rejects the first email message from a sender that it does not recognize, it forces the sender’s mail server to retain the message and queue it for another delivery attempt. The interval at which messages are resent depends on its configuration, and can be anywhere from ten minutes up to several hours. This can present a problem to businesses that depend on email, particularly with anything that is of a time-sensitive nature. Neither the sender nor the recipient have any direct control over the amount of time that the server will wait before resending the message. To avoid the delay, the sender can be whitelisted, however this typically requires some action on the part of an administrator. While greylisting can help reduce spam, it also inherently reduces the reliability of email.
Another problem with greylisting is how some mail servers handle the initial rejection. If the recipient’s mail server doesn’t recognize the sender’s email address, it will respond with a 450 error (or another status code in the 400-499 range). This should tell the sender’s mail server that it cannot accept the message at that time, and it should attempt to resend the message at some point in the future. However, some mail servers will treat that error as a permanent rejection. Instead of resending the message, the server considers the email to be undeliverable and bounces it back to the sender. As a result, the sender will typically think that the email address is no longer valid.
Greylisting also imposes additional workload and storage requirements on the sender’s mail server. It is forced to establish twice the number of connections to deliver the message, and it’s required to store that message until redelivery completes. For individuals or smaller organizations, that’s not a significant problem. But for companies that have a very high volume of mail, greylisting can cumulatively increase the CPU time, network bandwidth and disk space required to deliver messages. If greylisting could be used instead of filtering, there’s no question that the net result would be a reduction in resource utilization on the sender’s mail server. However, because filtering will still be required, both methods are used and the result is an overall increase in resource utilization.
Ultimately, greylisting works by taking advantage of a deficiency in how most spamware is currently written, but it’s not a long-term solution. As greylisting becomes more widespread, the spammers will adapt to it. More and more of the programs that they use to deliver their spam will have the ability to queue and resend messages, which means that in the long run it has simply increased the amount of time and network traffic required to send an email message.