idnits 2.17.1 draft-crocker-dmarc-author-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 : ---------------------------------------------------------------------------- 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 (July 12, 2020) is 1383 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IANA' is defined on line 219, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-leiba-cotton-iana-5226bis-11 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMARC D. Crocker 3 Internet-Draft Brandenburg InternetWorking 4 Intended status: Informational July 12, 2020 5 Expires: January 13, 2021 7 Author Header Field 8 draft-crocker-dmarc-author-00 10 Abstract 12 Internet mail defines the From: field to indicate the author of the 13 message's content and the Sender: field to indicate who initially 14 handled the message. The Sender: field is optional, if it has the 15 same information as the From: field. That is, when the Sender: field 16 is absent, the From: field has conflated semantics, with both a 17 handling identifier and a content creator identifier. This was not a 18 problem, until development of stringent protections on use of the 19 From: field. It has prompted Mediators, such as mailing lists, to 20 modify the From: field, to circumvent mail rejection caused by those 21 protections. 23 This affects end-to-end behavior of email, between the author and the 24 final recipients, because mail from the same author is not treated 25 the same, depending on what path it followed. In effect, the From: 26 field has become dominated by its role as a handling identifier. The 27 current specification augments the current use of the From: field, by 28 specifying the Author: field, which identifies the original author of 29 the message and is not subject to modification by Mediators. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 13, 2021. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Author Header Field . . . . . . . . . . . . . . . . . . . . . 4 67 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 70 5.1. Registration of the Author header field . . . . . . . . . 5 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 73 6.2. Informative References . . . . . . . . . . . . . . . . . 5 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 76 1. Introduction 78 Internet mail conducts asynchronous communication from an author to 79 one or more recipients, and is used for ongoing dialogue amongst 80 them. Email has a long history of serving a wide range of human uses 81 and styles, within that simple framework, and the mechanisms for 82 making email robust and safe serve that sole purpose. 84 Internet mail defines the From: field to indicate the author of the 85 message's content and the Sender: field to indicate who initially 86 handled the message. [rfc5322] The Sender: field is optional, if it 87 has the same information as the From: field. That is, when the 88 Sender: field is absent, the From: field has conflated semantics, as 89 both a handling identifier and a content creator identifier. These 90 fields were initially defined in [rfc733] and making the redundant 91 Sender: field optional was a small, obvious optimization, in the days 92 of slower communications, expensive storage and less powerful 93 computers. 95 The dual semantics was not a problem, until development of stringent 96 protections on use of the From: field. It has prompted Mediators, 97 such as mailing lists, to modify the From: field, to circumvent mail 98 rejection caused by those protections. This affects end-to-end 99 usability of email, between the author and the final recipients, 100 because mail received from the same author is treated differently by 101 the recipient's software, depending on what path the message 102 followed. 104 Because the current email protection behavior involves the From: 105 field, it is common to think that the issue, in protecting the 106 field's content, is behavior of the human recipient. However there 107 is no indication that the enforced values in the From: field alter 108 end-user behavior. The meaningful protections actually operate at 109 the level of the receiving system's mail filtering engine, which 110 decides on the dispostion of received mail. 112 By way of example, mail from "Example User " which 113 is sent directly to a recipient, will show the user's display name 114 correctly and can correctly analyze and aggregate mail from that 115 user, based on their email address. However if the user sends 116 through a mailing list, and the mailing list conducts a common form 117 of From: modification, needed to bypass enforcement of stringent 118 authentication policies, then the received message might have a From: 119 field along the lines of "Example User via Example List 120 ". The change inserts an operational 121 address, for the Mediator, into the From: field, and distorts the 122 field's display-name, as a means of recording the modification. The 123 result is that the recipient's software will see the message as being 124 from an entirely different author and will handle it separately. 125 (Mediators might create a Reply-To: field, with the original From: 126 field email address, but this does nothing to aid other processing 127 done by the recipient's MUA based on what it believes is the author's 128 address or original display-name. 130 In effect, the From: field has become dominated by its role as a 131 handling identifier. The current specification augments the current 132 use of the From: field, by specifying the Author: field, which 133 identifies the original author of the message and is not subject to 134 modification by Mediators. 136 While it might be cleanest to move towards more reliable use of the 137 Sender: field and then to target it as the focus of authentication 138 concerns, enhancement of standards works best with incremental 139 additions, rather than efforts at replacement. To that end, this 140 specification provides a means of supplying author information that 141 is not subject to modification by processes seeking to enforce 142 stringent authentication. 144 Teminology and architectural details in this document are 145 incorporated from [rfc5598] 147 Discussion of this draft is directed to the dmarc@ietf.org mailing 148 list. 150 2. Author Header Field 152 A new message header field is defined: Author:. It has the same 153 syntax as From:. [rfc5322] As with the original and primary intent 154 for the From: header field, the Author: header field is to contain 155 the email address and can contain the displayable human name of the 156 author for the message content. 158 The ABNF for the field's syntax is: 160 author = "Author:" mailbox-list CRLF 162 This header field can be added as part of the original message create 163 process, or it can be added later, to preserve the original author 164 information from the From: field. 166 3. Discussion 168 The Author: header field, here, is intended for creation during 169 message generation or during mediation. It is intended for use by 170 recipient MUAs, as they typically use the From: field. In that 171 regard, it would be reasonable for an MUA that would normally 172 organize or display information based on the From: field to give the 173 Author: header field priority. 175 The X-Original-From: header field is referenced in [rfc5703] but is 176 not actually defined. Further, it is registered with IANA, but the 177 registry cites RFC5703 as the controlling source for the entry. 178 Lastly, the field is solely intended for use by Mediators, to 179 preserve information from a modified From: 181 Obviously any security-related processing of a message needs to 182 distinguish From: from Author: and treat their information 183 accordingly. 185 4. Security Considerations 187 Any header field containing identification information is a source of 188 security and privacy concerns, especially one pertaining to content 189 authorship. At a minimum, the handling of the Author: header field 190 needs to receive the same scrutiny and care given to the From: header 191 field. 193 Given the semantics of this field, it is easy to believe that use of 194 this field will create a new attack vector for tricking end-users. 195 However, for all of the real and serious demonstration of users' 196 being tricked by deceptive or false content in a message, there is no 197 evidence that problematic content in a field providing information 198 about message's author directly contributes to differential and 199 problematic behavior by the end user. 201 5. IANA Considerations 203 5.1. Registration of the Author header field 205 Header field name: Author 207 Applicable protocol: mail 209 Status: provisional 211 Author/Change controller: *** ??? *** 213 Specification document(s): *** This document *** 215 6. References 217 6.1. Normative References 219 [IANA] M. Cotton, B. Leiba, and T. Narten, "Guidelines for 220 Writing an IANA Considerations Section in RFCs", I-D 221 draft-leiba-cotton-iana-5226bis-11, 2017. 223 [rfc5322] , RFC 5322. 225 [rfc5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 226 2009. 228 6.2. Informative References 230 [rfc5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part 231 Tests, Iteration, Extraction, Replacement, and Enclosure", 232 RFC 5703, October 2009. 234 [rfc733] . 236 Author's Address 237 Dave Crocker 238 Brandenburg InternetWorking 240 Email: dcrocker@bbiw.net