idnits 2.17.1 draft-ietf-appsawg-email-auth-codes-07.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7208]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 8, 2014) is 3549 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7001 (Obsoleted by RFC 7601) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Kucherawy 3 Internet-Draft August 8, 2014 4 Updates: 7208 (if approved) 5 Intended status: Standards Track 6 Expires: February 9, 2015 8 Email Authentication Status Codes 9 draft-ietf-appsawg-email-auth-codes-07 11 Abstract 13 This document registers code points to allow status codes to be 14 returned to an email client to indicate that a message is being 15 rejected or deferred specifically because of email authentication 16 failures. 18 This document updates [RFC7208] since some of the code points 19 registered replace the ones recommended for use in that document. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 9, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. New Enhanced Status Codes . . . . . . . . . . . . . . . . . . . 3 58 3.1. DKIM Failure Codes . . . . . . . . . . . . . . . . . . . . 3 59 3.2. SPF Failure Codes . . . . . . . . . . . . . . . . . . . . . 4 60 3.3. Reverse DNS Failure Code . . . . . . . . . . . . . . . . . 5 61 3.4. Multiple Authentication Failures Code . . . . . . . . . . . 5 62 4. General Considerations . . . . . . . . . . . . . . . . . . . . 6 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 65 7. Normative References . . . . . . . . . . . . . . . . . . . . . 7 66 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 [RFC3463] introduced Enhanced Mail System Status Codes, and [RFC5248] 71 created an IANA registry for these. 73 [RFC6376] and [RFC7208] introduced, respectively, DomainKeys 74 Identified Mail (DKIM) and Sender Policy Framework (SPF), two 75 protocols for conducting message authentication. Another common 76 email acceptance test is the reverse Domain Name System (DNS) check 77 on an email client's IP address, as described in Section 3 of 78 [RFC7001]. 80 The current set of enhanced status codes does not include any code 81 for indicating that a message is being rejected or deferred due to 82 local policy reasons related to any of these mechanisms. This is 83 potentially useful information to agents that need more than 84 rudimentary handling information about the reason a message was 85 rejected on receipt. This document introduces enhanced status codes 86 for reporting those cases to clients. 88 Section 3.2 updates [RFC7208], as new enhanced status codes relevant 89 to that specification are being registered and recommended for use. 91 2. Key Words 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 95 "OPTIONAL" in this document are to be interpreted as described in 96 [RFC2119]. 98 3. New Enhanced Status Codes 100 The following new enhanced status codes are defined: 102 3.1. DKIM Failure Codes 104 In the code point definitions below, the following definitions are 105 used: 107 passing: A signature is "passing" if the basic DKIM verification 108 algorithm as defined in [RFC6376] succeeds. 110 acceptable: A signature is "acceptable" if it satisfies all locally 111 defined requirements (if any) in addition to passing the basic 112 DKIM verification algorithm (e.g., certain header fields are 113 included in the signed content; no partial signatures; etc.). 115 Code: X.7.20 116 Sample Text: No passing DKIM signature found 117 Associated basic status code: 550 118 Description: This status code is returned when a message 119 did not contain any passing DKIM 120 signatures. (This violates the 121 advice of Section 6.1 of RFC6376.) 122 Reference: [this document]; RFC6376 123 Submitter: M. Kucherawy 124 Change controller: IESG 126 Code: X.7.21 127 Sample Text: No acceptable DKIM signature found 128 Associated basic status code: 550 129 Description: This status code is returned when a message 130 contains one or more passing DKIM signatures, 131 but none are acceptable. (This violates the 132 advice of Section 6.1 of RFC6376.) 133 Reference: [this document]; RFC6376 134 Submitter: M. Kucherawy 135 Change controller: IESG 137 Code: X.7.22 138 Sample Text: No valid author-matched DKIM signature found 139 Associated basic status code: 550 140 Description: This status code is returned when a message 141 contains one or more passing DKIM 142 signatures, but none are acceptable because 143 none have an identifier(s) 144 that matches the author address(es) found in 145 the From header field. This is a special 146 case of X.7.21. (This violates the advice 147 of Section 6.1 of RFC6376.) 148 Reference: [this document]; RFC6376 149 Submitter: M. Kucherawy 150 Change controller: IESG 152 3.2. SPF Failure Codes 153 Code: X.7.23 154 Sample Text: SPF validation failed 155 Associated basic status code: 550 156 Description: This status code is returned when a message 157 completed an SPF check that produced a 158 "fail" result, contrary to local policy 159 requirements. Used in place of 5.7.1 as 160 described in Section 8.4 of RFC7208. 161 Reference: [this document]; RFC7208 162 Submitter: M. Kucherawy 163 Change controller: IESG 165 Code: X.7.24 166 Sample Text: SPF validation error 167 Associated basic status code: 451/550 168 Description: This status code is returned when evaluation 169 of SPF relative to an arriving message 170 resulted in an error. Used in place of 171 4.4.3 or 5.5.2 as described in Sections 172 8.6 and 8.7 of RFC7208. 173 Reference: [this document]; RFC7208 174 Submitter: M. Kucherawy 175 Change controller: IESG 177 3.3. Reverse DNS Failure Code 179 Code: X.7.25 180 Sample Text: Reverse DNS validation failed 181 Associated basic status code: 550 182 Description: This status code is returned when an SMTP 183 client's IP address failed a reverse DNS 184 validation check, contrary to local policy 185 requirements. 186 Reference: [this document]; Section 3 of RFC7001 187 Submitter: M. Kucherawy 188 Change controller: IESG 190 3.4. Multiple Authentication Failures Code 191 Code: X.7.26 192 Sample Text: Multiple authentication checks failed 193 Associated basic status code: 550 194 Description: This status code is returned when a message 195 failed more than one message authentication 196 check, contrary to local policy requirements. 197 The specific mechanisms that failed are not 198 specified. 199 Reference: [this document] 200 Submitter: M. Kucherawy 201 Change controller: IESG 203 4. General Considerations 205 By the nature of the Simple Mail Transfer Protocol (SMTP), only one 206 enhanced status code can be returned for a given exchange between 207 client and server. However, an operator might decide to defer or 208 reject a message for a plurality of reasons. Clients receiving these 209 codes need to consider that the failure reflected by one of these 210 status codes might not reflect the only reason, or the most important 211 reason, for non-acceptance of the message or command. 213 It is important to note that Section 6.1 of [RFC6376] discourages 214 special treatment of messages bearing no valid DKIM signature. There 215 are some operators that disregard this advice, a few of which go so 216 far as to require a valid Author Domain signature (that is, one 217 matching the domain(s) in the From header field) in order to accept 218 the message. Moreover, some nascent technologies built atop SPF and 219 DKIM depend on such authentications. This work does not endorse 220 configurations that violate DKIM's recommendations, but rather 221 acknowledges that they do exist and merely seeks to provide for 222 improved interoperability with such operators. 224 A specific use case for these codes is mailing list software, which 225 processes rejections in order to remove from the subscriber set those 226 addresses that are no longer valid. There is a need in that case to 227 distinguish authentication failures versus indications that the 228 recipient address is no longer valid. 230 If a receiving server performs multiple authentication checks, and 231 more than one of them fails thus warranting rejection of the message, 232 the SMTP server SHOULD use the code that indicates multiple methods 233 failed rather than only reporting the first one that failed. It may 234 be the case that one method is always expected to fail, and thus 235 returning that method's specific code is not information useful to 236 the sending agent. 238 The reverse IP DNS check is defined in Section 2.6.3 of [RFC7001]. 240 Any message authentication or policy enforcement technologies 241 developed in the future should also include registration of their own 242 enhanced status codes so that this kind of specific reporting is 243 available to operators that wish to use them. 245 5. Security Considerations 247 Use of these codes reveals local policy with respect to email 248 authentication, which can be useful information to actors attempting 249 to deliver undesired mail. It should be noted that there is no 250 specific obligation to use these codes; if an operator wishes not to 251 reveal this aspect of local policy, it can continue using a generic 252 result code such as 5.7.7, 5.7.1, or even 5.7.0. 254 6. IANA Considerations 256 Registration of new enhanced status codes, for addition to the 257 Enumerated Stauts Codes sub-registry of the SMTP Enhanced Status 258 Codes Registry, can be found in Section 3. 260 7. Normative References 262 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 263 Requirement Levels", BCP 14, RFC 2119, March 1997. 265 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", 266 RFC 3463, January 2003. 268 [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced 269 Mail System Status Codes", BCP 138, RFC 5248, June 2008. 271 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 272 Identified Mail (DKIM) Signatures", STD 76, RFC 6376, 273 September 2011. 275 [RFC7001] Kucherawy, M., "Message Header Field for Indicating 276 Message Authentication Status", RFC 7001, September 2013. 278 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 279 Authorizing Use of Domains in Email, Version 1", RFC 7208, 280 April 2014. 282 Appendix A. Acknowledgments 284 Claudio Allocchio, Dave Crocker, Ned Freed, Arnt Gulbrandsen, Scott 285 Kitterman, Barry Leiba, Alexey Melnikov, S. Moonesamy, Hector Santos, 286 and Stephen Turnbull contributed to this work. 288 Author's Address 290 Murray S. Kucherawy 291 270 Upland Drive 292 San Francisco, CA 94127 293 USA 295 EMail: superuser@gmail.com