idnits 2.17.1 draft-dmarc-interoperability-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 (January 19, 2015) is 3378 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 (-13) exists of draft-kucherawy-dmarc-base-11 == 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: July 23, 2015 Cisco Systems GmbH 6 T. Draegen, Ed. 7 Eudaemon 8 January 19, 2015 10 Interoperability Issues Between DMARC and Indirect Email Flows 11 draft-dmarc-interoperability-00 13 Abstract 15 DMARC introduces a mechanism for expressing domain-level policies and 16 preferences for message validation, disposition, and reporting. The 17 DMARC mechanism can encounter interoperability issues when messages 18 originate from third party sources, are modified in transit, or are 19 forwarded enroute to their final destination. Collectively these 20 email flows are referred to as indirect email flows. This document 21 describes interoperability issues between DMARC and indirect email 22 flows. Possible methods for addressing interoperability issues are 23 presented. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 23, 2015. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Document Conventions . . . . . . . . . . . . . . . . . . 3 61 2. Causes of Interoperability Issues . . . . . . . . . . . . . . 3 62 2.1. Identifier Alignment . . . . . . . . . . . . . . . . . . 4 63 2.2. Message Forwarding . . . . . . . . . . . . . . . . . . . 4 64 2.3. Message Modification . . . . . . . . . . . . . . . . . . 5 65 3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 5 66 3.1. Message Handling System . . . . . . . . . . . . . . . . . 5 67 3.1.1. Message Submission Agents . . . . . . . . . . . . . . 5 68 3.1.2. Message Transfer Agents . . . . . . . . . . . . . . . 6 69 3.1.2.1. Message Encoding . . . . . . . . . . . . . . . . 6 70 3.1.2.2. Anti-spam . . . . . . . . . . . . . . . . . . . . 7 71 3.1.2.3. Email Address Internationalization . . . . . . . 7 72 3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 7 73 3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 8 75 3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 8 76 3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 9 77 3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 9 78 3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 10 79 3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 10 80 4. Possible Solutions to Interoperability Issues . . . . . . . . 10 81 4.1. Identifier Alignment . . . . . . . . . . . . . . . . . . 11 82 4.2. Message Modification . . . . . . . . . . . . . . . . . . 11 83 4.3. Message Forwarding . . . . . . . . . . . . . . . . . . . 11 84 4.3.1. Original-Authentication-Results . . . . . . . . . . . 12 85 4.4. Message Handling Services . . . . . . . . . . . . . . . . 12 86 4.4.1. Message Transfer Agents . . . . . . . . . . . . . . . 12 87 4.4.1.1. Encoding . . . . . . . . . . . . . . . . . . . . 12 88 4.4.1.2. Filters . . . . . . . . . . . . . . . . . . . . . 12 89 4.4.1.3. Email Address Internationalization . . . . . . . 12 90 4.5. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 12 91 4.5.1. Mailing Lists . . . . . . . . . . . . . . . . . . . . 12 92 4.6. Getting More Radical: Requiring New Communication Paths 93 Between MUA and the Message Store . . . . . . . . . . . . 13 94 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 95 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 96 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 97 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 98 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 99 8.2. Informative References . . . . . . . . . . . . . . . . . 15 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 102 1. Introduction 104 DMARC [I-D.kucherawy-dmarc-base] introduces a mechanism for 105 expressing domain-level policies and preferences for message 106 validation, disposition, and reporting. DMARC is used to combat 107 exact-domain phishing, to gain visibility into email infrastructure, 108 and to provide email egress controls. Due to wide adoption, the 109 impact of DMARC-based email rejection policies on both direct and 110 indirect email flows can be significant. 112 The DMARC mechanism can encounter several different types of 113 interoperability issues due to message transformation or rerouting. 114 This is known collectively as indirect email flows. In some of these 115 cases, message content is modified as a result. 117 The next section describes interoperability issues between DMARC and 118 indirect email flows. These issues are first described in the 119 context of configuration behavior that DMARC requires from underlying 120 authentication technology, and then described as they appear in 121 context of the Internet Mail Architecture [RFC5598]. 123 Lastly, possible methods for addressing interoperability issues are 124 presented. There are often multiple ways to address any given 125 interoperability issue. Whereas this document strives to be 126 comprehensive in its review, it should not be treated as complete. 128 1.1. Document Conventions 130 Notation regarding structured fields is taken from [RFC5598]. 132 2. Causes of Interoperability Issues 134 What do we mean by "interoperability issues"? We say that DMARC 135 introduces interoperability issues or problems, when conformance to 136 the DMARC specification leads an implementation to reject a message 137 that is both compliant with the architecture as specified in 138 [RFC5598] and would have been viewed as legitimate in the eyes of the 139 intended recipient. This the secondary effects of behaviors caused 140 by that rejection. Therefore, we can already conclude that DMARC 141 poses no interoperability problems when messages properly validate 142 through its specified processes. The rest of this section, 143 therefore, delves into how legitimate messages may get rejected. 145 2.1. Identifier Alignment 147 A fundamental aspect of message source validation is understanding 148 how the originator of a message is validated. Each of the underlying 149 mechanisms that DMARC uses (DKIM [RFC6376] or SPF [RFC7208]) takes a 150 different approach. Therefore, the DMARC [I-D.kucherawy-dmarc-base] 151 mechanism attempts to predictably specify the domain of the 152 originator that will be used for its purposes (reporting/message 153 disposition). This step is referred to as Identifier Alignment. 155 DKIM provides a cryptographic means for a domain to be associated 156 with a particular message. However, the signing domain is not 157 required to be related to the domain contained in the 5322.From field 158 [RFC5322]. The DMARC identifier alignment process posits just such a 159 relationship. For an identifier to align in DKIM, the signing domain 160 must be part of the same organizational domain as the domain in the 161 5322.From field, and the signature must be valid. 163 In addition, DKIM allows for the possibility of multiple valid 164 signatures. The DMARC mechanism will process Authenticated 165 Identifiers that are based on DKIM signatures until an aligned 166 Authenticated Identifier is found (if any). However, operational 167 experience has shown that some implementations have difficulty 168 processing multiple signatures. The impact on DMARC processing is 169 clear: if an implementation cannot process multiple DKIM signatures 170 it may lead to perfectly valid messages being flagged as not 171 authentic. 173 SPF provides authenticated domain identifiers based on either the 174 5321.MailFrom [RFC5321] domain or, if the 5321.MailFrom address is 175 absent (as in the case of "bounces"), the domain found in the HELO/ 176 EHLO SMTP command. More often than not operators have not put an SPF 177 record on domains found in the HELO/EHLO SMTP command and when 178 present, it could be difficult to change this domain to the domain in 179 the 5322.From, especially when several mail streams share the same 180 sending IP address. 182 2.2. Message Forwarding 184 Message forwarding is a generic concept encapsulating a variety of 185 behaviors. Section 3 describes forwarding behavior as it relates to 186 the components of the Internet Mail Architecture. 188 When a message has been transmitted through a forwarder, there will 189 be no such relationship. With SPF, the domain of the 5321.MailFrom 190 or 5321.HELO/EHLO must match that of the 5322.From. Because 191 forwarders generally do not modify the 5322.From, this test will 192 fail. Thus a DMARC implementation must rely on DKIM, if available, 193 in these cases. 195 2.3. Message Modification 197 Modification of email content invalidates most DKIM signatures. 198 While DKIM provides a length flag so that content can be appended 199 (See Section 8.2 of RFC6376 [RFC6376] for additional discussion), in 200 practice, particularly with MIME-encoded messages, a mailing list 201 processor will do more than append (See Section 5.3 of [RFC5598] for 202 details). 204 3. Internet Mail Architecture, DMARC, and Indirect Email Flows 206 This section describes components within the Internet Mail 207 Architecture [RFC5598] where interoperability issues between DMARC 208 and indirect email flows can be found. 210 3.1. Message Handling System 212 Section 4 of [RFC5598] describes six basic components that fulfill 213 the purpose of the Message Handling System (MHS): 215 o Message 217 o Message User Agent (MUA) 219 o Message Submission Agent (MSA) 221 o Message Transfer Agent (MTA) 223 o Message Delivery Agent (MDA) 225 o Message Store (MS) 227 Of these components MSA, MTA, and MDA are discussed in relation to 228 interoperability with DMARC. 230 A Mediator is a special class of MUA that is given special 231 consideration in this section due to the unique issues Mediators face 232 when attempting to interoperate with DMARC. 234 3.1.1. Message Submission Agents 236 An MSA accepts messages submitted by a Message User Agent (MUA) and 237 enforces the policies of the hosting ADministrative Management Domain 238 (ADMD) and the requirements of Internet standards. 240 MSAs are split into two sub-components: 242 o Author-focused MSA functions (aMSA) 244 o MHS-focused MSA functions (hMSA) 246 MSA interoperability issues with DMARC begin when an aMSA accepts a 247 message where the 5322.From header contains a domain that is outside 248 of the ADMD of the MSA. The ADMD will almost certainly not be 249 capable of sending email that yields authenticated domain identifiers 250 related to the domain found in the 5322.From header. Examples of 251 this issue include "forward-to-friend" functionality commonly found 252 on news/article websites or "send-as" functionality present on some 253 MUAs. 255 When an hMSA takes responsibility for transit of a message containing 256 a domain in the 5322.From header that is outside of the hMSA's ADMD, 257 the hMSA faces DMARC interoperability issues if the domain publishes 258 a DMARC policy of "quarantine" or "reject". These issues are marked 259 by an inherent difficulty in modifying the domain present in a 260 message's 5322.From header. Examples of this issue include: 262 o Pseudo-open relays - a residential ISP that allows its customers 263 to relay any domains through its infrastructure. 265 o Embedded devices - cable/dsl modems, firewalls, wireless access 266 points that send email using hardcoded domains. 268 o Email service providers - ESPs that service customers that are 269 using freemail services where the freemail service publishes a 270 DMARC "reject" policy. 272 o Calendaring software - an invited member of an event modifies the 273 event causing calendaring software to emit an update that appears 274 to come from the creator of the event. 276 3.1.2. Message Transfer Agents 278 MTAs relay a message until the message reaches a destination MDA. 280 3.1.2.1. Message Encoding 282 An MTA may change the message encoding. For instance it may convert 283 8bits mail sections to quoted-printable 7bits sections, or just 284 change the character set from US-ASCII to ISO-8859-4. Such 285 transformations invalidate any present DKIM signature. 287 3.1.2.2. Anti-spam 289 To keep its reputation, an MTA that transfers message, may block or 290 otherwise remove harmful content from messages that are likely to be 291 unwanted by the next MTA. Any such modifications would invalidate a 292 DKIM signature. 294 3.1.2.3. Email Address Internationalization 296 A DMARC interoperability issue arises in the context of Email Address 297 Internationalization [RFC6530]. [RFC6854] allows group syntax in the 298 5322.From header during the transition period to SMTPUTF8. In the 299 case where an EAI/SMTPUTF8-aware MTA relays a message to a non-aware 300 MTA, the EAI/SMTPUTF8-aware MTA may transform the 5322.From header of 301 the message to include group syntax that allows the non-aware MTA to 302 process the email. 304 This transformation modifies the content of the message and will 305 invalide any DKIM signatures and possibly remove the ability for the 306 DMARC mechanism to receive an authenticated domain identifier from a 307 DKIM module. 309 3.1.3. Message Delivery Agents 311 The MDA transfers a message from the MHS to a mailbox. Like the MSA, 312 the MDA consists of two sub-components: 314 o MHS-focused MDA functions (hMDA) 316 o Recipient-focused MDA functions (rMDA) 318 Both the hMDA and the rMDA can redirect a message to an alternative 319 address. DMARC interoperability issues related to redirecting of 320 messages are described in Section 3.2. 322 SIEVE [RFC5228] functionality often lives in the rMDA sub-component 323 and can cause DMARC interoperability issues. The SIEVE 'addheader' 324 and 'deleteheader' filtering actions can modify messages and 325 invalidate DKIM signatures, removing DKIM- supplied authenticated 326 domain identifiers as inputs to the DMARC mechanism. 328 3.2. Mediators 330 Descriptions of Mediators are largely imported from [RFC5598]. 332 Mediators forward messages through a re-posting process. Mediators 333 share some functionality with basic MTA relaying, but have greater 334 flexibility in both addressing and content modifications. 336 DMARC interoperability issues are prevalent within the context of 337 Mediators, as Mediators represent a class of transformations that 338 mirror the concept of "indirect email flows". 340 3.2.1. Alias 342 An Alias is a simple re-addressing facility that provides one or more 343 new Internet Mail addresses, rather than a single, internal one. A 344 message continues through the transfer service for delivery to one or 345 more alternate addresses. 347 Aliases can be implemented by mailbox-level forwarding (e.g. through 348 "dot-forwarding") or SIEVE-level forwarding (through the SIEVE 349 'redirect' action). When an Alias preserves message content, DKIM 350 signatures may remain valid. However, Aliases extend the delivery 351 path beyond SPF's ability to grant authorization. 353 Examples of Aliasing include: 355 o Forwarding email between freemail providers to try different 356 interfaces while maintaining an original email address. 358 o Consolidating many email addresses into a single acccount to 359 centralize processing. 361 o Services that provides "activity based", "role based" , "vanity" 362 or "temporary" email addresses such as universities and 363 professional associations. 365 A fundamental challenge in dealing with workarounds involving Aliases 366 is that in many instances, the aMSA has no administrative 367 relationship to the ADMD of the alias. Another challenge is that the 368 underlying mechanisms upon which DMARC relies do not consider the 369 local-part of the addr-spec. While normally considered a perfectly 370 reasonable scaling feature, the underlying assumption is that Authors 371 will make use of aMSAs that are always authorized for a given domain. 372 For vanity domains, this assumption turns out to not hold. 374 3.2.2. ReSenders 376 ReSenders "splice" a message's addressing information to connect the 377 Author of the original message with the Recipient of the new message. 378 The new Recipient sees the message as being from the original Author, 379 even if the Mediator adds commentary. 381 ReSenders introduce DMARC interoperability issues as content 382 modification invalidates DKIM signatures. SPF's ability to grant 383 authorization via alignement is removed as the new Recipient receives 384 the message from the Mediator. 386 Without an ability to produce authenticated domain identifiers 387 relevant to the Author's 5322.From domain using either DKIM or SPF, 388 the new Recipient has almost no chance of successfully applying the 389 DMARC mechanism. 391 Examples of ReSenders include MUA-level forwarding by resending a 392 message to a new recipient or by forwarding a message "inline" to a 393 new recipient (this does not include forwarding a message "as an 394 attachment"). An additional example comes in the form of calendering 395 software that allows a meeting attendee (not the meeting organizer) 396 to modify the content of an invite causing the invitations to appear 397 to be reissued from the meeting organizer. 399 3.2.3. Mailing Lists 401 A Mailing List receives messages as an explicit addressee and then 402 re-posts them to a list of subscribed members. The Mailing List 403 performs a task that can be viewed as an elaboration of the ReSender. 405 Mailing Lists share the same DMARC interoperability issues as 406 ReSenders (Section 3.2.2), plus the following: 408 o Subscribed members may not receive email from members that post 409 using domains that publish a DMARC "p=reject" policy. 411 o Mailing Lists may interpret DMARC-related email rejection as an 412 inability to deliver email to the recipients that are checking and 413 enforcing DMARC policy. This processing may cause subscribed 414 members to be suspended or removed from the Mailing List. 416 3.2.4. Gateways 418 A Gateway performs the basic routing and transfer work of message 419 relaying, but it also is permitted to modify content, structure, 420 address, or attributes as needed to send the message into a messaging 421 environment that operates under different standards or potentially 422 incompatible policies. 424 Gateways share the same DMARC interoperability issues as ReSenders 425 (Section 3.2.2). 427 Gateways may share also the same DMARC interopreability issues as 428 MTAs (Section 3.1.2). 430 Gateway-level forwarding can introduce DMARC interoperability issues 431 if the Gateway is configured to rewrite the message to map between 432 recipient domains. For example, an acquisition may lead the 433 acquiring company to decide to decommission the acquired companies 434 domains by rewriting messages to use the domain of the acquiring 435 company. 437 3.2.5. Boundary Filters 439 To enforce security boundaries, organizations can subject messages to 440 analysis for conformance with its safety policies. A filter might 441 alter the content to render it safe, such as by removing content 442 deemed unacceptable. 444 Boundary Filters share the same DMARC interoperability issues as 445 ReSenders. 447 Examples of Boundary Filters include: 449 o Antispam services that remove or modify content. 451 o Any service that reformulates the 5322.body for any other reason. 453 o Secondary MX services. In this case, however, it is inappropriate 454 for a primary MX server to perform an SPF check against its own 455 secondaries. Rather, the secondary MX should perform this 456 function. 458 3.3. Combinations 460 The causes of indirect email flows can be combined. For example, a 461 university student may subscribe to a mailing list (using his 462 university email address) while this university email address is 463 configured to forward all emails to a freemail provider where a more 464 permanent email address for this student exists. 466 Within an organisation the message may passes through various MTAs 467 (Section 3.1.2) that performs each one a different function, 468 authentication, filtering, distribution,... 470 4. Possible Solutions to Interoperability Issues 472 Solutions to interoperability issues between DMARC and indirect email 473 flows vary from improving of underlying processors, such as proper 474 handling multiple DKIM signatures, to more radical approaches to the 475 messaging architecture. This section decribes possible ways to 476 address interoperability issues. 478 Through external knowledge it may be possible to determinine that the 479 DMARC mechanism cannot be applied to a particular message because 480 modification and/or forwarding is to be expected through the normal 481 course of operations for a given sender. This is known as an 482 "override". 484 4.1. Identifier Alignment 486 In the case of forwarders, identity alignment poses a substantial 487 concern. A receiving ADMD may track subscriptions to mailing lists, 488 so that different processing may be applied to those messages. 490 Various proposals have been submitted to provide either some form of 491 transitive trust between an email sender, a realy and an email 492 receiver, or to allow a modified version of DKIM to survive light 493 transformation to the message: 495 o DKIM conditional signatures, [I-D.levine-dkim-conditional] 497 o Third party authorization, [RFC6541], [I-D.otis-tpa-label] and 498 [I-D.kucherawy-dkim-delegate] 500 o DKIM with light transformations, [I-D.kucherawy-dkim-list-canon] 502 4.2. Message Modification 504 Message modification invalidates DKIM signatures and complicates a 505 receiver's ability to generate authenticated domain identifiers from 506 a message. It is therefore important to review the MTAs 507 (Section 3.1.2) configuration to ensure no modification of the 508 message is done when simply forwarding the message. Furthermore 509 Filters should not add to or modify the body of the message, but 510 either rejecting the message or adding email headers to indicate the 511 result of the filter. 513 4.3. Message Forwarding 515 Forwarding messages without modification is referred to as 516 "transparent forwarding", and is a way to preserve the validity of 517 DKIM signatures. 519 The X-Original-From header is used in various contexts. 521 Note that Original-From is merely adding complexity to the 'who was 522 the author of this message' assessment, very possibly creating yet- 523 another security hole. 525 4.3.1. Original-Authentication-Results 527 Mentioned in early drafts [I-D.kucherawy-original-authres] as a way 528 to pass along Original Authentication Results to "downstream" 529 receivers. 531 4.4. Message Handling Services 533 4.4.1. Message Transfer Agents 535 4.4.1.1. Encoding 537 There is very little reason to modify the encoding of the message, 538 compatibility issues between international character sets are few 539 nowadays. No modification of the message should be done when simply 540 forwarding the message. 542 4.4.1.2. Filters 544 Filters should not add to or modify the body of the message, but 545 either should reject the message or add new email headers (not under 546 DKIM) to indicate the result of the filter. 548 4.4.1.3. Email Address Internationalization 550 The postmaster will choose the solution best for its users but really 551 to avoid DMARC not finding a single useable domain in the 5322.From, 552 the real solution is to upgrade your MTAs, if you want to do DMARC, 553 to support EAI (SMTPUTF8) so that the group syntax in the 5322.From 554 is not needed for interoperability issues during transition, and such 555 syntax be considered at least as suspicious when present. 557 4.5. Mediators 559 4.5.1. Mailing Lists 561 o One common mitigation policy is to configure the Mailing List 562 Manager (MLM) to alter the RFC5322.From field to use the domain of 563 the MLM. Since most list subscribers prefer to know the identity 564 of the author of the original message, typically this information 565 may be provided in the display name part of the RFC5322.From 566 field. This display name needs to be carefully crafted as to not 567 collide with the original display name of the author, nor contain 568 something that looks like an email address or domain name. These 569 modification may to some extent defeats the purpose of DMARC 570 itself. It may make it difficult to ensure that users of all 571 email clients can easily reply to author, list, or all using the 572 email client features provided for that purpose. Use of "Reply- 573 To" can alleviate this problem depending if the mailing list is 574 configured to reply-to-list, reply-to-author or reply-to-fixed- 575 address. 577 o Another common mitigation policy is to configure the MLM to "wrap" 578 the message in a MIME message/rfc822 part. This completely 579 bypasses the DMARC policy in clients that allow reading the part 580 as a message. Many email clients (as of August 2014) have 581 difficulty reading such messages. 583 o Finally a less common mitigation policy, is to configure the MLM 584 to not modify the message so that the DKIM signature remains 585 valid. 587 o To alleviate unsubscribes to the mailing list due to the messages 588 bouncing because of DMARC, the MLM needs to not act on bounces due 589 to Message Authentication issues. Correctly interpreting Extended 590 SMTP error messages is useful in this case. 592 All these techniques may provide some specific challenges in MUAs and 593 different operational usages for end users (like rewriting filters to 594 sort emails in folders). There will be some time before all 595 implications are understood and alleviated. 597 4.6. Getting More Radical: Requiring New Communication Paths Between 598 MUA and the Message Store 600 In practice a number of operators are using strict alignement mode in 601 DMARC in order to avoid receiving new and innovative forms of 602 unwanted and unauthentic mail through systems purporting to be 603 mailing list handlers. The receiving ADMD has no knowledge of which 604 lists the user has subscribed to and which they have not. One avenue 605 of exploration would be for the user to authorize mailing lists as 606 proxies for authentication, at which point the receiving ADMD would 607 be vesting some trust in the mailing list service. The creators of 608 DKIM foresaw precisely this possibility at the time by not tightly 609 binding any semantics to the 5322.From. Some experimental work has 610 taken place in this area, as mentioned above. Additional work might 611 examine a new communication path to the user to authorize third party 612 signatures. 614 5. IANA Considerations 616 No IANA considerations. 618 6. Security Considerations 620 No Security considerations. 622 7. Acknowledgments 624 Miles Fidelman, John Levine, David Crocker, Stephen J. Turnbull, 625 Rolf E. Sonneveld, Tim Dragen and Franck Martin contributed to the 626 IETF DMARC Working Group's wiki page listing all known 627 interoperability issues with DMARC and indirect mail flows. 629 Tim Draegen created the first draft of this document from these 630 contributions and by carefully mapping contributions into the 631 language of [RFC5598]. 633 8. References 635 8.1. Normative References 637 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 638 Language", RFC 5228, January 2008. 640 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 641 October 2008. 643 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 644 October 2008. 646 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 647 2009. 649 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 650 Identified Mail (DKIM) Signatures", STD 76, RFC 6376, 651 September 2011. 653 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 654 Internationalized Email", RFC 6530, February 2012. 656 [RFC6541] Kucherawy, M., "DomainKeys Identified Mail (DKIM) 657 Authorized Third-Party Signatures", RFC 6541, February 658 2012. 660 [RFC6854] Leiba, B., "Update to Internet Message Format to Allow 661 Group Syntax in the "From:" and "Sender:" Header Fields", 662 RFC 6854, March 2013. 664 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 665 Authorizing Use of Domains in Email, Version 1", RFC 7208, 666 April 2014. 668 8.2. Informative References 670 [I-D.kucherawy-dkim-delegate] 671 Kucherawy, M. and D. Crocker, "Delegating DKIM Signing 672 Authority", draft-kucherawy-dkim-delegate-01 (work in 673 progress), June 2014. 675 [I-D.kucherawy-dkim-list-canon] 676 Kucherawy, M., "A List-safe Canonicalization for 677 DomainKeys Identified Mail (DKIM)", draft-kucherawy-dkim- 678 list-canon-00 (work in progress), June 2014. 680 [I-D.kucherawy-dmarc-base] 681 Kucherawy, M. and E. Zwicky, "Domain-based Message 682 Authentication, Reporting and Conformance (DMARC)", draft- 683 kucherawy-dmarc-base-11 (work in progress), January 2015. 685 [I-D.kucherawy-original-authres] 686 Chew, M. and M. Kucherawy, "Original-Authentication- 687 Results Header Field", draft-kucherawy-original-authres-00 688 (work in progress), February 2012. 690 [I-D.levine-dkim-conditional] 691 Levine, J., "DKIM Conditional Signatures", draft-levine- 692 dkim-conditional-00 (work in progress), June 2014. 694 [I-D.otis-tpa-label] 695 Otis, D. and D. Black, "Third-Party Authorization Label", 696 draft-otis-tpa-label-00 (work in progress), May 2014. 698 Authors' Addresses 700 Franck Martin (editor) 701 LinkedIn 702 Mountain View, CA 703 USA 705 Email: fmartin@linkedin.com 706 Eliot Lear (editor) 707 Cisco Systems GmbH 708 Richtistrasse 7 709 Wallisellen, ZH CH-8304 710 Switzerland 712 Phone: +41 44 878 9200 713 Email: lear@cisco.com 715 Tim Draegen (editor) 716 Eudaemon 717 NC 718 USA 720 Email: tim@eudaemon.net