Individual submission M. Kucherawy
Internet-Draft Cloudmark, Inc.
Intended status: BCP October 24, 2011
Expires: April 26, 2012
Best Current Practices for Email Greylisting
draft-kucherawy-greylisting-bcp-01
Abstract
This memo describes best current practices for the art of email
greylisting, the practice of providing temporarily degraded service
to unknown email clients as an anti-abuse mechanism.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 26, 2012.
Copyright Notice
Copyright (c) 2011 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 Expires April 26, 2012 [Page 1]
Internet-Draft Email Greylisting BCP October 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. E-Mail Architecture Terminology . . . . . . . . . . . . . . 3
3. Deciding Who Is Affected . . . . . . . . . . . . . . . . . . . 3
4. Connection-Level Greylisting . . . . . . . . . . . . . . . . . 3
5. SMTP HELO/EHLO Greylisting . . . . . . . . . . . . . . . . . . 3
6. SMTP MAIL Greylisting . . . . . . . . . . . . . . . . . . . . . 4
7. SMTP RCPT Greylisting . . . . . . . . . . . . . . . . . . . . . 4
8. SMTP DATA Greylisting . . . . . . . . . . . . . . . . . . . . . 4
9. Effects on Clients . . . . . . . . . . . . . . . . . . . . . . 4
10. Benefits and Costs . . . . . . . . . . . . . . . . . . . . . . 4
11. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 5
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
13. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
14.1. Normative References . . . . . . . . . . . . . . . . . . . 5
14.2. Informative References . . . . . . . . . . . . . . . . . . 6
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 6
Kucherawy Expires April 26, 2012 [Page 2]
Internet-Draft Email Greylisting BCP October 2011
1. Introduction
There are many techniques in use for dealing with email abuse. One
is a set of techniques known as "greylisting". Broadly, this refers
to any degradation of service for an unknown or suspect source, over
a period of time. 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 general technique, and,
predictably therefore, some blurred terminology.
This memo documents common greylisting techniques and discusses their
benefits and costs. It also defines terminology to enable clear
distinction and discussion of these techniques.
2. Definitions
2.1. Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS].
2.2. E-Mail Architecture Terminology
Readers should be familiar with the material and terminology
discussed in [MAIL] and [EMAIL-ARCH].
3. Deciding Who Is Affected
This section will discuss how it is decided whether or not a
particular client session, or specific message, will be selected for
greylisting. Discuss selection criteria, e.g., {IP} vs. {IP, from,
to}.
4. Connection-Level Greylisting
This section will talk about greylisting applied at the time of
decision about whether or not to accept a new connection, even before
SMTP begins to take place.
5. SMTP HELO/EHLO Greylisting
This section will talk about greylisting applied within the [SMTP]
session at the HELO/EHLO phase.
Kucherawy Expires April 26, 2012 [Page 3]
Internet-Draft Email Greylisting BCP October 2011
6. SMTP MAIL Greylisting
This section will talk about greylisting applied within the [SMTP]
session at the MAIL FROM phase.
7. SMTP RCPT Greylisting
This section will talk about greylisting applied within the [SMTP]
session at the RCPT TO phase.
8. SMTP DATA Greylisting
This section will talk about greylisting applied within the [SMTP]
session at the DATA phase.
Some implementations do filtering here because there are clients that
don't bother checking SMTP reply codes to commands other than DATA.
9. Effects on Clients
This section will discuss the behaviours of SMTP clients when
greylisting is in effect, such as:
o very long retry times
o aggressive retries can hit rate limits
o incorrect handling of greylisting replies (e.g., treat 4xx like
5xx)
o retries may change envelope sender
10. Benefits and Costs
This section will discuss the benefits and also the costs (resources
and impacts on generals ervice) of the various implementations.
Discuss failure modes, including:
o all retries fail
o retries go to a different server that doesn't know about previous
attempts
o retries come from a different client than earlier ones
o for systems that use body hashes, the retries aren't the same as
the previous attempts
Kucherawy Expires April 26, 2012 [Page 4]
Internet-Draft Email Greylisting BCP October 2011
11. Recommendations
This section will provide some general recommendations about when and
how to deploy greylisting in various conceptual environments.
Some points to discuss:
o logging of a greylisting server vs. one not greylisting can be a
good measure of how effective it is
o can also compare greylisting results to DNSBLs and content
filtering
o greylisting is more expensive than not greylisting
o greylisting delays legitimate mail, and can cause conversations to
arrive out of order
o time limits for greylisting
o special actions to take if the same message is retried before the
time limit expires
o recommended termiantion methods (421 vs. 4xx)
o affects/requirements on MXes other than the lowest
o ability to share information between servers
12. IANA Considerations
No actions are requested of IANA in this memo.
13. Security Considerations
This section discusses potential security issues related to
greylisting.
14. References
14.1. Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Kucherawy Expires April 26, 2012 [Page 5]
Internet-Draft Email Greylisting BCP October 2011
14.2. Informative References
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598,
October 2008.
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
The author wishes to acknowledge Mike Adkins, Steve Atkins, Dave
Crocker, Peter J. Holzer, John Levine, Jose-Marcio Martins da Cruz,
Jordan Rosenwald, Gregory Shapiro, and Joe Sniderman for their
contributions to this memo.
Author's Address
Murray S. Kucherawy
Cloudmark, Inc.
128 King St., 2nd Floor
San Francisco, CA 94107
US
Phone: +1 415 946 3800
EMail: msk@cloudmark.com
Kucherawy Expires April 26, 2012 [Page 6]