idnits 2.17.1 draft-crocker-dmarc-author-01.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 27, 2020) is 1359 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) == Unused Reference: 'IANA' is defined on line 211, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-leiba-cotton-iana-5226bis-11 ** Downref: Normative reference to an Informational RFC: RFC 5598 (ref. 'Mail-Arch') -- Obsolete informational reference (is this intentional?): RFC 733 (Obsoleted by RFC 822) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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: Standards Track July 27, 2020 5 Expires: January 28, 2021 7 Author Header Field 8 draft-crocker-dmarc-author-01 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, as 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 28, 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. [Mail-Fmt] 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 By way of example, mail from "Example User " which 105 is sent directly to a recipient, will show the user's display name 106 correctly and can correctly analyze and aggregate mail from that 107 user, based on their email address. However if the user sends 108 through a mailing list, and the mailing list conducts a common form 109 of From: modification, needed to bypass enforcement of stringent 110 authentication policies, then the received message might have a From: 111 field along the lines of "Example User via Example List 112 ". The change inserts an operational 113 address, for the Mediator, into the From: field, and distorts the 114 field's display-name, as a means of recording the modification. The 115 result is that the recipient's software will see the message as being 116 from an entirely different author and will handle it separately. 117 (Mediators might create a Reply-To: field, with the original From: 118 field email address, but this does nothing to aid other processing 119 done by the recipient's MUA based on what it believes is the author's 120 address or original display-name.) 122 In effect, the From: field has become dominated by its role as a 123 handling identifier. The current specification augments the current 124 use of the From: field, by specifying the Author: field, which 125 identifies the original author of the message and is not subject to 126 modification by Mediators. 128 While it might be cleanest to move towards more reliable use of the 129 Sender: field and then to target it as the focus of authentication 130 concerns, enhancement of standards works best with incremental 131 additions, rather than efforts at replacement. To that end, this 132 specification provides a means of supplying author information that 133 is not subject to modification by processes seeking to enforce 134 stringent authentication. 136 Terminology and architectural details in this document are 137 incorporated from [Mail-Arch]. 139 Discussion of this draft is directed to the dmarc@ietf.org mailing 140 list. 142 2. Author Header Field 144 A new message header field is defined: Author:. It has the same 145 syntax as From:. [Mail-Fmt] As with the original and primary intent 146 for the From: header field, the Author: header field is to contain 147 the email address and can contain the displayable human name of the 148 author for the message content. 150 The ABNF for the field's syntax is: 152 author = "Author:" mailbox-list CRLF 154 This header field can be added as part of the original message create 155 process, or it can be added later, to preserve the original author 156 information from the From: field. 158 3. Discussion 160 The Author: header field, here, is intended for creation during 161 message generation or during mediation. It is intended for use by 162 recipient MUAs, as they typically use the From: field. In that 163 regard, it would be reasonable for an MUA that would normally 164 organize or display information based on the From: field to give the 165 Author: header field priority. 167 The X-Original-From: header field is referenced in [rfc5703] but is 168 not actually defined. Further, it is registered with IANA, but the 169 registry cites RFC5703 as the controlling source for the entry. 170 Lastly, the field is solely intended for use by Mediators, to 171 preserve information from a modified From: 173 Obviously any security-related processing of a message needs to 174 distinguish From: from Author: and treat their information 175 accordingly. 177 4. Security Considerations 179 Any header field containing identification information is a source of 180 security and privacy concerns, especially one pertaining to content 181 authorship. Generally, the handling of the Author: header field 182 needs to receive scrutiny and care comparable to that given to the 183 From: header field. 185 Given the semantics of this field, it is easy to believe that use of 186 this field will create a new attack vector for tricking end-users. 187 However, for all of the real and serious demonstration of users' 188 being tricked by deceptive or false content in a message, there is no 189 evidence that problematic content in a field providing information 190 about message's author directly contributes to differential and 191 problematic behavior by the end user. 193 5. IANA Considerations 195 5.1. Registration of the Author header field 197 Header field name: Author 199 Applicable protocol: mail 201 Status: provisional 203 Author/Change controller: *** ??? *** 205 Specification document(s): *** This document *** 207 6. References 209 6.1. Normative References 211 [IANA] M. Cotton, B. Leiba, and T. Narten, "Guidelines for 212 Writing an IANA Considerations Section in RFCs", I-D 213 draft-leiba-cotton-iana-5226bis-11, 2017. 215 [Mail-Arch] 216 Crocker, D., "Internet Mail Architecture", RFC 5598, July 217 2009. 219 [Mail-Fmt] 220 Resnick, P., Ed., "Internet Message Format", RFC 5322, 221 October 2008. 223 6.2. Informative References 225 [rfc5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part 226 Tests, Iteration, Extraction, Replacement, and Enclosure", 227 RFC 5703, October 2009. 229 [RFC733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson, 230 "Standard for the Format of ARPA Network Text Messages", 231 RFC 733, November 1977. 233 Author's Address 234 Dave Crocker 235 Brandenburg InternetWorking 237 Email: dcrocker@bbiw.net