idnits 2.17.1 draft-ietf-appsawg-authres-ptypes-registry-00.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 10, 2014) is 3539 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 94, 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 10, 2014 4 Updates: 7001 (if approved) 5 Intended status: Standards Track 6 Expires: February 11, 2015 8 A Property Types Registry for the Authentication-Results Header Field 9 draft-ietf-appsawg-authres-ptypes-registry-00 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, such as mail 16 filters or Mail User Agents (MUAs), can add or use this header field 17 to relay that information in a convenient and meaningful way to 18 users, or make 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 to allow new property types 23 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 11, 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. Updated 'ptype' Definition . . . . . . . . . . . . . . . . . . 3 61 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 63 5. Normative References . . . . . . . . . . . . . . . . . . . . . 5 64 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 [RFC7001] describes a header field called Authentication-Results for 69 electronic mail messages that presents the results of a message 70 authentication effort in a machine-readable format. The intent of 71 the header field is to create a place to collect such data when 72 message authentication mechanisms are in use so that a Mail User 73 Agent (MUA) and downstream filters can make filtering decisions 74 and/or provide a recommendation to the user as to the validity of the 75 message's origin and possibly the safety and integrity of its 76 content. 78 The specification in that document enumerated a small set of types of 79 properties that can be reported using this mechanism. There has 80 emerged a desire to report types of properties about a message 81 through this mechanism. Accordingly, this document updates the 82 specification to allow for additional property types ("ptypes") 83 beyond the original set, and creates a registry where new ones can be 84 listed and their defining documents referenced. 86 2. Updated 'ptype' Definition 88 Advanced Backus Naur Form (ABNF) is defined in [RFC5234]. 90 The ABNF in Section 2.2 of [RFC7001] is updated as follows: 92 ptype = Keyword 93 ; indicates whether the property being evaluated was 94 ; a parameter to an [SMTP] command, was a value taken 95 ; from a message header field, was some property of 96 ; the message body, or was some other property evaluated by 97 ; the receiving MTA 99 The ABNF token "Keyword" is defined in Section 4.1.2 of [RFC5321]. 101 Legal values of "ptype" are as defined in this document, or in the 102 IANA "Email Authentication Property Types" registry (see Section 3). 103 The initial values are as follows, matching those defined in 104 [RFC7001]: 106 body: Indicates information that was extracted from the body of the 107 message. This might be an arbitrary string of bytes, a hash of a 108 string of bytes, a Uniform Resource Identifier, or some other 109 content of interest. 111 header: Indicates information that was extracted from the header of 112 the message. This might be the value of a header field or some 113 portion of a header field. 115 policy: As defined in Section 2.3 of [RFC7001]. 117 smtp: Indicates information that was extracted from an SMTP command 118 that was used to relay the message. 120 A consumer of this header field encountering a "ptype" it does not 121 understand simply ignores the result it is reporting. 123 3. IANA Considerations 125 IANA is requested to create the Email Authentication Property Types 126 registry. Entries in this registry are subject to the Expert Review 127 rules as described in [RFC5226]. Each entry in the registry requires 128 the following values: 130 o The "ptype" token to be registered, which must fit within the ABNF 131 described in Section 2. 133 o A brief description of what sort of information this "ptype" is 134 meant to cover. 136 o A reference to the defining document, if any. 138 The initial entries in this table are enumerated in Section 2. This 139 document should be listed as their defining document values. 141 For new entries, the Designated Expert simply needs to assure that 142 the description provided for the new entry adequately describes the 143 intended use. An example would be helpful to include, although 144 entries in the Email Authentication Methods registry or the Email 145 Authentication Result Names registry might also serve as examples of 146 intended use. 148 4. Security Considerations 150 A consumer of this header field might be confused by a result bearing 151 a "ptype" it does not understand. The advice is simply to ignore 152 such a result since its semantics are unknown to such a consumer. It 153 is unknown how legacy code, which expects one of a fixed set of 154 "ptype" tokens, will handle new tokens as they begin to appear. This 155 could conceivably result in undesirable deliveries for consumers that 156 have been implemented to "fail open". 158 5. Normative References 160 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 161 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 162 May 2008. 164 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 165 Specifications: ABNF", STD 68, RFC 5234, January 2008. 167 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 168 October 2008. 170 [RFC7001] Kucherawy, M., "Message Header Field for Indicating 171 Message Authentication Status", RFC 7001, September 2013. 173 Appendix A. Acknowledgements 175 The author wishes to acknowledge the following for their review and 176 constructive criticism of this update: (names) 178 Author's Address 180 Murray S. Kucherawy 181 270 Upland Drive 182 San Francisco, CA 94127 183 US 185 EMail: superuser@gmail.com