idnits 2.17.1 draft-ietf-dmarc-sender-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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 234: '... domain owner MAY have a RFC5322.Se...' RFC 2119 keyword, line 235: '... that evaluation MAY be based on the d...' RFC 2119 keyword, line 270: '...ndividual message, Mail Receivers MUST...' RFC 2119 keyword, line 272: '... 2-3 MAY be done in parallel, wherea...' RFC 2119 keyword, line 298: '... of the algorithm and MUST include the...' (2 more instances...) -- The draft header indicates that this document updates RFC7489, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 25, 2020) is 1309 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 733 (Obsoleted by RFC 822) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 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 Updates: 7489 (if approved) September 25, 2020 5 Intended status: Experimental 6 Expires: March 29, 2021 8 DMARC Use of the RFC5322.Sender Header Field 9 draft-ietf-dmarc-sender-00 11 Abstract 13 Internet mail defines the RFC5322.From field to indicate the author 14 of the message's content and the RFC5322.Sender field to indicate who 15 initially handled the message. The RFC5322.Sender field is optional, 16 if it has the same information as the RFC5322.From field. That is, 17 when the RFC5322.Sender field is absent, the RFC5322.From field has 18 conflated semantics, with both a handling identifier and a content 19 creator identifier. This was not a problem, until development of 20 stringent protections on use of the RFC5322.From field. It has 21 prompted Mediators, such as mailing lists, to modify the RFC5322.From 22 field, to circumvent mail rejection caused by those protections. 24 This affects end-to-end behavior of email, between the author and the 25 final recipients, because mail from the same author is not treated 26 the same, depending on what path it followed. In effect, the 27 RFC5322.From field has become dominated by its role as a handling 28 identifier. 30 The current specification augments use of the RFC5322.From field, by 31 enhancing DMARC to also use the RFC5322.Sender field. This preserves 32 the utility of RFC5322.From field while also preserving the utility 33 of DMARC. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on March 29, 2021. 51 Copyright Notice 53 Copyright (c) 2020 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Domain Owner Actions . . . . . . . . . . . . . . . . . . . . 5 71 4. Mail Originator Actions . . . . . . . . . . . . . . . . . . . 6 72 5. Mail Mediator Actions . . . . . . . . . . . . . . . . . . . . 6 73 6. Mail Receiver Actions . . . . . . . . . . . . . . . . . . . . 6 74 6.1. Extract RFC5322.Sender and RFC5322.From Domains . . . . . 6 75 6.2. Determine Handling Policy . . . . . . . . . . . . . . . . 6 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 80 9.2. Informative References . . . . . . . . . . . . . . . . . 8 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 83 1. Introduction 85 Internet mail conducts asynchronous communication from an author to 86 one or more recipients, and is used for ongoing dialogue amongst 87 them. Email has a long history of serving a wide range of human uses 88 and styles, within that simple framework, and the mechanisms for 89 making email robust and safe serve that sole purpose. 91 Internet mail defines the RFC5322.From field to indicate the author 92 of the message's content and the RFC5322.Sender field to indicate who 93 initially handled the message. [Mail-Fmt] The RFC5322.Sender field 94 is optional, if it has the same information as the RFC5322.From 95 field. That is, when the RFC5322.Sender field is absent, the 96 RFC5322.From field has conflated semantics, as both a handling 97 identifier and a content creator identifier. These fields were 98 initially defined in [RFC733] and making the redundant RFC5322.Sender 99 field optional was a small, obvious optimization, in the days of 100 slower communications, expensive storage and less powerful computers. 102 The dual semantics of the RFC5322.From field was not a problem, until 103 development of stringent protections were put in place, on the use of 104 the RFC5322.From field. It has prompted Mediators, such as mailing 105 lists, to modify the RFC5322.From field, to circumvent mail rejection 106 caused by those protections. This affects end-to-end usability of 107 email, between the author and the final recipients. If the mailing 108 list does not modify the RFC5322.From field, there is the risk that 109 the message will be rejected or quarantined by the receiving system. 110 However, if the mailing list does modify the RFC5322.From field, mail 111 received from the same author will be treated differently by the 112 recipient's software, depending on what path the message followed. 114 By way of example, mail by: 116 Author Name 118 which is sent directly to a recipient, will show the user's display 119 name correctly and can correctly analyze and aggregate mail from that 120 user, based on their email address. However if the user sends 121 through a mailing list, and the mailing list conducts a common form 122 of RFC5322.From modification, needed to bypass enforcement of 123 stringent authentication policies, then the received message might 124 have a RFC5322.From field along the lines of 126 Author Name via Listname 128 The change inserts an operational address, for the Mediator, into the 129 RFC5322.From field, and distorts the field's display-name, as a means 130 of recording the modification. The result is that the recipient's 131 software will see the message as being from an entirely different 132 author and will handle it separately. Mediators might create a 133 Reply-To: field, with the original RFC5322.From field email address. 134 While this facilitates a recipient's responding to the original 135 author, it does nothing to aid other processing done by the 136 recipient's MUA based on what it believes is the author's address or 137 original display-name. 139 Because the current email protection behavior involves the 140 RFC5322.From field, and pertain to the human author, it is common to 141 think that the issue, in protecting the field's content, is behavior 142 of the human recipient. However there is no indication that the 143 enforced values in the RFC5322.From field alter end-user behavior. 144 In fact there is a long train of indication that it does not. 146 Rather, the meaningful protections actually operate at the level of 147 the receiving system's mail filtering engine, which decides on the 148 dispostion of received mail. 150 In effect, the RFC5322.From field has become dominated by its role as 151 a handling identifier. This specification defines enhancement for 152 use of the RFC5322.Sender field by [DMARC]. It is designed with the 153 view that enhancement of standards works best as incremental 154 additions. DMARC functionality is preserved, as is long-standing 155 recipient email usability.. 157 Teminology and architectural details in this document are 158 incorporated from [Mail-Arch]. 160 Discussion of this draft is directed to the dmarc@ietf.org mailing 161 list. 163 COMMENT: The original version of this specification essentially 164 sought to have the Sender: header field treated as an alternative 165 to the From: header field. Unfortunately this suffers a fatal 166 problem, in the face of established DMARC use. 168 If: 170 * the original From: field is covered by DMARC, and 172 * the message goes through a Mediator that breaks aligned 173 authentication, and 175 * the receiving DMARC engine only uses the original version of 176 DMARC, 178 then it will produce a DMARC fail. 180 It does not appear to be possible to handle this case safely, 181 except by modifying the From: header field so that it does not 182 trigger an alignment failure. Unless there comes a time at which 183 concern for this case is eliminated, Mediators will continue to 184 have to deal with this, such as by modifying the From: field. 186 To that end, this version of the specification has been modified, 187 to make Sender: an _additional_ DMARC alignment possibility, 188 rather than an alternative one. 190 2. Overview 192 This specification defines modifications to DMARC, to add use of the 193 RFC5322.Sender header field, as a possible second source of DMARC 194 validation and policy information. The changes are: 196 o A tag is added to the DMARC DNS record, to flag support for this 197 enhancement, indicating that valid mail originating from this 198 domain will have an aligned RFC5322.Sender field. 200 o The message originator creates a RFC5322.Sender field that is 201 identical to the RFC5322.From field, and therefore provides DMARC 202 alignment. This can permit DMARC to validate, even when it fails 203 to validate, based on the From: field. 205 o Receiving systems supporting the enhancement check for the 206 RFC5322.Sender domain's DNS DMARC record. 208 * If there is a record and it contains the enhancement flag, 209 DMARC evaluation is performed on that domain name. 211 * DMARC evaluation is also performed, as before, using the 212 RFC5322.From domain name. 214 The enhancement preserves existing DMARC operation, but permits DMARC 215 success in some scenarios that either used to fail or that produce 216 Mediator actions to bypass DMARC. The following table shows DMARC 217 interactions between original vs. enhanced originators and receivers: 219 +-------------------------------+--------------+----------------+ 220 | \Originate/ || - Receive --> | Original | Enhanced | 221 +-------------------------------+--------------+----------------+ 222 | RFC5322.From | RFC5322.From | RFC5322.From | 223 | RFC5322.From + RFC5322.Sender | RFC5322.From | RFC5322.Sender | 224 +-------------------------------+--------------+----------------+ 226 DMARC Original/Enhanced Interactions 228 3. Domain Owner Actions 230 For a domain that supports the use of RFC5322.Sender field evaluation 231 for DMARC, the owner specifies an additional DMARC Policy Record tag: 233 snd: When present, this tag signals that mail originated by the 234 domain owner MAY have a RFC5322.Sender field, as well as a 235 RFC5322.From field and that evaluation MAY be based on the domain 236 name in the RFC5322.Sender field. 238 4. Mail Originator Actions 240 Mail originators, for domains supporting enhanced DMARC, can create a 241 RFC5322.Sender field that is a duplicate of the RFC5322.From field. 242 They can, instead, create one that has a separate address, such as 243 when the originator is an independent agent, acting on behalf of the 244 content creator. 246 5. Mail Mediator Actions 248 Mediators, such as mailings lists, are independent agents, acting on 249 behalf of authors and recipients. They take delivery of messages and 250 then repost them, typically with modification. In response to the 251 use of DMARC, they often modify the RFC 5332.From field. They can 252 use this Sender-based mechanism to generate their own DMARC-aligned 253 authentication, based on the RFC5322.Sender field. 255 6. Mail Receiver Actions 257 6.1. Extract RFC5322.Sender and RFC5322.From Domains 259 The domain in the RFC5322.Sender field and the domain in the 260 RFC5322.From field are extracted as the domains to be evaluated by 261 DMARC. 263 6.2. Determine Handling Policy 265 The following procedure can result in DMARC policy information based 266 on the rfc5322.From, or the rfc5322.Sender, or based on both header 267 fields. The final choice for using this information to determine 268 message disposition resides with the receiving system. 270 To arrive at a policy for an individual message, Mail Receivers MUST 271 perform the following actions or their semantic equivalents. Steps 272 2-3 MAY be done in parallel, whereas steps 4 and 5 require input from 273 previous steps. 275 The steps are as follows: 277 1. 279 Sender: Extract the RFC5322.Sender domain from the message. 281 Query the DNS for a DMARC policy record. 283 Perform remaining, numbered steps, if one is found and it 284 contains an "snd" tag. 286 AND 288 From: Extract the RFC5322.From domain from the message. 290 Query the DNS for a DMARC policy record 292 Perform remaining, numbered steps, if one is found. 294 Terminate: Otherwise terminate DMARC evaluation. 296 2. Perform DKIM signature verification checks. A single email could 297 contain multiple DKIM signatures. The results of this step are 298 passed to the remainder of the algorithm and MUST include the 299 value of the "d=" tag from each checked DKIM signature. 301 3. Perform SPF validation checks. The results of this step are 302 passed to the remainder of the algorithm and MUST include the 303 domain name used to complete the SPF check. 305 4. Conduct Identifier Alignment checks. With authentication checks 306 and policy discovery performed, the Mail Receiver checks to see 307 if Authenticated Identifiers fall into alignment. If one or more 308 of the Authenticated Identifiers align with the RFC5322.From (or 309 with the RFC5322.Sender field, if permitted by the domain owner) 310 domain, the message is considered to pass the DMARC mechanism 311 check. All other conditions (authentication failures, identifier 312 mismatches) are considered to be DMARC mechanism check failures. 314 5. Apply policy. Emails that fail the DMARC mechanism check MAY be 315 disposed of in accordance with the discovered DMARC policy of the 316 Domain Owner. Broadly, however, receivers typically do not 317 automatically follow such directives. Rather, they apply complex 318 evaluation rules, for which DMARC is merely one (or more) sets of 319 input data. To that end, having a DMARC assessment for the 320 RFC5322.From field and another for the RFC5322.Sender field 321 merely add to their pool of data to consider. 323 7. Security Considerations 325 This enhancement entails the same security issues as the basic DMARC 326 service. 328 8. IANA Considerations 330 None. 332 9. References 334 9.1. Normative References 336 [DMARC] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 337 Message Authentication, Reporting, and Conformance 338 (DMARC)", RFC 7489, March 2015. 340 [Mail-Arch] 341 Crocker, D., "Internet Mail Architecture", RFC 5598, July 342 2009. 344 [Mail-Fmt] 345 Resnick, P., Ed., "Internet Message Format", RFC 5322, 346 October 2008. 348 9.2. Informative References 350 [RFC733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson, 351 "Standard for the Format of ARPA Network Text Messages", 352 RFC 733, November 1977. 354 Author's Address 356 Dave Crocker 357 Brandenburg InternetWorking 359 Email: dcrocker@bbiw.net