RFC 6647 Proposed Standard Anti-abuse and operations

Email Greylisting: An Applicability Statement for SMTP

This document describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism. Greylisting is an established mechanism deemed essential to the repertoire of current anti-abuse email filtering systems. [STANDARDS-TRACK]

Status
Proposed Standard. On the standards track and stable enough to implement against. Most of the email stack stays at this level permanently.
Published
June 2012
Authors
M. Kucherawy, D. Crocker
Read it
rfc-editor.org · DOI

What it is

Greylisting: temporarily rejecting a first delivery attempt from an unknown sender and accepting the retry.

What it solves

A great deal of abuse came from software that never retried, so a temporary failure separated real MTAs from the rest cheaply.

What it means to operate

Less effective than it was, and it costs every legitimate sender a delay measured in minutes on first contact. From the sending side it is a common and benign cause of 4xx on first attempt: retry on the normal schedule and do not treat it as a reputation signal.

Bounce classifier tells a greylisting deferral apart from a refusal. Open bounce classifier

Normative requirements

Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from.

4.2 Unintended SMTP Client Failures

  • SHOULDo Alternate (MX) servers SHOULD share the same greylisting database.
  • SHOULDo When alternate MX servers relay mail back to the "primary" MX server, the latter SHOULD be configured to permit the other servers to relay mail without being subjected to greylisting.

5 Recommendations

  • RECOMMENDEDThe following practices are RECOMMENDED based on collected experience:
  • SHOULDThe default range SHOULD be from one minute to 24 hours.
  • SHOULDRetries after the end of the range SHOULD be considered to be a new message for the purposes of greylisting evaluation (i.e., reset the "first seen" timestamp for that IP address).
  • SHOULDThe default SHOULD be at least one week.
  • SHOULDFor an Administrative Management Domain (ADMD), all inbound border MTAs listed in the [DNS] SHOULD share a common greylisting database and common greylisting policies.
  • MAYTo accommodate those senders that have clusters of outgoing mail servers, greylisting servers MAY track CIDR blocks of a size of its own choosing, such as /24, rather than the full IPv4 address.
  • MAY(Note, however, that this heuristic will not work for clusters having machines on different networks.) A similar grouping capability MAY be established based on the domain name of the mail server if one can be determined.
  • SHOULDThere are also some highly visible online entities such as email service providers that will be certain to retry; thus, those that are known SHOULD be allowed to bypass the filter.
  • SHOULD NOTGreylisting SHOULD NOT be applied by an ADMD's submission service (see [SUBMISSION]) for authenticated client hosts.
  • SHOULDIt also SHOULD not be applied against any authenticated ADMD session.

Every current email RFC