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. Appendix A. Acknowledgments 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]