idnits 2.17.1 draft-kucherawy-greylisting-bcp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 24, 2011) is 4561 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual submission M. Kucherawy 3 Internet-Draft Cloudmark, Inc. 4 Intended status: BCP October 24, 2011 5 Expires: April 26, 2012 7 Best Current Practices for Email Greylisting 8 draft-kucherawy-greylisting-bcp-01 10 Abstract 12 This memo describes best current practices for the art of email 13 greylisting, the practice of providing temporarily degraded service 14 to unknown email clients as an anti-abuse mechanism. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 26, 2012. 33 Copyright Notice 35 Copyright (c) 2011 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.2. E-Mail Architecture Terminology . . . . . . . . . . . . . . 3 54 3. Deciding Who Is Affected . . . . . . . . . . . . . . . . . . . 3 55 4. Connection-Level Greylisting . . . . . . . . . . . . . . . . . 3 56 5. SMTP HELO/EHLO Greylisting . . . . . . . . . . . . . . . . . . 3 57 6. SMTP MAIL Greylisting . . . . . . . . . . . . . . . . . . . . . 4 58 7. SMTP RCPT Greylisting . . . . . . . . . . . . . . . . . . . . . 4 59 8. SMTP DATA Greylisting . . . . . . . . . . . . . . . . . . . . . 4 60 9. Effects on Clients . . . . . . . . . . . . . . . . . . . . . . 4 61 10. Benefits and Costs . . . . . . . . . . . . . . . . . . . . . . 4 62 11. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 5 63 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 64 13. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 65 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 14.1. Normative References . . . . . . . . . . . . . . . . . . . 5 67 14.2. Informative References . . . . . . . . . . . . . . . . . . 6 68 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 There are many techniques in use for dealing with email abuse. One 73 is a set of techniques known as "greylisting". Broadly, this refers 74 to any degradation of service for an unknown or suspect source, over 75 a period of time. The narrow use of the term refers to generation of 76 an SMTP temporary failure reply code for traffic from such sources. 78 There are diverse implementations of this general technique, and, 79 predictably therefore, some blurred terminology. 81 This memo documents common greylisting techniques and discusses their 82 benefits and costs. It also defines terminology to enable clear 83 distinction and discussion of these techniques. 85 2. Definitions 87 2.1. Keywords 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [KEYWORDS]. 93 2.2. E-Mail Architecture Terminology 95 Readers should be familiar with the material and terminology 96 discussed in [MAIL] and [EMAIL-ARCH]. 98 3. Deciding Who Is Affected 100 This section will discuss how it is decided whether or not a 101 particular client session, or specific message, will be selected for 102 greylisting. Discuss selection criteria, e.g., {IP} vs. {IP, from, 103 to}. 105 4. Connection-Level Greylisting 107 This section will talk about greylisting applied at the time of 108 decision about whether or not to accept a new connection, even before 109 SMTP begins to take place. 111 5. SMTP HELO/EHLO Greylisting 113 This section will talk about greylisting applied within the [SMTP] 114 session at the HELO/EHLO phase. 116 6. SMTP MAIL Greylisting 118 This section will talk about greylisting applied within the [SMTP] 119 session at the MAIL FROM phase. 121 7. SMTP RCPT Greylisting 123 This section will talk about greylisting applied within the [SMTP] 124 session at the RCPT TO phase. 126 8. SMTP DATA Greylisting 128 This section will talk about greylisting applied within the [SMTP] 129 session at the DATA phase. 131 Some implementations do filtering here because there are clients that 132 don't bother checking SMTP reply codes to commands other than DATA. 134 9. Effects on Clients 136 This section will discuss the behaviours of SMTP clients when 137 greylisting is in effect, such as: 139 o very long retry times 141 o aggressive retries can hit rate limits 143 o incorrect handling of greylisting replies (e.g., treat 4xx like 144 5xx) 146 o retries may change envelope sender 148 10. Benefits and Costs 150 This section will discuss the benefits and also the costs (resources 151 and impacts on generals ervice) of the various implementations. 153 Discuss failure modes, including: 155 o all retries fail 157 o retries go to a different server that doesn't know about previous 158 attempts 160 o retries come from a different client than earlier ones 162 o for systems that use body hashes, the retries aren't the same as 163 the previous attempts 165 11. Recommendations 167 This section will provide some general recommendations about when and 168 how to deploy greylisting in various conceptual environments. 170 Some points to discuss: 172 o logging of a greylisting server vs. one not greylisting can be a 173 good measure of how effective it is 175 o can also compare greylisting results to DNSBLs and content 176 filtering 178 o greylisting is more expensive than not greylisting 180 o greylisting delays legitimate mail, and can cause conversations to 181 arrive out of order 183 o time limits for greylisting 185 o special actions to take if the same message is retried before the 186 time limit expires 188 o recommended termiantion methods (421 vs. 4xx) 190 o affects/requirements on MXes other than the lowest 192 o ability to share information between servers 194 12. IANA Considerations 196 No actions are requested of IANA in this memo. 198 13. Security Considerations 200 This section discusses potential security issues related to 201 greylisting. 203 14. References 205 14.1. Normative References 207 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 208 Requirement Levels", BCP 14, RFC 2119, March 1997. 210 14.2. Informative References 212 [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, 213 October 2008. 215 [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, 216 October 2008. 218 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 219 October 2008. 221 Appendix A. Acknowledgments 223 The author wishes to acknowledge Mike Adkins, Steve Atkins, Dave 224 Crocker, Peter J. Holzer, John Levine, Jose-Marcio Martins da Cruz, 225 Jordan Rosenwald, Gregory Shapiro, and Joe Sniderman for their 226 contributions to this memo. 228 Author's Address 230 Murray S. Kucherawy 231 Cloudmark, Inc. 232 128 King St., 2nd Floor 233 San Francisco, CA 94107 234 US 236 Phone: +1 415 946 3800 237 EMail: msk@cloudmark.com