Greylisting (sometimes spelled graylisting) is a process of defending electronic mail users against e-mail spam. A mail transfer agent using greylisting will "temporarily reject" any email from a sender it does not recognize. If the mail is legitimate, the originating server will most likely try again to send it later (see disadvantages), at which time the destination will accept it. If the mail is from a spammer, it will probably not be retried, and spam sources which re-transmit later are more likely to be listed in DNSBLs and distributed signature systems such as Vipul's Razor.

How it works

Typically, a server employing greylisting will record the three pieces of data known as a "triplet" for each incoming mail message:

The IP address of the connecting host

The envelope sender address

The envelope recipient address

This is checked against the mail server's internal database. If this triplet has not been seen before (within some configurable period), the email is greylisted for a short time (also configurable), and it is refused with a temporary rejection. The assumption is that since temporary failures are built into the RFC specifications for email delivery, a legitimate server will attempt to connect again later on to deliver the email.

In practice, most greylisting systems do not require an exact match on the IP address and the sender address. Because large senders often have a pool of machines that can send (and resend) email, IP addresses that have the most-significant 24 bits (/24) the same are treated as equivalent, or in some cases SPF records are used to determine the sending pool. Similarly, with mailing lists which use unique per-message return-paths (via variable envelope return path or VERP), if an exact match on the sender address is required, each post from such a mailing list will be delayed. Instead, some greylisting systems try to eliminate the variable parts of the VERP by using only the sender domain and the beginning of the local-part of the sender address.

Greylisting is effective because many mass email tools used by spammers will not bother to retry a failed delivery, so the spam is never delivered. When a spammer does retry a delivery after the waiting period has expired, however, it will likely be after a number of automated honeypots have detected the spam source and listed both the source and the specific message in their databases.Therefore, these subsequent attempts are more likely to be detected as spam by other mechanisms than they were at first.

Advantages

The main advantage from the users' point of view is that greylisting requires no extra configuration from their end. If the server utilizing greylisting is configured appropriately, the end user will only notice a delay on the first message from a given sender.

From a mail administrator's point of view the benefit is twofold. Greylisting takes minimal configuration to get up and running with occasional modifications of any local whitelists. The second benefit is that rejecting email with a temporary 450 error (actual error code is implementation dependent) is very cheap in system resources. Most spam filtering tools are very intensive users of CPU and memory. By stopping spam before it hits filtering processes, far fewer system resources are used. This allows more layers of spam filtering or higher throughput.

Disadvantages

Perhaps the most significant disadvantage of greylisting is the fact that, like all spam mitigation techniques, it destroys the near-instantaneous nature of email people have come to expect, and throws email back to the early days when it was slow and unreliable. A customer of a greylisting ISP can not always rely on getting every email in a small amount of time.Thereforeemail loses its function as easy and effortless vehicle to transfer electronic information instantanously.

On a technical level, some SMTP clients and SMTP servers acting as clients may interpret the temporary rejection as a permanent failure. Old clients conforming only to the original specification (RFC 821) are permitted to give up on delivery after the first failed attempt, although it is considered a poor practice -- RFC 821 states that clients "should" retry messages. However, it is a violation of more modern SMTP technical specifications for the client to fail to retry. The present SMTP specification (RFC 2821) clearly states that "the SMTP client retains responsibility for delivery of that message" (section 4.2.5) and "the SMTP client is encouraged to try again", and "mail that can't be transmitted instantly MUST be queued and episodically retried by the sender." (section 4.5.4.1)

This problem can affect SMTP clients in unexpected ways. Most MTAs will queue and retry messages, but a small number do not. A similar concern exists for applications which act as SMTP clients and fail to incorporate any form of queueing for deferred SMTP mail. This can be mitigated on the sending side by configuring the application to use a local SMTP server as an outbound queue, instead of attempting direct delivery. For the server operator who uses greylisting, clients which are known to fail on temporary errors can be supported by whitelisting or exception lists.

Some MTAs, upon encountering the temporary failure message from a greylisting server on the first attempt, will send a warning message back to the original sender of the message. The warning message is not a bounce message, but it is often formatted similarly to and reads like one. This practice often causes the sender to believe that the message has not been delivered, when in fact the message will be delivered successfully at a later time.

When a mail server is greylisted, the duration of time between the initial delay and the re-transmission is variable. Some mail servers use a default of four hours, though most will retry sooner. Most open-source MTAs have retry rules set to attempt delivery after around fifteen minutes (Sendmail default is 0, 15, ..., Exim default is 0, 15, ..., Postfix default is 0, 16.6, ..., Qmail default is 0, 6:40, 26:40, ...).

Greylisting delays much of the mail from non-whitelisted mail servers - not just spam - until typical patterns of communication are recorded by the greylisting system.

Also, legitimate mail might not get delivered, if the retry doesn't come within the time window the greylisting software uses, or if the retry comes from a different IP address than the original attempt: When the source of an email is a server farm or goes out through an anti-spam mail relay service it is likely that on the retry a server other than the original server will make the next attempt. Since the IP addresses will be different, the recipient's server will fail to recognize that the two attempts are related and refuse the latest connection as well. This can continue until the message ages out of the queue if the number of servers is large enough. The problem can be partially bypassed by identifying and whitelisting such server farms in advance. However, it is not possible on a distributed network the size of the Internet to maintain a complete list of all such server farms.

Greylisting can be a specific nuisance with websites that require you to create an account and confirm your email address before you can begin using them. Because greylisting will delay, possibly for several hours, the initial email containing your signup confirmation link, it will introduce a waiting period although the actual website may send out your email confirmation code immediately.

In order for greylisting to work for a specific domain, all backup mail servers (as specified by lower-priority MX records for the domain) must implement the greylisting policy as well. This may not be easily achievable if the backup mail server is not under direct control of the domain owner.