idnits 2.17.1 draft-ietf-appsawg-authres-ptypes-registry-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7001]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC7001, but the abstract doesn't seem to directly say this. It does mention RFC7001 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 26, 2014) is 3532 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) == Missing Reference: 'SMTP' is mentioned on line 110, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7001 (Obsoleted by RFC 7601) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual submission M. Kucherawy 3 Internet-Draft August 26, 2014 4 Updates: 7001 (if approved) 5 Intended status: Standards Track 6 Expires: February 27, 2015 8 A Property Types Registry for the Authentication-Results Header Field 9 draft-ietf-appsawg-authres-ptypes-registry-02 11 Abstract 13 [RFC7001] describes a header field called Authentication-Results for 14 use with electronic mail messages to indicate the results of message 15 authentication efforts. Any receiver-side software, mainly Mail 16 Transfer Agents (MTAs) or mail filters, can add or use this header 17 field to relay that information in a convenient and meaningful way to 18 later-stage systems, such as for sorting and filtering decisions. 20 One portion of the definition in that document limits the types of 21 authentication properties about a message to a small, fixed set. 22 This document updates the specification, making it extensible to 23 allow new property types to be declared and used. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on February 27, 2015. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.2. Email Architecture . . . . . . . . . . . . . . . . . . . . 3 63 3. Updated 'ptype' Definition . . . . . . . . . . . . . . . . . . 3 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 68 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 69 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 5 71 1. Introduction 73 [RFC7001] defines the email Authentication-Results header field that 74 presents the results of an authentication effort in a machine- 75 readable format. The header field creates a place to collect the 76 output from authentication processes that are disjoint from later 77 processes that might use the output, such as analysis, filtering or 78 sorting mechanisms. 80 The specification in that document enumerated a small set of types of 81 properties that can be reported using this mechanism. There has 82 emerged a desire to report types of properties about a message 83 through this mechanism. Accordingly, this document updates the 84 specification to allow for additional property types ("ptypes") 85 beyond the original set, and creates a registry where new ones can be 86 listed and their defining documents referenced. 88 2. Definitions 90 2.1. Key Words 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 94 "OPTIONAL" in this document are to be interpreted as described in 95 [RFC2119]. 97 2.2. Email Architecture 99 Many of the definitions and acronyms regarding general email 100 architecture can be found in [RFC5598]. 102 3. Updated 'ptype' Definition 104 Advanced Backus Naur Form (ABNF) is defined in [RFC5234]. 106 The ABNF in Section 2.2 of [RFC7001] is updated as follows: 108 ptype = Keyword 109 ; indicates whether the property being evaluated was 110 ; a parameter to an [SMTP] command, was a value taken 111 ; from a message header field, was some property of 112 ; the message body, or was some other property evaluated by 113 ; the receiving MTA 115 The ABNF token "Keyword" is defined in Section 4.1.2 of [RFC5321]. 117 Legal values of "ptype" are as defined in the IANA "Email 118 Authentication Property Types" registry (see Section 4). The initial 119 values are as follows, matching those defined in [RFC7001]: 121 body: Indicates information that was extracted from the body of the 122 message. This might be an arbitrary string of bytes, a hash of a 123 string of bytes, a Uniform Resource Identifier, or some other 124 content of interest. 126 header: Indicates information that was extracted from the header of 127 the message. This might be the value of a header field or some 128 portion of a header field. 130 policy: As defined in Section 2.3 of [RFC7001]. 132 smtp: Indicates information that was extracted from an SMTP command 133 that was used to relay the message. 135 A consumer of this header field encountering a "ptype" it does not 136 understand MUST ignore the result it is reporting. 138 4. IANA Considerations 140 IANA is requested to create the Email Authentication Property Types 141 registry. Entries in this registry are subject to the Expert Review 142 rules as described in [RFC5226]. Each entry in the registry requires 143 the following values: 145 o The "ptype" token to be registered, which must fit within the ABNF 146 described in Section 3. 148 o A brief description of what sort of information this "ptype" is 149 meant to cover. 151 o A reference to the defining document, if any. 153 The initial entries in this table are enumerated in Section 3. This 154 document should be listed as their defining document values. 156 For new entries, the Designated Expert needs to assure that the 157 description provided for the new entry adequately describes the 158 intended use. An example would be helpful to include, although 159 entries in the Email Authentication Methods registry or the Email 160 Authentication Result Names registry might also serve as examples of 161 intended use. 163 5. Security Considerations 165 A consumer of this header field might be confused by a result bearing 166 a "ptype" it does not understand. The advice is to ignore such a 167 result since its semantics are unknown to such a consumer. It is 168 unknown how legacy code, which expects one of a fixed set of "ptype" 169 tokens, will handle new tokens as they begin to appear. This might 170 result in undesirable deliveries for consumers that have been 171 implemented to "fail open". 173 6. References 175 6.1. Normative References 177 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 178 Requirement Levels", BCP 14, RFC 2119, March 1997. 180 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 181 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 182 May 2008. 184 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 185 Specifications: ABNF", STD 68, RFC 5234, January 2008. 187 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 188 October 2008. 190 [RFC7001] Kucherawy, M., "Message Header Field for Indicating 191 Message Authentication Status", RFC 7001, September 2013. 193 6.2. Informative References 195 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 196 July 2009. 198 Appendix A. Acknowledgements 200 The author wishes to acknowledge the following for their review and 201 constructive criticism of this update: Dave Crocker, Tim Draegen, 202 Scott Kitterman, Franck Martin. 204 Author's Address 206 Murray S. Kucherawy 207 270 Upland Drive 208 San Francisco, CA 94127 209 US 211 EMail: superuser@gmail.com