Almost everyone in the antispam community is quite familiar with the concept of greylisting. However, it’s not always clear to the rest of the world how exactly the technology works.
We’re implementing this technology in our next version of our corporate email security product, Ninja, and our product manager for email security, Quentin DeWitt, using some other source s and his own input, put together a nice little overview of what it is and how it works.
Greylisting.
Greylisting is a method of defending against e-mail spam. A mail server which uses Greylisting will “temporarily reject” any e-mail from a sender it does not recognize. If the mail is legitimate, the originating mail server will try again to send it later, at which time your e-mail server will accept it. If the e-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 Antispam databases.
Greylisting requires little configuration and few resources. It is designed as a complement to existing defenses against spam, and not as a replacement.
How it works.
Typically, a server that uses Greylisting will record the following three pieces of information (known as a “triplet”) for each incoming e-mail message:
- The IP address of the connecting e-mail server
- The sender e-mail address
- The recipient e-mail address
This is checked against the e-mail server’s internal database. If this triplet has not been seen before (within some configurable period), the e-mail is grey listed 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.
Is Greylisting Effective?
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.
How useful is Greylisting?
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 e-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 allowlists. 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. This allows more layers of spam filtering or higher throughput.
Sunbelt Messaging Ninja and Greylisting
Greylisting within Ninja 2.1 will be turned off by default. It is easily enabled and setup through the Ninja console on the Exchange Server and operates in our Connection level filtering component in conjunction with RBL and SPF to fight spam at the border of your e-mail server. Once enabled it functions automatically to Greylist e-mail sent to the server and builds it’s own allowlist as well as taking into account those specified by the admin. The resources used be Greylisting in Ninja are very minimal. It should be setup only on the Front End server in a Front end/Back End Server setup. Once Greylisting is enabled you should see even less spam make it through to your inbox.
Alex Eckelberry