idnits 2.17.1 draft-kucherawy-authres-spf-erratum-02.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 (Using the creation date from RFC5451, updated by this document, for RFC5378 checks: 2004-09-10) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 12, 2012) is 4429 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 5451 (ref. 'AUTHRES') (Obsoleted by RFC 7001) -- Obsolete informational reference (is this intentional?): RFC 5226 (ref. 'IANA') (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 4408 (ref. 'SPF') (Obsoleted by RFC 7208) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). 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 Updates: 5451 (if approved) February 12, 2012 5 Intended status: Standards Track 6 Expires: August 15, 2012 8 Authentication-Results Registration Update for SPF Results 9 draft-kucherawy-authres-spf-erratum-02 11 Abstract 13 This memo updates the registry of authentication method results in 14 Authentication-Results: message header fields, correcting a 15 discontinuity between the original registry creation and the SPF 16 specification. 18 This memo updates RFC5451. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 15, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. New 'fail' definition . . . . . . . . . . . . . . . . . . . . . 3 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3 58 4.1. Addition of 'Status' Columns . . . . . . . . . . . . . . . 3 59 4.2. Update to Result Names . . . . . . . . . . . . . . . . . . 4 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 6.1. Normative References . . . . . . . . . . . . . . . . . . . 4 63 6.2. Informative References . . . . . . . . . . . . . . . . . . 4 64 Appendix A. Examples in RFC5451 . . . . . . . . . . . . . . . . . 5 65 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . . 5 67 1. Introduction 69 [AUTHRES] defined a new header field for electronic mail messages 70 that presents the results of a message authentication effort in a 71 machine-readable format. That Request For Comments created a 72 registry of results for a few message authentication mechanisms, one 73 of which was the Sender Policy Framework [SPF]. The registry 74 contains one entry that is inconsistent with the latter 75 specification, which was noted in an erratum filed with the RFC 76 Editor. This memo updates the IANA registries accordingly. 78 2. Keywords 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [KEYWORDS]. 84 3. New 'fail' definition 86 The new "fail" result, replacing the existing "hardfail" result for 87 [SPF] (and thus also for [SENDER-ID]) has the same definition for 88 "hardfail" that was used in Section 2.4.2 of [AUTHRES], namely: 90 This client is explicitly not authorized to inject or relay mail 91 using the sender's DNS domain. 93 4. IANA Considerations 95 This section enumerates requested actions of IANA, per [IANA]. 97 4.1. Addition of 'Status' Columns 99 IANA is requested to amend the Email Authentication Methods and Email 100 Authentication Result Names registries, both in the Email 101 Authentication Parameters group, by adding to each a column called 102 "Status" that will indicate for each entry its current standards 103 status. Legal values for these columns are: 105 active: The entry is in current use. 107 deprecated: The entry is no longer in current use. 109 New registrations to either table MUST specify one of these values. 111 All exisitng entries, except as specified below, are to be noted as 112 "active" as of publication of this memo. 114 4.2. Update to Result Names 116 [AUTHRES] listed "hardfail" as the result to be used when a message 117 fails an [SPF] evaluation. However, this latter specification used 118 the string "fail" to denote such failures. 120 Therefore, IANA is requested to mark "hardfail" in the Email 121 Authentication Result Names registry as "deprecated", and amend the 122 "fail" entry as follows: 124 Code: fail 126 Defined: [AUTHRES] 128 Auth Method: spf, sender-id 130 Meaning: [this memo] Section 3 132 Status: active 134 5. Security Considerations 136 This memo corrects a registry error. It is possible that older 137 implementations will not recognize or use the corrected entry. Thus, 138 implementers are advised to support both result strings for some 139 period of time. However, it is known that some implementations are 140 already using the SPF-defined result string. 142 6. References 144 6.1. Normative References 146 [AUTHRES] Kucherawy, M., "Message Header Field for Indicating 147 Message Authentication Status", RFC 5451, April 2009. 149 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 150 Requirement Levels", BCP 14, RFC 2119, March 1997. 152 6.2. Informative References 154 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an 155 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 156 May 2008. 158 [SENDER-ID] Lyon, J. and M. Wong, "Sender ID: Authenticating 159 E-Mail", RFC 4406, April 2006. 161 [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 162 for Authorizing Use of Domains in E-Mail, Version 1", 163 RFC 4408, April 2006. 165 Appendix A. Examples in RFC5451 167 It should be noted that this update also applies to the examples in 168 [AUTHRES], specifically the one in Appendix B.5. The error there is 169 not corrected by this update, which only deals with the normative 170 portions of that specification and the related IANA registrations. 171 However, it is assumed one could easily see what needs to be 172 corrected there. 174 Corrected examples will be included in a full update to [AUTHRES] at 175 some future time. 177 Appendix B. Acknowledgements 179 The author wishes to acknowledge the following for their review and 180 constructive criticism of this proposal: S. Moonesamy, Scott 181 Kitterman. 183 Author's Address 185 Murray S. Kucherawy 186 Cloudmark, Inc. 187 128 King St., 2nd Floor 188 San Francisco, CA 94107 189 US 191 Phone: +1 415 946 3800 192 EMail: msk@cloudmark.com