idnits 2.17.1 draft-ietf-appsawg-authres-ptypes-registry-03.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 date (September 16, 2014) is 3509 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 84, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7001 (Obsoleted by RFC 7601) Summary: 2 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 September 16, 2014 4 Updates: 7001 (if approved) 5 Intended status: Standards Track 6 Expires: March 20, 2015 8 A Property Types Registry for the Authentication-Results Header Field 9 draft-ietf-appsawg-authres-ptypes-registry-03 11 Abstract 13 This document updates RFC7001 by creating a registry for property 14 types in the Authentication-Results header field, used in email 15 authentication work, rather than limiting participants to using the 16 original, small set of fixed values. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on March 20, 2015. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Updated 'ptype' Definition . . . . . . . . . . . . . . . . . . 3 54 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 56 5. Normative References . . . . . . . . . . . . . . . . . . . . . 5 57 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 5 59 1. Introduction 61 [RFC7001] defines the email Authentication-Results header field that 62 presents the results of an authentication effort in a machine- 63 readable format. The header field creates a place to collect the 64 output from authentication processes that are disjoint from later 65 processes that might use the output, such as analysis, filtering or 66 sorting mechanisms. 68 The specification in that document enumerated a small set of types of 69 properties that can be reported using this mechanism. There has 70 emerged a desire to report types of properties about a message 71 through this mechanism. Accordingly, this document updates the 72 specification to allow for additional property types ("ptypes") 73 beyond the original set, and creates a registry where new ones can be 74 listed and their defining documents referenced. 76 2. Updated 'ptype' Definition 78 Advanced Backus Naur Form (ABNF) is defined in [RFC5234]. 80 The ABNF in Section 2.2 of [RFC7001] is updated as follows: 82 ptype = Keyword 83 ; indicates whether the property being evaluated was 84 ; a parameter to an [SMTP] command, was a value taken 85 ; from a message header field, was some property of 86 ; the message body, or was some other property evaluated by 87 ; the receiving Message Transfer Agent (MTA) 89 The ABNF token "Keyword" is defined in Section 4.1.2 of [RFC5321]. 91 Legal values of "ptype" are as defined in the IANA "Email 92 Authentication Property Types" registry (see Section 3). The initial 93 values are as follows, matching those defined in [RFC7001]: 95 body: Indicates information that was extracted from the body of the 96 message. This might be an arbitrary string of bytes, a hash of a 97 string of bytes, a Uniform Resource Identifier, or some other 98 content of interest. 100 header: Indicates information that was extracted from the header of 101 the message. This might be the value of a header field or some 102 portion of a header field. 104 policy: A local policy mechanism was applied that augments or 105 overrides the result returned by the authentication mechanism. 106 See Section 2.3 of [RFC7001]. 108 smtp: Indicates information that was extracted from an SMTP command 109 that was used to relay the message. 111 When a consumer of this header field encounters a ptype that it does 112 not understand, it ignores the result reported with that ptype. 114 3. IANA Considerations 116 IANA is requested to create the Email Authentication Property Types 117 registry. Entries in this registry are subject to the Expert Review 118 rules as described in [RFC5226]. Each entry in the registry requires 119 the following values: 121 o The "ptype" token to be registered, which must fit within the ABNF 122 described in Section 2. 124 o A brief description of what sort of information this "ptype" is 125 meant to cover. 127 o An optional reference to the defining document. This is 128 recomended, but not required. 130 The initial entries in this table are enumerated in Section 2. 131 [RFC7001] should be listed as their defining document values. 133 For new entries, the Designated Expert needs to assure that the 134 description provided for the new entry adequately describes the 135 intended use. An example would be helpful to include in the entry's 136 defining document, if any, although entries in the Email 137 Authentication Methods registry or the Email Authentication Result 138 Names registry might also serve as examples of intended use. 140 4. Security Considerations 142 It is unknown how legacy code, which expects one of a fixed set of 143 "ptype" tokens, will handle new tokens as they begin to appear. 144 There are typically two options: prevent delivery of the message, or 145 ignore those portions of the field that use unknown "ptype" tokens 146 and allow processing of the message to continue. 148 The choice comes down to whether the consumer considers it a threat 149 when there are unknown "ptypes" present. The semantics of the report 150 are unknown; the report might be indicating the message is authentic, 151 fraudulent, or that a test failed to complete. The report itself is 152 not actionable because it cannot be understood, and only its presence 153 is certain. 155 Generally, the advice in this situation is to ignore unknown 156 "ptypes". It is anticipated that a new property type evaluated by 157 earlier handling agents would also result in the filtering of 158 messages by those agents until consumers can be updated to interpret 159 them. 161 5. Normative References 163 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 164 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 165 May 2008. 167 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 168 Specifications: ABNF", STD 68, RFC 5234, January 2008. 170 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 171 October 2008. 173 [RFC7001] Kucherawy, M., "Message Header Field for Indicating 174 Message Authentication Status", RFC 7001, September 2013. 176 Appendix A. Acknowledgements 178 The author wishes to acknowledge the following for their review and 179 constructive criticism of this update: Dave Crocker, Tim Draegen, 180 Scott Kitterman, Franck Martin. 182 Author's Address 184 Murray S. Kucherawy 185 270 Upland Drive 186 San Francisco, CA 94127 187 US 189 EMail: superuser@gmail.com