idnits 2.17.1 draft-ietf-dmarc-interoperability-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 (June 9, 2015) is 3244 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-kucherawy-dkim-delegate-01 == Outdated reference: A later version (-01) exists of draft-kucherawy-dkim-list-canon-00 == Outdated reference: A later version (-02) exists of draft-kucherawy-dkim-transform-00 == Outdated reference: A later version (-04) exists of draft-levine-dkim-conditional-00 == Outdated reference: A later version (-08) exists of draft-otis-tpa-label-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMARC Working Group F. Martin, Ed. 3 Internet-Draft LinkedIn 4 Intended status: Informational E. Lear, Ed. 5 Expires: December 11, 2015 Cisco Systems GmbH 6 T. Draegen, Ed. 7 Eudaemonic Development LLC 8 E. Zwicky, Ed. 9 Yahoo 10 June 9, 2015 12 Interoperability Issues Between DMARC and Indirect Email Flows 13 draft-ietf-dmarc-interoperability-04 15 Abstract 17 DMARC introduces a mechanism for expressing domain-level policies and 18 preferences for email message validation, disposition, and reporting. 19 The DMARC mechanism can encounter interoperability issues when 20 messages do not flow directly from the author's administrative domain 21 to the final recipients. Collectively these email flows are referred 22 to as indirect email flows. This document describes interoperability 23 issues between DMARC and indirect email flows. Possible methods for 24 addressing interoperability issues are presented. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 11, 2015. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Document Conventions . . . . . . . . . . . . . . . . . . 3 62 2. Causes of Interoperability Issues . . . . . . . . . . . . . . 3 63 2.1. Originator vs Receiver Perspective . . . . . . . . . . . 4 64 2.2. Identifier Alignment . . . . . . . . . . . . . . . . . . 4 65 2.3. Message Forwarding . . . . . . . . . . . . . . . . . . . 5 66 2.4. Message Modification . . . . . . . . . . . . . . . . . . 5 67 3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 6 68 3.1. Message Handling System . . . . . . . . . . . . . . . . . 6 69 3.1.1. Message Submission Agents . . . . . . . . . . . . . . 6 70 3.1.2. Message Transfer Agents . . . . . . . . . . . . . . . 7 71 3.1.2.1. Message Encoding . . . . . . . . . . . . . . . . 7 72 3.1.2.2. Header Standardization . . . . . . . . . . . . . 8 73 3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 8 74 3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 8 75 3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 8 76 3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 9 77 3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 10 78 3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 11 79 3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 11 80 3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 12 81 4. Possible Mitigations of Interoperability Issues . . . . . . . 12 82 4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 13 83 4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 13 84 4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 13 85 4.1.1.2. Message Modification . . . . . . . . . . . . . . 13 86 4.1.2. Mitigations for Receivers . . . . . . . . . . . . . . 14 87 4.1.2.1. Identifier Alignment . . . . . . . . . . . . . . 14 88 4.1.2.2. Policy Override . . . . . . . . . . . . . . . . . 14 89 4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 14 90 4.1.3.1. Changes to the RFC5322.From . . . . . . . . . . . 14 91 4.1.3.2. Avoiding Message Modification . . . . . . . . . . 14 92 4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 15 93 4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 16 94 4.2.1. Getting More Radical: Requiring New Communication 95 Paths Between MUAs . . . . . . . . . . . . . . . . . 17 97 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 98 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 99 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 100 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 101 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 102 8.2. Informative References . . . . . . . . . . . . . . . . . 19 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 105 1. Introduction 107 DMARC [RFC7489] introduces a mechanism for expressing domain-level 108 policies and preferences for message validation, disposition, and 109 reporting. The DMARC mechanism can encounter several different types 110 of interoperability issues due to third-party message sourcing, 111 message transformation or rerouting. 113 DMARC is, as this writing, an Informational RFC, however it has a 114 significant deployment within the email community. 116 Cases in which email does not flow directly from the author's 117 administrative domain to the recipients are collectively referred to 118 in this document as indirect email flows. Due to existing and 119 increasing adoption of DMARC, the impact of DMARC-based email 120 rejection policies on both direct and indirect email flows can be 121 significant. 123 Several known causes of interoperability issues are presented, 124 followed by a description of components within the Internet Mail 125 Architecture [RFC5598] where interoperability issues can arise. 127 Lastly, known and possible methods for addressing interoperability 128 issues are presented. There are often multiple ways to address any 129 given interoperability issue. While this document strives to be 130 comprehensive in its review, it should not be treated as complete. 132 1.1. Document Conventions 134 Notation regarding structured fields is taken from [RFC5598]. 136 Organizational Domain and Authenticated Identifiers are specified in 137 DMARC [RFC7489]. 139 2. Causes of Interoperability Issues 141 Interoperability issues between DMARC and indirect email flows arise 142 when conformance to the DMARC specification leads an implementation 143 to apply DMARC based policy to messages that are both compliant with 144 the architecture as specified in [RFC5598] and viewed as legitimate 145 by the intended recipient. To be clear, this document does not 146 address emails considered legitimate by the intended recipient but 147 which are not conformant to other email specifications. The rest of 148 this section describes several conceptual causes of interoperability 149 issues. 151 2.1. Originator vs Receiver Perspective 153 Some Receivers are concerned that wanted email messages are received, 154 regardless if such email messages are not strictly in conformance to 155 any standard or protocol. 157 Some Originators, particularly for high value transactional messages, 158 want the message discarded if it passes through an intermediary and 159 is modified in any way resulting in a failure to validate. Examples 160 of such messages include those related to financial organizations and 161 medical establishments. 163 2.2. Identifier Alignment 165 DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform message 166 source validation. The DMARC [RFC7489] mechanism refers to source 167 domains that are validated by DKIM or SPF as Authenticated 168 Identifiers. DMARC requires an Authenticated Identifier to be 169 relevant to the domain found in the message's RFC5322.From header 170 field [RFC5322]. This relevancy is referred to as Identifier 171 Alignment. 173 Identifier Alignment can be strict, where the domains exactly match 174 each others, or relaxed where the domains are part of the same 175 Organizational Domain. There are, in general, the same 176 interoperability issues between strict and relaxed alignment, however 177 in strict mode the possible solutions are more constrained when 178 possible. This Document mainly implies relaxed Identifier Alignment. 180 DKIM provides a cryptographic means for a domain to be associated 181 with a particular message. DKIM does not make any constraints on 182 what domains may or must present this association. However, for a 183 DKIM identifier to align in DMARC, the signing domain of a valid 184 signature must be part of the same Organizational Domain as the 185 domain in the RFC5322.From header field [RFC5322]. 187 In addition, DKIM allows for the possibility of multiple valid 188 signatures. The DMARC mechanism will process Authenticated 189 Identifiers that are based on DKIM signatures until an aligned 190 Authenticated Identifier is found (if any). However, operational 191 experience has shown that some implementations have difficulty 192 processing multiple signatures. The impact on DMARC processing is 193 clear: implementations that cannot process multiple DKIM signatures 194 may erroneously apply DMARC based policy to otherwise legitimate 195 messages. 197 SPF can provide two Authenticated Identifiers based on two different 198 SPF identities: RFC7208.HELO [RFC7208] and RFC7208.MAILFROM 199 [RFC7208]. DMARC uses only the RFC7208.MAILFROM identifier for 200 alignment. The SPF validated domain in RFC7208.MAILFROM must be part 201 of the same Organizational Domain as the domain in the RFC5322.From 202 header field to be aligned. It is important to note that even when 203 an SPF record exists for the domain in RFC5322.From, SPF will not 204 authenticate it unless it is also the domain in RFC7208.MAILFROM, 205 furthermore, RFC7208.MAILFROM definition is different from 206 RFC5321.MailFrom [RFC5321] definition. 208 2.3. Message Forwarding 210 Message forwarding is a generic concept encapsulating a variety of 211 behaviors. Section 3 describes forwarding behavior as it relates to 212 the components of the Internet Mail Architecture. 214 All of these behaviors involve email being retransmitted by a new 215 SMTP server. As discussed above, for SPF to cause a DMARC pass, the 216 domain of the RFC7208.MAILFROM, must be aligned with that of the 217 RFC5322.From header field: 219 o If the RFC5321.MailFrom is not empty and if the forwarder keeps 220 the RFC5321.MailFrom, the SPF validation will fail altogether 221 unless the forwarder is an authorized part of the originator's 222 email sending infrastructure. On another hand, if the forwarder 223 uses its own domain in the RFC5321.MailFrom, SPF passes but the 224 alignment with the RFC5322.From header field fails. 226 o If the RFC5321.MailFrom is empty, the RFC5321.Helo of the 227 forwarder will likely be in different organizational domain of the 228 RFC5322.From. SPF may pass but the alignment with the 229 RFC5322.From header field fails. 231 In either case, SPF cannot produce a DMARC pass, and DKIM will be 232 required to get DMARC to pass. 234 2.4. Message Modification 236 Modification of email content invalidates most DKIM signatures, and 237 many message forwarding systems modify email content. Mailing list 238 processors are the most common example of such systems, but other 239 forwarding systems also make modifications. Although DKIM provides a 240 length flag so that content can be appended (See Section 8.2 of 242 [RFC6376] for additional security considerations), in practice, 243 particularly with MIME-encoded [RFC2045] messages, a mailing list 244 processor will do more than append (See Section 5.3 of [RFC5598] for 245 details). Furthermore, the use of the length flag is seldom found in 246 emails in part because of its security challenges. 248 DKIM has two canonicalizations to use for headers and body 249 separately: simple and relaxed. The latter allows some modest in 250 transit modifications that do not change the interpretation of the 251 content of the email. The relaxed canonicalization is more computing 252 intensive and may not have been preferred in the early deployment of 253 DKIM as this may have been more significant than today. 255 3. Internet Mail Architecture, DMARC, and Indirect Email Flows 257 This section describes components within the Internet Mail 258 Architecture [RFC5598] where interoperability issues between DMARC 259 and indirect email flows can be found. 261 3.1. Message Handling System 263 Section 4 of [RFC5598] describes six basic components that make up 264 the Message Handling System (MHS): 266 o Message 268 o Message User Agent (MUA) 270 o Message Submission Agent (MSA) 272 o Message Transfer Agent (MTA) 274 o Message Delivery Agent (MDA) 276 o Message Store (MS) 278 Of these components MSA, MTA, and MDA are discussed in relation to 279 interoperability with DMARC. 281 A Mediator is a special class of MUA that is given special 282 consideration in this section due to the unique issues Mediators face 283 when attempting to interoperate with DMARC. 285 3.1.1. Message Submission Agents 287 An MSA accepts messages submitted by a Message User Agent (MUA) and 288 enforces the policies of the hosting ADministrative Management Domain 289 (ADMD) and the requirements of Internet standards. 291 MSAs are split into two sub-components: 293 o Author-focused MSA functions (aMSA) 295 o MHS-focused MSA functions (hMSA) 297 MSA interoperability issues with DMARC begin when an aMSA accepts a 298 message where the RFC5322.From header field contains a domain that is 299 outside of the ADMD of the MSA. The ADMD will almost certainly not 300 be capable of sending email that yields Authenticated Identifiers 301 aligned with the domain found in the RFC5322.From header field. 302 Examples of this issue include "forward-to-friend" functionality 303 commonly found on news/article websites or "send-as" functionality 304 present on some MUAs. 306 When an hMSA takes responsibility for transit of a message containing 307 a domain in the RFC5322.From header field that is outside of the 308 hMSA's ADMD, the hMSA faces DMARC interoperability issues if the 309 domain publishes a DMARC policy of "quarantine" or "reject". These 310 issues are marked by an inherent difficulty in establishing alignment 311 with the domain present in a message's RFC5322.From header field. 312 Examples of this issue include: 314 o Pseudo-open relays - a residential ISP that allows its customers 315 to relay any domains through its infrastructure. 317 o Embedded devices - cable/dsl modems, firewalls, wireless access 318 points that send email using hardcoded domains. 320 o Email service providers - ESPs that service customers that are 321 using domains that publish a DMARC "reject" policy. 323 o Calendaring software - an invited member of an event modifies the 324 event causing calendaring software to emit an update that appears 325 to come from the creator of the event. 327 3.1.2. Message Transfer Agents 329 MTAs relay a message until the message reaches a destination MDA. 331 3.1.2.1. Message Encoding 333 An MTA may modify the message encoding, for instance by converting 334 8-bit MIME sections to quoted-printable 7-bit sections. This 335 modification is outside the scope of DKIM canonicalization and will 336 invalidate DKIM signatures that include message content. 338 3.1.2.2. Header Standardization 340 An MTA may standardize headers, usually in order to make non-RFC 341 compliant headers properly compliant. For instance, some common MTAs 342 will correct comprehensible but non-compliant date formats to 343 compliant ones. This correction is outside the scope of DKIM 344 canonicalization and will invalidate DKIM signatures. This 345 correction is also outside the scope of this document in providing 346 solutions for non RFC compliant emails. 348 3.1.3. Message Delivery Agents 350 The MDA transfers a message from the MHS to a mailbox. Like the MSA, 351 the MDA consists of two sub-components: 353 o MHS-focused MDA functions (hMDA) 355 o Recipient-focused MDA functions (rMDA) 357 Both the hMDA and the rMDA can redirect a message to an alternative 358 address. DMARC interoperability issues related to redirecting of 359 messages are described in Section 3.2. 361 SIEVE [RFC5228] functionality often lives in the rMDA sub-component 362 and can cause DMARC interoperability issues. The SIEVE 'addheader' 363 and 'deleteheader' filtering actions can modify messages and 364 invalidate DKIM signatures, removing DKIM-supplied Authenticated 365 Identifiers as inputs to the DMARC mechanism. There are also SIEVE 366 extensions that modify the body. SIEVE may only become an issue when 367 the email is reintroduced in the transport infrastructure. 369 3.2. Mediators 371 See [RFC5598] for a complete definition of Mediators. 373 Mediators forward messages through a re-posting process. Mediators 374 share some functionality with basic MTA relaying, but have greater 375 flexibility in both addressing and content modifications. 377 DMARC interoperability issues are prevalent within the context of 378 Mediators, which are often used precisely for their ability to modify 379 messages. 381 3.2.1. Alias 383 An Alias is a simple re-addressing facility that provides one or more 384 new Internet Mail addresses, rather than a single, internal one. A 385 message continues through the transfer service for delivery to one or 386 more alternative addresses. 388 Aliases can be implemented by mailbox-level forwarding (e.g. through 389 "dot-forwarding") or SIEVE-level forwarding (through the SIEVE 390 'redirect' action) or other methods. When an Alias preserves message 391 content and does not make significant header changes, DKIM signatures 392 may remain valid. However, Aliases often extend the delivery path 393 beyond SPF's ability to grant authorization. 395 Examples of Aliasing include: 397 o Forwarding email between freemail providers to try different 398 interfaces while maintaining an original email address. 400 o Consolidating many email addresses into a single acccount to 401 centralize processing. 403 o Services that provides "activity based", "role based" , "vanity" 404 or "temporary" email addresses such as universities and 405 professional associations. For instance professional or alumni 406 institutions may offer to their members an alias for the duration 407 of their membership but may not want to deal with the long term 408 storage of emails. 410 In most cases, the aMSA providing Alias services has no 411 administrative relationship to the ADMD of the final recipient, so 412 solutions to Alias-related DMARC failure should not assume such a 413 relationship. 415 3.2.2. ReSenders 417 ReSenders "splice" a message's addressing information to connect the 418 Author of the original message with the Recipient(s) of the new 419 message. The new Recipient sees the message as being from the 420 original Author, even if the Mediator adds commentary. 422 ReSenders introduce DMARC interoperability issues as content 423 modification invalidates DKIM signatures. SPF's ability to grant 424 authorization via alignment is removed as the new Recipient receives 425 the message from the Mediator. 427 Without an ability to produce Authenticated Identifiers relevant to 428 the Author's RFC5322.From header field domain using either DKIM or 429 SPF, the new Recipient has almost no chance of successfully applying 430 the DMARC mechanism. 432 Examples of ReSenders include MUA-level forwarding by resending a 433 message to a new recipient or by forwarding a message "inline" to a 434 new recipient (this does not include forwarding a message "as an 435 attachment"). An additional example comes in the form of calendaring 436 software that allows a meeting attendee (not the meeting organizer) 437 to modify the content of an invite causing the invitations to appear 438 to be reissued from the meeting organizer. 440 3.2.3. Mailing Lists 442 A Mailing List receives messages as an explicit addressee and then 443 re-posts them to a list of subscribed members. The Mailing List 444 performs a task that can be viewed as an elaboration of the ReSender. 446 Mailing Lists share the same DMARC interoperability issues as 447 ReSenders (Section 3.2.2), and very commonly modify headers or 448 message content in ways that will cause DKIM to fail, including: 450 o prepending the RFC5322.Subject header field with a tag, to allow 451 the receiver to identify visually the mailing list. 453 o adding a footer to the email body to contain administrative 454 instructions. 456 o removing some MIME-parts from the email or converting the message 457 to text only. 459 o PGP-encrypting or S/MIME encrypting the body to the receiver's 460 key. 462 o enforcing community standards by rewriting banned words. 464 o allowing moderators to add arbitrary commentary to messages. 466 Any such modifications would invalidate a DKIM signature. 468 Mailing Lists may also have the following DMARC interoperability 469 issues: 471 o Subscribed members may not receive email from members that post 472 using domains that publish a DMARC "p=reject" policy. 474 o Mailing Lists may interpret DMARC-related email rejection as an 475 inability to deliver email to the recipients that are checking and 476 enforcing DMARC policy. This processing may cause subscribed 477 members to be suspended or removed from the Mailing List. 479 These changes are common for many mailing lists and receivers are 480 used to them. Furthermore MUA expects certain mailing list behavior 481 in presenting emails to the end users 483 3.2.4. Gateways 485 A Gateway performs the basic routing and transfer work of message 486 relaying, but it also is permitted to modify content, structure, 487 address, or attributes as needed to send the message into a messaging 488 environment that operates under different standards or potentially 489 incompatible policies. 491 Gateways share the same DMARC interoperability issues as ReSenders 492 (Section 3.2.2). 494 Gateways may share also the same DMARC interoperability issues as 495 MTAs (Section 3.1.2). 497 Gateway-level forwarding can introduce DMARC interoperability issues 498 if the Gateway is configured to rewrite the message to map between 499 recipient domains. For example, an acquisition may lead the 500 acquiring company to decide to decommission the acquired company's 501 domains by rewriting messages to use the domain of the acquiring 502 company. Since the RFC5322.To header field is usually DKIM-signed, 503 this kind of rewriting will also cause DKIM signatures to fail. 505 3.2.5. Boundary Filters 507 To enforce security boundaries, organizations can subject messages to 508 analysis for conformance with their safety policies. A filter might 509 alter the content to render it safe, such as by removing content 510 deemed unacceptable. 512 Boundary Filters share the same DMARC interoperability issues as 513 ReSenders. 515 Issues may arise if SPF and DKIM is evaluated after the filter 516 modifications. 518 Examples of Boundary Filters include: 520 o Anti-spam: To keep its reputation, an MTA that transfers a message 521 may remove harmful content from messages that are likely to be 522 unwanted by the next MTA and/or add text in the body to indicate 523 the message has been scanned. Any such modifications would 524 invalidate a DKIM signature. 526 o Any service that reformulates the RFC5322.body for any other 527 reason, for instance adding an organizational disclaimer. 529 o Secondary MX services. In this case, however, it is inappropriate 530 for a primary MX server to perform an SPF check against its own 531 secondaries. Rather, the secondary MX should perform this 532 function. 534 3.3. Combinations 536 The causes of indirect email flows can be combined. For example, a 537 university student may subscribe to a mailing list (using his 538 university email address) while this university email address is 539 configured to forward all emails to a freemail provider where a more 540 permanent email address for this student exists. 542 Within an organization the message may pass through various MTAs 543 (Section 3.1.2), each of which performs a different function 544 (authentication, filtering, distribution, etc.) 546 4. Possible Mitigations of Interoperability Issues 548 Solutions to interoperability issues between DMARC and indirect email 549 flows vary widely in their scope and implications. They range from 550 improvements to underlying processors, such as proper handling of 551 multiple DKIM signatures, to more radical approaches to the messaging 552 architecture. This section describes possible ways to address 553 interoperability issues. 555 Mail systems are diverse and widely deployed and are expected to 556 continue to work with old systems. For instance, Qmail is still used 557 and the base code has not been updated since 1998. Ezmlm, a once 558 popular mailing list manager, is still deployed and has not been 559 updated since 1997, although a new version, Ezmlm-idx exists. In 560 this constrained environment, some solutions may be time-consuming 561 and/or disruptive to implement. 563 DMARC provides for receivers to make decisions about identity 564 alignment acceptability based on information outside DMARC and 565 communicate those decisions as "overrides" to the sender. This 566 facility can be used to ease some interoperability issues, although 567 care is needed to ensure that this does not create loopholes that 568 abusers can use arbitrarily. 570 4.1. Mitigations in Current Use 572 At many places where DMARC is already deployed, mitigations are in 573 use. These mitigations vary in their effectiveness and side effects, 574 but have the advantage that they are currently available. 576 4.1.1. Mitigations for Senders 578 4.1.1.1. Identifier Alignment 580 o MTAs handling multiple domains may choose to change 581 RFC5321.MailFrom to align with RFC5322.From to improve SPF 582 usability for DMARC. 584 o MTAs handling multiple domains may also choose to align 585 RFC5321.HELO/EHLO to RFC5322.From, particularly when sending 586 bounce messages. Adjusting dynamically the RFC5321.HELO based on 587 the RFC5322.From may not be possible for some MTA software. 589 o MTAs may choose to DKIM sign bounces with an aligned domain to 590 allow DKIM-based DMARC pass. 592 o MTAs handling multiple domains may require DMARC-using senders to 593 provide DKIM keys and use DKIM to avoid SPF alignment issues. 594 Handling DKIM keys with a third party has its security challenges. 596 o Senders who are sending on behalf of users in other Administrative 597 Domains may choose to use an RFC5322.From under the sender's 598 control. The new From can be either a forwarding address in a 599 domain controlled by the Sender, or a placeholder address, with 600 the original user's address in a RFC5322.Reply-to header field. 601 However this may affect what the recipient expects in its MUA. 603 o Senders can use different domains with different DMARC policies 604 for email sent directly and email known to use indirect mail flow. 605 However for known brands, all active domains are likely to be 606 targeted equally by abusers. 608 4.1.1.2. Message Modification 610 o Senders can maximize survivability of DKIM signatures by limiting 611 the header fields they sign, using relaxed canonicalization and by 612 using length to allow appended signatures. 614 o Senders can also maximize survivability by starting with RFC- 615 compliant headers and common body formats. 617 o In order to minimize the chances of transport conversions, Senders 618 can convert the message to a suitable MIME content-transfer 619 encoding such as quoted-printable or base64 before signing 620 ([RFC6376] Section 5.3). 622 4.1.2. Mitigations for Receivers 624 4.1.2.1. Identifier Alignment 626 o Receivers should update DKIM handling libraries to ensure that 627 they process all valid DKIM signatures and check them for 628 alignment. 630 4.1.2.2. Policy Override 632 o Receivers can amalgamate data from their user base to identify 633 forwarders and use such list for a DMARC local policy override. 634 This process may be easier for large receivers, where there is 635 data and resources to create such lists, than for small receivers. 637 4.1.3. Mitigations for ReSenders 639 4.1.3.1. Changes to the RFC5322.From 641 Many ReSender issues can be avoided by using an RFC5322.From header 642 field under the ReSender's control, instead of the initial 643 RFC5322.From. This will correct identifier alignment issues and 644 allow arbitrary message modification, for instance. When ReSenders 645 change the RFC5322.From, it is desirable to preserve the information 646 about the original initiator of the message. 648 A first option is to use the Original-From [RFC5703] (or X-Original- 649 From) header field for this purpose in various contexts (X- header 650 fields name are discouraged by [RFC6648]). However, handling of 651 Original-From (or X-Original-From) is not defined anywhere. It is 652 not currently used consistently or displayed to the user, but in any 653 situation where it is used, it is a new unauthenticated identifier 654 available for exploitation. 656 Another option for ReSenders is to rewrite the RFC5322.From header 657 field address to a valid forwarding address to the original sender, 658 in a domain that the ReSender controls. 660 4.1.3.2. Avoiding Message Modification 662 o Forwarders can choose to add email header fields instead of 663 modifying existing headers or bodies, for instance to indicate a 664 message may be spam. 666 o Forwarders can minimize the circumstances in which they choose to 667 fix messages, preferring to preserve non-compliant headers to 668 creating DKIM failures. 670 o Forwarders can choose to reject messages with suspect or harmful 671 content instead of modifying them. 673 4.1.3.3. Mailing Lists 675 [RFC6377] provides some guidance on using DKIM with Mailing lists. 676 Here are some remediation techniques on using DMARC with Mailing 677 lists: 679 o One mitigation policy, which is now present on several Mailing 680 List software, is to configure the Mailing List Manager (MLM) to 681 alter the RFC5322.From header field to use the domain of the MLM. 682 Since most list subscribers prefer to know the identity of the 683 author of the original message, typically this information may be 684 provided in the display name part of the RFC5322.From header 685 field. This display name needs to be carefully crafted as to not 686 collide with the original display name of the author, nor contain 687 something that looks like an email address or domain name. These 688 modifications may to some extent defeat the purpose of DMARC 689 itself. It may make it difficult to ensure that users of all 690 email clients can easily reply to the author, the list, or all 691 using the email client features provided for that purpose. Use of 692 RFC5322.Reply-To header field can alleviate this problem depending 693 on whether the mailing list is configured to reply-to-list, reply- 694 to-author or reply-to-fixed-address, however it is important to 695 note that this header field can take multiple email addresses. 696 When altering the RFC5322.From there are two possibilities, to 697 change it to put the mailing list email address, or to change it 698 to add a suffix like ".invalid" to the domain of the email address 699 present there. The later modification may create issues because 700 it is an invalid domain name, and some MTAs may take particular 701 attention to the validity of email addresses in RFC5322.From and 702 the reputation of the domains present there. 704 o Another mitigation policy is to configure the MLM to "wrap" the 705 message in a MIME message/rfc822 part and to send as the Mailing 706 List email address. Many email clients (as of August 2014) have 707 difficulty reading such messages. 709 o Another mitigation policy, is to configure the MLM to not modify 710 the message so that the DKIM signature remains valid. Some 711 Mailing Lists are mainly setup this way and require little 712 modifications to ensure the DKIM signature is preserved. However 713 moving to this policy a list that do extensive modification to the 714 email, may be too much of a change for the members of such list. 716 o Another mitigation policy, is to reject posts from domains with a 717 DMARC policy other than p=none. However members of such Mailing 718 Lists may complain of unfair exclusion. 720 o To alleviate unsubscribes to the Mailing List due to the messages 721 bouncing because of DMARC, the MLM needs to not act on bounces due 722 to Message Authentication issues. [RFC3463] specifies Enhanced 723 Mail System Status Codes which help differentiate between various 724 bounces. Correctly interpreting Extended SMTP error messages is 725 useful in this case in particular codes defined in [RFC7372] and 726 in DMARC. 728 All these techniques may provide some specific challenges in MUAs and 729 different operational usages for end users (like rewriting filters to 730 sort emails in folders). There will be some time before all 731 implications are understood and alleviated. 733 4.2. Proposed and In-Progress Mitigations 735 The following mitigations are based on Internet Drafts which have not 736 yet received broad consensus. They are described here to offer 737 exploratory path for solutions. These solutions should not be used 738 in a production environment. 740 o Third party authorization, [RFC6541], [I-D.otis-tpa-label] and 741 [I-D.kucherawy-dkim-delegate] provide ways to extend identifier 742 alignment under the control of the domain owner. 744 o DKIM with constrained transformations, 745 [I-D.kucherawy-dkim-list-canon] is proposed to allow message 746 modification. 748 o DKIM with recorded transformations, [I-D.kucherawy-dkim-transform] 749 is proposed to indicate what limited transformations were done to 750 the message so that a receiver could reverse them and confirm the 751 validity of the orignal DKIM signature. 753 o [I-D.kucherawy-original-authres] is intended as a way to pass 754 along Original Authentication Results to "downstream" receivers. 755 It is not widely implemented and relies on a trust relationship 756 between the forwarder and the other receivers. 758 o [I-D.levine-dkim-conditional] could be used to have the sender add 759 a limited DKIM signature, that signs only a very limited set of 760 header fields and not the body of the message. This DKIM 761 signature would come with the condition that a subsequent known 762 domain fully DKIM sign the message. For instance a Mailing List 763 could transform the message, add its DKIM signature and there 764 would be a valid DKIM signature aligned with the RFC5322.From that 765 would satisfy DMARC while limiting the possibilities of replay 766 attack. 768 4.2.1. Getting More Radical: Requiring New Communication Paths Between 769 MUAs 771 In practice a number of operators are using strict alignment mode in 772 DMARC in order to avoid receiving new and innovative forms of 773 unwanted and unauthentic email through systems purporting to be 774 mailing list handlers. The receiving ADMD has no knowledge of which 775 lists the user has subscribed to and which they have not. One avenue 776 of exploration would be for the user to authorize mailing lists as 777 proxies for authentication, at which point the receiving ADMD would 778 be vesting some trust in the mailing list service. The creators of 779 DKIM foresaw precisely this possibility at the time by not tightly 780 binding any semantics to the RFC5322.From header field. Some 781 experimental work has taken place in this area, as mentioned above. 782 Additional work might examine a new communication path to the user to 783 authorize some form of transitive trust. 785 5. IANA Considerations 787 This document contains no actions for IANA. [RFC Editor: Please 788 delete this section prior to publication.] 790 6. Security Considerations 792 This document is an analysis of DMARC's impact on indirect email 793 flows. It describes the possibility of accidental denial-of-service 794 that can be created by rejections of messages by DMARC-aware Mail 795 Receivers. However, it introduces no new security issues to Internet 796 messaging. 798 7. Acknowledgments 800 Miles Fidelman, John Levine, David Crocker, Stephen J. Turnbull, 801 Rolf E. Sonneveld, Tim Draegen and Franck Martin contributed to the 802 IETF DMARC Working Group's wiki page listing all known 803 interoperability issues with DMARC and indirect email flows. 805 Tim Draegen created the first draft of this document from these 806 contributions and by hamfistedly mapping contributions into the 807 language of [RFC5598]. 809 8. References 811 8.1. Normative References 813 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 814 Extensions (MIME) Part One: Format of Internet Message 815 Bodies", RFC 2045, November 1996. 817 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 818 3463, January 2003. 820 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 821 Language", RFC 5228, January 2008. 823 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 824 October 2008. 826 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 827 October 2008. 829 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 830 2009. 832 [RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part 833 Tests, Iteration, Extraction, Replacement, and Enclosure", 834 RFC 5703, October 2009. 836 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 837 Identified Mail (DKIM) Signatures", STD 76, RFC 6376, 838 September 2011. 840 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and 841 Mailing Lists", BCP 167, RFC 6377, September 2011. 843 [RFC6541] Kucherawy, M., "DomainKeys Identified Mail (DKIM) 844 Authorized Third-Party Signatures", RFC 6541, February 845 2012. 847 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, 848 "Deprecating the "X-" Prefix and Similar Constructs in 849 Application Protocols", BCP 178, RFC 6648, June 2012. 851 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 852 Authorizing Use of Domains in Email, Version 1", RFC 7208, 853 April 2014. 855 [RFC7372] Kucherawy, M., "Email Authentication Status Codes", RFC 856 7372, September 2014. 858 8.2. Informative References 860 [I-D.kucherawy-dkim-delegate] 861 Kucherawy, M. and D. Crocker, "Delegating DKIM Signing 862 Authority", draft-kucherawy-dkim-delegate-01 (work in 863 progress), June 2014. 865 [I-D.kucherawy-dkim-list-canon] 866 Kucherawy, M., "A List-safe Canonicalization for 867 DomainKeys Identified Mail (DKIM)", draft-kucherawy-dkim- 868 list-canon-00 (work in progress), June 2014. 870 [I-D.kucherawy-dkim-transform] 871 Kucherawy, M., "Recognized Transformations of Messages 872 Bearing DomainKeys Identified Mail (DKIM) Signatures", 873 draft-kucherawy-dkim-transform-00 (work in progress), 874 April 2015. 876 [I-D.kucherawy-original-authres] 877 Chew, M. and M. Kucherawy, "Original-Authentication- 878 Results Header Field", draft-kucherawy-original-authres-00 879 (work in progress), February 2012. 881 [I-D.levine-dkim-conditional] 882 Levine, J., "DKIM Conditional Signatures", draft-levine- 883 dkim-conditional-00 (work in progress), June 2014. 885 [I-D.otis-tpa-label] 886 Otis, D. and D. Black, "Third-Party Authorization Label", 887 draft-otis-tpa-label-00 (work in progress), May 2014. 889 [RFC7489] Kucherawy, M. and E. Zwicky, "Domain-based Message 890 Authentication, Reporting, and Conformance (DMARC)", RFC 891 7489, March 2015. 893 Authors' Addresses 895 Franck Martin (editor) 896 LinkedIn 897 Mountain View, CA 898 USA 900 Email: fmartin@linkedin.com 901 Eliot Lear (editor) 902 Cisco Systems GmbH 903 Richtistrasse 7 904 Wallisellen, ZH CH-8304 905 Switzerland 907 Phone: +41 44 878 9200 908 Email: lear@cisco.com 910 Tim Draegen (editor) 911 Eudaemonic Development LLC 912 PO Box 19443 913 Asheville, NC 28815 914 USA 916 Email: tim@eudev.net 918 Elizabeth Zwicky (editor) 919 Yahoo 920 Sunnyvale, CA 921 USA 923 Email: zwicky@yahoo-inc.com