Greylisting is a simple method of defending electronic mail users against e-mail spam. In short, a mail transfer agent which uses greylisting will “temporarily reject” any email from a sender it does not recognize. If the mail is legitimate, the originating server will try again to send it later, at which time the destination will accept it. If the mail is from a spammer, it will probably not be retried, however, even spam sources which re-transmit later will be more likely to be listed in DNSBLs and distributed signature systems such as Vipul’s Razor.
Greylisting requires little configuration and modest resources. It is designed as a complement to existing defenses against spam, and not as a replacement.
The word is sometimes spelled graylisting in the United States.
How it works
Typically, a server that uses greylisting will record the following three pieces of information (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 e-mail 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 e-mail delivery, a legitimate server will attempt to connect again later on to deliver the e-mail.
Greylisting is effective because many mass e-mail 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 particular message in their databases. Thus, these subsequent attempts are more likely to be detected as spam by other mechanisms than they were at first.
The main advantage from the users’ point of view is that greylisting requires no additional 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 less system resources are used allowing more layers of spam filtering or higher throughput.
There is a possibility that poorly-configured e-mail systems will translate the temporary reject as a permanent bounce and not deliver the mail, which would lead to legitimate mail being bounced. This can be prevented with whitelisting or exception lists.
Greylisting delays all unknown e-mail, not just spam.
Since there is always an ongoing arms race between legitimate e-mail administrators and those who send bulk e-mail, the likelihood is that spam tools which are thwarted by greylisting will be fixed to circumvent this safeguard in the future.
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 e-mail is a server farm, it is possible that on the retry, a server other than the original server will make the second 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 second as well. The problem can be bypassed by identifying and whitelisting such server farms in advance.
Licensed under the GNU Free Documentation License. It uses materials from the Wikipedia.