Email Greylisting: An Applicability Statement for SMTP
RFC 6647
Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 6647 Cloudmark
Category: Standards Track D. Crocker
ISSN: 2070-1721 Brandenburg InternetWorking
June 2012
Email Greylisting: An Applicability Statement for SMTP
Abstract
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.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6647.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Kucherawy & Crocker Standards Track [Page 1]
RFC 6647 Greylisting June 2012
Table of Contents
1. Introduction ....................................................3
1.1. Background .................................................3
1.2. Definitions ................................................4
2. Types of Greylisting ............................................4
2.1. Connection-Level Greylisting ...............................4
2.2. SMTP HELO/EHLO Greylisting .................................5
2.3. SMTP MAIL Greylisting ......................................5
2.4. SMTP RCPT Greylisting ......................................5
2.5. SMTP DATA Greylisting ......................................6
2.6. Additional Heuristics ......................................7
2.7. Exceptions .................................................7
3. Benefits and Costs ..............................................8
4. Unintended Consequences .........................................9
4.1. Unintended Mail Delivery Failures ..........................9
4.2. Unintended SMTP Client Failures ...........................10
4.3. Address Space Saturation ..................................11
5. Recommendations ................................................12
6. Measuring Effectiveness ........................................13
7. IPv6 Applicability .............................................14
8. Security Considerations ........................................14
8.1. Trade-Offs ................................................14
8.2. Database ..................................................14
9. References .....................................................15
9.1. Normative References ......................................15
9.2. Informative References ....................................15
Appendix A. Acknowledgments ......................................17
Kucherawy & Crocker Standards Track [Page 2]
RFC 6647 Greylisting June 2012
1. Introduction
Preferred techniques for handling email abuse explicitly identify
good actors and bad actors, giving each significantly different
service quality. In some cases, an actor does not have a known
reputation; this can justify providing degraded service, until there
is a basis for providing better service. This latter approach is
known as "greylisting". Broadly, the term refers to any degradation
of service for an unknown or suspect source, over a period of time
(typically measured in minutes or a small number of hours). The
narrow use of the term refers to generation of an SMTP temporary
failure reply code for traffic from such sources. There are diverse
implementations of this basic concept and predictably, therefore,
Show full document text