Greylisting

Anti-spam technique: Greylisting
Date of first use:	early 2000s
Effectiveness:	Medium
Popularity:	Low, increasing
Difficulty of implementation:	Medium
Where implemented:	MTA
Harm:	Low

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 RFC says 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, and in a few cases a hash of the message body. Some systems remember (IP, to, from), sometimes known as a 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)
• long delays when the retry time of the sending system is too long - some big ISPs set this value to values bigger than 4 hours and even a day.
• unwanted interactions with servers doing callbacks
• extra burden on the sending MTAs

A few legitimate mail clients don't work with greylisting, either because they don't retry, or they retry in a way that the greylisting server doesn't recognize. Often, whitelist tables of such hosts need to be maintained.

References

• M. Kucherawy and D. Crocker, Email Greylisting: An Applicability Statement for SMTP", RFC 6647