idnits 2.17.1 draft-crocker-email-author-04.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 (March 20, 2021) is 1104 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 171, but not defined -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 733 (Obsoleted by RFC 822) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Crocker 3 Internet-Draft Brandenburg InternetWorking 4 Intended status: Experimental March 20, 2021 5 Expires: September 21, 2021 7 Email Author Header Field 8 draft-crocker-email-author-04 10 Abstract 12 Internet mail defines the From: header field to indicate the author 13 of the message's content and the Sender: field to indicate who 14 initially handled the message, on the author's behalf. The Sender: 15 field is optional, if it has the same information as the From: field. 16 This was not a problem, until development of stringent protections on 17 use of the From: field. It has prompted Mediators, such as mailing 18 lists, to modify the From: field, to circumvent mail rejection caused 19 by those protections. In effect, the From: field has become 20 dominated by its role as a handling identifier. 22 The current specification augments the altered use of the From: 23 field, by specifying the Author: field, which ensures identification 24 of the original author of the message and is not subject to 25 modification by Mediators. This version is published as an 26 Experiment, to assess community interest, functional efficacy, and 27 technical adequacy. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 21, 2021. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Author Header Field . . . . . . . . . . . . . . . . . . . . . 4 66 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 7. Experimental Goals . . . . . . . . . . . . . . . . . . . . . 6 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 8.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 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 content header's From: field to indicate 85 the author of the message and the Sender: field to indicate who 86 initially handled the message, on the author's behalf. [Mail-Fmt] 87 The Sender: field is optional, if it has the same information as the 88 From: field. That is, when the Sender: field is absent, the From: 89 field has conflated semantics, as both a handling identifier and a 90 content creator identifier. These fields were initially defined in 91 [RFC733] and making the redundant Sender: field optional was a small, 92 obvious optimization, in the days of slower communications, expensive 93 storage and less powerful 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 98 receiver mail rejection, caused by those protections. This affects 99 end-to-end usability of email, between the author and the final 100 recipients, because mail received from the same author is treated 101 differently by the recipient's software, depending on what path the 102 message followed. 104 By way of example, mail originating with: 106 From: Example User 108 which is sent directly to a recipient, will show the author's display 109 name correctly and can correctly analyze, filter and aggregate mail 110 from the author, based on their email address. However if the author 111 sends through a mailing list, and the mailing list conducts a common 112 form of From: modification, needed to bypass enforcement of stringent 113 authentication policies, then the received message might instead have 114 a From: field showing: 116 From: Example User via Example List 118 The change inserts an operational address, for the Mediator, into the 119 From: field, and distorts the field's display-name, as a means of 120 recording the modification. 122 In terms of email identification semantics, this is a profound 123 change: 125 o The result is that the recipient's software will see the message 126 as being from an entirely different author and will handle it 127 separately, such as for sorting or filtering. In effect, the 128 recipient's software will see the same person's email as being 129 from a different address, for the person's actual address and each 130 of the mailing lists that person's mail transits. 132 o Mediators might create a Reply-To: field, with the original From: 133 field email address. This facilitates getting replies back to the 134 original author, but it does nothing to aid other processing or 135 presentation, done by the recipient's Mail User Agent (MUA), based 136 on what it believes is the author's address or original display- 137 name. This Reply-To action represents another knock-on, 138 collateral damage, by distorting the meaning of that header field, 139 as well as creating an issue if the field already exists. 141 In effect, the From: field has become dominated by its role as a 142 handling identifier. The current specification augments this altered 143 use of the From: field, by specifying the Author: field, which 144 identifies the original author of the message and is not subject to 145 modification by Mediators. 147 While it might be cleanest to move towards more reliable use of the 148 Sender: field and then to target it as the focus of authentication 149 concerns, enhancement of existing standards works best with 150 incremental additions, rather than with efforts at replacement. To 151 that end, this specification provides a means of supplying author 152 information that is not subject to modification by processes seeking 153 to enforce stringent authentication. 155 This version is published as an Experiment, to assess community 156 interest, functional efficacy, and technical adequacy. See 157 Section 7. 159 2. Terminology 161 Terminology and architectural details in this document are 162 incorporated from [Mail-Arch]. 164 Normative language, per [RFC8174]: 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 167 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 168 "MAY", and "OPTIONAL" in this document are to be interpreted as 169 described in BCP 14 [RFC2119] [RFC8174] when, and only when, they 170 appear in all capitals, as shown here. 172 RFC EDITOR: Please remove for publication: 174 Discussion of this draft is directed to the ietf-822@ietf.org 175 mailing list. 177 3. Author Header Field 179 A new message header field is defined: Author:. It has the same 180 syntax as the From: header field [Mail-Fmt]. As with the original 181 and primary intent for the From: field, the Author: field is to 182 contain the email address of the author of the message content. It 183 also can contain the displayable human name of the author. 185 The [ABNF] for the field's syntax is: 187 author = "Author:" mailbox-list CRLF 189 which echos the syntax for the From: header field. 191 This header field can be added as part of the original message 192 creation process, or it can be added later, by a Mediator, to 193 preserve the original author information from the From: field. 195 The goal of the Author: field is to reflect information about the 196 original author. However it is possible that the author's MUA or 197 Mail Submission Agent (MSA) will not create it, but that a Mediator 198 might know it will be modifying the From: field and wish to preserve 199 author information. Hence it needs to be allowed to create the 200 Author: field for this, if the field does not already exist. 202 Processing of the Author: field follows these rules: 204 o If an Author: field already exists, a new one MUST NOT be created 205 and the existing one MUST NOT be modified 207 o An author's MUA or MSA MAY create an Author: field, and its value 208 MUST be identical to the value in the From: field 210 o A Mediator MAY create an Author: field, if one does not already 211 exist, and this new field's value MUST be identical to the value 212 of the From: field, at the time the Mediator received the message 213 (and before the Mediator causes any changes to the From: field) 215 4. Discussion 217 The Author: header field, here, is intended for creation during 218 message generation or during mediation. It is intended for use by 219 recipient MUAs, as they typically use the From: field. In that 220 regard, it would be reasonable for an MUA that would normally 221 organize, filter, or display information based on the From: field to 222 give the Author: header field preference. 224 Original-From: is a similar header field, referenced in [RFC5703]. 225 It is registered with IANA, which cites RFC5703 as the controlling 226 source for the entry. However that document only has a minimal 227 definition for the field. Also, the field is solely intended for use 228 by Mediators, to preserve information from a modified From:. The 229 current specification can be used either during origination or during 230 mediation. 232 While the basic model of email header fields is highly extensible, 233 there well might be implementation and usability considerations for 234 carrying this field through to end-users, such as via [IMAP]. 236 Obviously any security-related processing of a message needs to 237 distinguish From: from Author: and treat their information 238 accordingly. 240 5. Security Considerations 242 Any header field containing identification information is a source of 243 security and privacy concerns, especially when the information 244 pertains to content authorship. Generally, the handling of the 245 Author: header field needs to receive scrutiny and care, comparable 246 to that given to the From: header field, but preferably not in a way 247 that defeats its utility. 249 Given the semantics of this field, it is easy to believe that use of 250 this field will create a new attack vector for tricking end-users. 251 However (and perhaps surprisingly) for all of the real and serious 252 demonstration of users' being tricked by deceptive or false content 253 in a message, there is no evidence that problematic content in a 254 header field, which is providing information about message's author, 255 directly contributes to differential and problematic behavior by the 256 end user. (The presents an obvious exercise for the reader, to find 257 credible, documented evidence.) 259 6. IANA Considerations 261 The IANA is request to register the Author header field, per 262 [RFC3864], into the Provisional Message Header Field Names Registry: 264 Header field name: Author 266 Applicable protocol: mail 268 Status: Provisional 270 Author/Change controller: Dave Crocker 272 Specification document(s): *** This document *** 274 7. Experimental Goals 276 Given that the semantics of this field echo the long-standing From: 277 header field, the basic mechanics of the field's creation and use are 278 well understood. Points of concern, therefore, are with possible 279 interactions with the existing From: field, with anti-abuse systems, 280 and with MUA behavior, along with basic market acceptance. So the 281 questions to answer, while the header field has experimental status 282 are: 284 o Is there demonstrated interest by MUA developers? 286 o If MUA developers add this capability, is it used by authors? 287 o Does the presence of the Author field, in combination with the 288 From field, create any operational problems, especially for 289 recipients? 291 o Does the presence of the Author field demonstrate additional 292 security issues? 294 o Does the presence of the Author field engender problematic 295 behavior by anti-abuse software, such as defeating its utility? 297 8. References 299 8.1. Normative References 301 [ABNF] Dave, D., Ed. and P. Paul, "Augmented BNF for Syntax 302 Specifications: ABNF", RFC 5234, January 2008. 304 [Mail-Arch] 305 Crocker, D., "Internet Mail Architecture", RFC 5598, July 306 2009. 308 [Mail-Fmt] 309 Resnick, P., Ed., "Internet Message Format", RFC 5322, 310 October 2008. 312 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 313 Procedures for Message Header Fields", BCP 90, RFC 3864, 314 DOI 10.17487/RFC3864, September 2004, 315 . 317 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 318 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 319 May 2017, . 321 8.2. Informative References 323 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 324 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 325 . 327 [RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part 328 Tests, Iteration, Extraction, Replacement, and Enclosure", 329 RFC 5703, October 2009. 331 [RFC733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson, 332 "Standard for the Format of ARPA Network Text Messages", 333 RFC 733, November 1977. 335 Appendix A. Acknowledgements 337 The idea for this field was prompted by discussions in the IETF's 338 DMARC working group, with participation including: Benny Lyne 339 Amorsen, Kurt Anderson, Laura Atkins, Adrian Farrel, Murray S. 340 Kucherawy, Mike Hammer, John Levine, Alexey Melnikov, Jesse Thompson, 341 Alessandro Vesely. 343 Author's Address 345 Dave Crocker 346 Brandenburg InternetWorking 348 Email: dcrocker@bbiw.net