Email Greylisting: An Applicability Statement for SMTP
Extracted elements (27)
Greylisting exploits the behavior of spamware, which typically does not retry delivery after receiving a 4xx temporary failure response. Volume matters more than reliability to spammers, so they move on rather than retry, allowing greylisting to filter them out without permanently blocking the source.
Greylisting is designed to be cheap and to apply early in the SMTP session sequence, before expensive content analysis. Though some spamware routes around it, it remains useful for removing a large volume of simplistic-but-significant abusive traffic.
IPv6 applicability of greylisting is uncertain. The larger address space may allow bad actors to behave differently, potentially negating greylisting benefits or requiring substantially different algorithm parameters. The required database would also be substantially larger for IPv6.
Only the first RFC5321.RcptTo is used in the recommended tuple because legitimate MTAs appear not to reorder recipients between retries. Including RFC5321.MailFrom improves accuracy when IP addresses are matched in CIDR clusters rather than precisely.
Per RFC 5321, the only two reasonable 4yz reply choices for a greylisting implementation are 421 (to terminate the connection immediately) and 450 (for all other cases). No specific recommendation is made between these, as no data indicates one is particularly advantageous over the other.
Post-DATA greylisting is substantially more expensive than earlier-phase alternatives because it requires accepting and temporarily storing a complete message body, plus any content processing. As a result, DATA-level greylisting is not typical practice.
For DATA-level greylisting, if any portion of the message is reformulated between delivery attempts (a behavior exhibited by some MTAs at submission time), the constructed tuple may differ from the original attempt, causing the delivery to be greylisted again as if new.
NAT causes multiple distinct outbound MTAs to appear to originate from a single shared IP address. This can cause greylisting to be applied only to the first connection from that address, exempting later MTAs connecting for the first time from greylisting protection.
Sites with multiple outbound MTAs sharing a common queue may experience repeated greylisting: when a retry uses a different outbound MTA with a different IP address, the receiving server treats it as a first-time connection. DHCP-induced address changes between attempts produce the same effect.
Some SMTP clients encode message-specific details in the MAIL command address parameter, causing the parameter to change between retry attempts. A greylisting implementation may treat each attempt as a new delivery rather than a retry, resulting in permanent delivery failure after the retry timeout expires.
Some SMTP clients treat 4yz temporary failure replies as 5yz permanent failures and return messages as undeliverable, or do not retry at all in violation of RFC 5321. Greylisting will cause outright delivery failure for such clients on the first attempt.
When a domain has multiple inbound MTA servers that do not share a greylisting database, a client greylisted by one server may retry to another and be greylisted again, amplifying delivery delays rather than resolving them for otherwise legitimate senders.
A configurable retry time range SHOULD default from one minute to 24 hours. Retries within this range satisfy the greylisting test. Retries after the end of the range SHOULD be treated as a new message, resetting the 'first seen' timestamp for the IP address.
All inbound border MTAs for an Administrative Management Domain (ADMD) that are listed in DNS SHOULD share a common greylisting database and common greylisting policies, so that a client's retry to a different server is correctly recognized.
Alternate (MX) servers SHOULD share the same greylisting database. When alternate MX servers relay mail back to the primary MX server, the primary SHOULD be configured to permit the other servers to relay without being subjected to greylisting.
Database records for IP addresses that have generated no recent traffic SHOULD be expired. The default expiry SHOULD be at least one week, enabling re-evaluation of addresses that may have changed owners since their last recorded contact.
Greylisting servers MAY track CIDR blocks (e.g., /24) rather than full IPv4 addresses to accommodate clusters of outgoing mail servers. A similar grouping MAY be established based on the mail server's domain name.
Greylisting SHOULD NOT be applied by an ADMD's submission service for authenticated client hosts, and SHOULD NOT be applied against any authenticated ADMD session. Authentication may include known internal IP addresses, protocol-level client authentication, or similar mechanisms.
It is RECOMMENDED to implement greylisting based on a tuple of (IP address, RFC5321.MailFrom, first RFC5321.RcptTo). After a successful retry, all further SMTP traffic from that IP address in the tuple SHOULD be allowed regardless of envelope information.
Connection-level greylisting evaluates only the incoming IP address and/or host name. If the source is not in the database or has not reached a required minimum age, the server returns either a 421 reply closing the connection, or a 4yz reply to all further commands in the session.
Greylisting implementations SHOULD provide an exception mechanism allowing specific IP addresses, CIDR blocks, host names, or domain names to bypass greylisting. Known good senders that do not respond well to greylisting, or that are certain to retry, are typical candidates for exceptions.
HELO/EHLO greylisting retains records of (source, HELO/EHLO parameter) tuples. A 4yz reply is returned to all commands for the remainder of the SMTP session if the tuple is new or has not reached a configured minimum age.
SMTP DATA greylisting can be applied on receipt of the DATA command (entire envelope known) or on completion of DATA (message content available). Tuple components may include source, return address, recipients, message header fields, content digests, or arbitrary body analysis.
SMTP MAIL greylisting retains records of (source, RFC5321.MailFrom) tuples. A 4yz reply is returned for the remainder of the session if the tuple is new or has not met a configured minimum age.
SMTP RCPT greylisting retains tuples combining the recipient address with any combination of source, return address, and other recipients. A 4yz reply is issued for the remainder of the session if the tuple is not found or has not reached minimum age. A match on the first valid RCPT is typically sufficient to identify a retry.
Although greylisting provides valuable defenses, it introduces delay that can be harmful for time-sensitive financial, transactional, or security-related email. Exempting specific sources from greylisting grants them elevated access privilege that malefactors could seek to exploit by spoofing or compromising those sources.
An attacker aware of the greylisting scheme in use could rotate SMTP client parameters to continuously generate new tuples, inflating the greylisting database toward denial-of-service. Implementers should configure a failure policy for when the database is unavailable or under attack.