Greylisting
| Anti-spam technique: Greylisting | |
|---|---|
| Date of first use: | early 2000s |
| Effectiveness: | High |
| Popularity: | Low, increasing |
| Difficulty of implementation: | medium |
| Where implemented: | MTA |
| Harm: | Medium |
Greylisting (AKA graylisting) is an extremely effective method against illegitimate spammers who use cracked PCs (botnets, for example) to send the spam. It is utterly ineffective against spamers sending from conforming conventional MTAs.
SMTP requires clients to maintain a queue of outgoing messages. During a delivery attempt, a 4xx response code indicates a temporary failure. The client system must then retry the message. See RFC 2821 Section 4.5.4. Clients can immediately try another host listed in an MX record for the target domain, or re-queue the message and try again later. When the message is re-queued, the client SHOULD wait at least 30 minutes before the next delivery attempt, and generally should use progressively larger delays for each subsequent retry attempt.
Greylisting attempts to detect SMTP client systems that are not true SMTP servers and do not maintain a message queue, instead using a "blast and dump" approach.
Greylisting operates by initially deferring incoming messages by giving a 4xx (temporary failure) response during the smtp protocol dialogue. The receiving MTA stores information about the attempted delivery, at minimum the client SMTP system's IP address, but in some implementations also the envelope sender address and envelope recipient address). When all three items are stored, it is called the triplet.
If a new delivery attempt matching the stored client information (that is, the same IP address or the same triplet) arrives within the minimum delay time enforced by the receiving MTA, the retry is also rejected and the minimum delay time reset. If the retry arrives after the minimum delay time, the message is accepted and the saved data is marked so that subsequent attempts which match the saved data are immediately accepted with no delay. Depending on the implementation, subsequent attempts need only match the IP address of the client SMTP system, or the entire triplet.
While effective against certain kinds of spam, the technique has its drawbacks:
- greylisted messages are initially delayed, possibly for hours or days
- problems with outbound server pools that retry with different IPs
- problems with inbound server pools that accept connections on multiple IPs
- problems when the retry time of the sending system is smaller than the minimum retry time enforced by the receiving system (note that RFC 2821 says that the 30 minute delay is a SHOULD, not a MUST)
- unwanted interactions with servers doing callbacks
- extra burden on the sending MTAs
Because of the large number of situations and implementations in which problems occur, sites using greylisting need to monitor the greylisting state to detect legitimate sites whose mail is not being received. Often, whitelist tables of such hosts need to be maintained.
