idnits 2.17.1 draft-ietf-dmarc-interoperability-05.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 (August 17, 2015) is 3168 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4408 (Obsoleted by RFC 7208) == 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: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMARC F. Martin, Ed. 3 Internet-Draft LinkedIn 4 Intended status: Informational E. Lear, Ed. 5 Expires: February 18, 2016 Cisco Systems GmbH 6 T. Draegen, Ed. 7 dmarcian, inc. 8 E. Zwicky, Ed. 9 Yahoo 10 K. Andersen, Ed. 11 LinkedIn 12 August 17, 2015 14 Interoperability Issues Between DMARC and Indirect Email Flows 15 draft-ietf-dmarc-interoperability-05 17 Abstract 19 DMARC introduces a mechanism for expressing domain-level policies and 20 preferences for email message validation, disposition, and reporting. 21 The DMARC mechanism can encounter interoperability issues when 22 messages do not flow directly from the author's administrative domain 23 to the final recipients. Collectively these email flows are referred 24 to as indirect email flows. This document describes interoperability 25 issues between DMARC and indirect email flows. Possible methods for 26 addressing interoperability issues are presented. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on February 18, 2016. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Document Conventions . . . . . . . . . . . . . . . . . . 4 64 2. Causes of Interoperability Issues . . . . . . . . . . . . . . 4 65 2.1. Identifier Alignment . . . . . . . . . . . . . . . . . . 4 66 2.2. Message Forwarding . . . . . . . . . . . . . . . . . . . 5 67 2.3. Message Modification . . . . . . . . . . . . . . . . . . 6 68 3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 6 69 3.1. Message Handling System . . . . . . . . . . . . . . . . . 7 70 3.1.1. Message Submission Agents . . . . . . . . . . . . . . 7 71 3.1.2. Message Transfer Agents . . . . . . . . . . . . . . . 8 72 3.1.2.1. Message Encoding . . . . . . . . . . . . . . . . 8 73 3.1.2.2. Header Standardization . . . . . . . . . . . . . 8 74 3.1.2.3. Content Validation . . . . . . . . . . . . . . . 9 75 3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 9 76 3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 9 77 3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 9 78 3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 10 79 3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 11 80 3.2.3.1. Mailing List Operational Effects . . . . . . . . 11 81 3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 12 82 3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 12 83 3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 13 84 4. Possible Mitigations of Interoperability Issues . . . . . . . 13 85 4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 14 86 4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 14 87 4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 15 88 4.1.1.2. Message Modification . . . . . . . . . . . . . . 15 89 4.1.2. Mitigations for Receivers . . . . . . . . . . . . . . 16 90 4.1.2.1. Identifier Alignment . . . . . . . . . . . . . . 16 91 4.1.2.2. Policy Override . . . . . . . . . . . . . . . . . 16 92 4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 16 93 4.1.3.1. Changes to the RFC5322.From . . . . . . . . . . . 16 94 4.1.3.2. Avoiding Message Modification . . . . . . . . . . 16 95 4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 17 96 4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 18 97 4.2.1. Getting More Radical: Requiring New Communication 98 Paths Between MUAs . . . . . . . . . . . . . . . . . 19 99 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 100 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 101 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 102 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 103 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 104 8.2. Informative References . . . . . . . . . . . . . . . . . 21 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 107 1. Introduction 109 DMARC [RFC7489] introduces a mechanism for expressing domain-level 110 policies and preferences for message validation, disposition, and 111 reporting. The DMARC mechanism can encounter several different types 112 of interoperability issues due to third-party message sourcing, 113 message transformation or rerouting. 115 At the time of the writing of this document, the DMARC base 116 specification is published as an Informational RFC and has seen 117 significant deployment within the email community. 119 Cases in which email does not flow directly from the author's 120 administrative domain to the recipient's domain(s) are collectively 121 referred to in this document as indirect email flows. Due to 122 existing and increasing adoption of DMARC, the impact of DMARC-based 123 email rejection policies on email flows can be significant for a 124 select subset of general email traffic. 126 Several known causes of interoperability issues are presented, 127 followed by a description of components within the Internet Mail 128 Architecture [RFC5598] where interoperability issues can arise. 130 Finally, known and possible methods for addressing interoperability 131 issues are presented. There are often multiple ways to address any 132 given interoperability issue. While this document strives to be 133 comprehensive in its review, it should not be treated as complete. 134 Also, some practices which are in use at the time of this document 135 may or may not be "best practices" as future standards evolve. 137 1.1. Document Conventions 139 Notation regarding structured fields is taken from [RFC5598]. 141 Organizational Domain and Authenticated Identifiers are specified in 142 DMARC [RFC7489]. 144 2. Causes of Interoperability Issues 146 Interoperability issues between DMARC and indirect email flows arise 147 when conformance to the DMARC specification leads a receiving 148 implementation to apply DMARC based policy restrictions to messages 149 that are both compliant with the architecture as specified in 150 [RFC5598] and viewed as legitimate by the intended recipient. 152 Note that domains which assert a p=None policy and email which passes 153 standard DMARC validation do not have any interoperability issues. 155 Email messages that do not conform to other email specifications but 156 are considered legitimate by the intended recipients are not 157 discussed in this document. The rest of this section describes 158 several conceptual causes of interoperability issues. 160 2.1. Identifier Alignment 162 DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform message 163 source validation. The DMARC [RFC7489] mechanism refers to source 164 domains that are validated by DKIM or SPF as Authenticated 165 Identifiers. DMARC requires an Authenticated Identifier to be 166 related to the domain found in the message's RFC5322.From header 167 field [RFC5322]. This relationship is referred to as Identifier 168 Alignment. 170 DMARC allows for Identifier Alignment to be achieved in two different 171 modes: strict and relaxed. Strict mode requires an exact match of 172 either of the Authenticated Identifiers to the message's RFC5322.From 173 header field [RFC5322]. Relaxed mode allows for Identifier Alignment 174 if Authenticated Identifiers and the message's RFC5322.From header 175 field [RFC5322] share the same Organizational Domain. In general, 176 interoperability issues between strict and relaxed modes are the 177 same, with strict mode constraining the application of possible 178 solutions. The mitigations described in this document generally 179 require a relaxed mode of Identifier Alignment. 181 DKIM provides a cryptographic means for a domain identifier to be 182 associated with a particular message. As a standalone technology 183 DKIM identifiers are not required to be relevant to the content of a 184 message. However, for a DKIM identifier to align in DMARC, the 185 signing domain of a valid signature must be part of the same 186 Organizational Domain as the domain in the RFC5322.From header field 187 [RFC5322]. 189 In addition, DKIM allows for the possibility of multiple valid 190 signatures. The DMARC mechanism will process Authenticated 191 Identifiers that are based on DKIM signatures until an aligned 192 Authenticated Identifier is found (if any). However, operational 193 experience has shown that some implementations have difficulty 194 processing multiple signatures. The impact on DMARC processing is 195 clear: implementations that cannot process multiple DKIM signatures 196 may incorrectly flag messages as "failing DMARC" and erroneously 197 apply DMARC based policy to otherwise conforming messages. 199 SPF can provide two Authenticated Identifiers. The first one is the 200 RFC7208.HELO [RFC7208] based on the RFC5321.HELO/EHLO. The second 201 one is the RFC7208.MAILFROM [RFC7208] based on the RFC5321.MailFrom 202 [RFC5321] domain, or, if the RFC5321.MailFrom address is absent (as 203 in the case of "bounce" messages, on the domain found in the HELO/ 204 EHLO SMTP command. DMARC uses only the SPF results for the 205 RFC7208.MAILFROM identifier for alignment (this is often true for 206 local policies outside of DMARC as well). The SPF validated domain 207 in RFC7208.MAILFROM must be part of the same Organizational Domain as 208 the domain in the RFC5322.From header field to be aligned. It is 209 important to note that even when an SPF record exists for the domain 210 in RFC5322.From, SPF will not authenticate it unless it is also the 211 domain which the SPF analysis has checked. Also note that 212 RFC7208.MAILFROM definition is different from RFC5321.MailFrom 213 [RFC5321] definition. The RFC7208.MAILFROM definition has not 214 changed from the RFC4408.MAILFROM [RFC4408] definition, the earlier 215 version of the SPF specification, however, not all implementations 216 have updated to the [RFC7208] algorithm which can lead to unexpected 217 results. 219 2.2. Message Forwarding 221 Message forwarding is a generic concept encapsulating a variety of 222 behaviors. Section 3 describes forwarding behavior as it relates to 223 the components of the Internet Mail Architecture. 225 All forwarding behavior involves the retransmission of email. As 226 discussed above, in order for SPF to yield an Authenticated 227 Identifier that is pertinent to DMARC, the domain of the 228 RFC7208.MAILFROM must be in alignment with the RFC5322.From header 229 field. Forwarding introduces specific issues to the availability of 230 SPF-based Authenticated Identifiers: 232 o If the RFC5321.MailFrom is present and the forwarder maintains the 233 original RFC5321.MailFrom, SPF validation will fail unless the 234 forwarder is an authorized part of the originator's email sending 235 infrastructure. If the forwarder replaces the RFC5321.MailFrom 236 with its own domain, SPF may pass but Identifier Alignment with 237 the RFC5322.From header field will fail. 239 o If the RFC5321.MailFrom is empty (as in the case of Delivery 240 Status Notifications), the RFC5321.Helo domain of the forwarder 241 will likely be in different organizational domain of the 242 RFC5322.From header field. SPF may pass but Identifier Alignment 243 with the RFC5322.From header field fails. 245 In both cases, SPF cannot yield relevant Authenticated Identifiers, 246 and DKIM must be relied upon to produce results that are relevant to 247 DMARC. 249 2.3. Message Modification 251 Modification of email content invalidates most DKIM signatures, and 252 many message forwarding systems modify email content. Mailing list 253 processors are a common example of such systems, but other forwarding 254 systems also make modifications. 256 Although DKIM provides a length flag so that content can be appended 257 without invalidating the signature, in practice, particularly with 258 MIME-encoded [RFC2045] messages, a mailing list processor will do 259 more than simply append content (see Section 5.3 of [RFC5598] for 260 details). Furthermore, the length flag is seldom used due to 261 security issues (see Section 8.2 of [RFC6376] for additional security 262 considerations). 264 DKIM describes two canonicalizations for use when preparing headers 265 and body for DKIM processing: simple and relaxed. The latter allows 266 for trivial modifications (largely regarding whitespace folding) that 267 maintain the integrity of the content of the email. However, the 268 relaxed canonicalization is more computationally intensive and may 269 not have been preferred in the early deployment of DKIM, leaving some 270 deployments using the less forgiving "simple" canonicalization. 271 While the prevalence is unknown, there are some DKIM checkers which 272 have problems evaluating relaxed canonicalization correctly. 274 3. Internet Mail Architecture, DMARC, and Indirect Email Flows 276 This section describes components within the Internet Mail 277 Architecture [RFC5598] where interoperability issues between DMARC 278 and indirect email flows can be found. 280 3.1. Message Handling System 282 Section 4 of [RFC5598] describes six basic components that make up 283 the Message Handling System (MHS): 285 o Message 287 o Message User Agent (MUA) 289 o Message Submission Agent (MSA) 291 o Message Transfer Agent (MTA) 293 o Message Delivery Agent (MDA) 295 o Message Store (MS) 297 Of these components MSA, MTA, and MDA are discussed in relation to 298 interoperability with DMARC. 300 A Mediator is a hybrid of several component types that is given 301 special consideration in this section due to the unique issues 302 Mediators face when attempting to interoperate with DMARC. 304 3.1.1. Message Submission Agents 306 An MSA accepts messages submitted by a Message User Agent (MUA) and 307 enforces the policies of the hosting ADministrative Management Domain 308 (ADMD) and the requirements of Internet standards. 310 MSAs are split into two sub-components: 312 o Author-focused MSA functions (aMSA) 314 o MHS-focused MSA functions (hMSA) 316 MSA interoperability issues with DMARC begin when an aMSA accepts a 317 message where the RFC5322.From header field contains a domain that is 318 outside of the ADMD of the MSA. The ADMD will almost certainly not 319 be capable of sending email that yields Authenticated Identifiers 320 aligned with the domain found in the RFC5322.From header field. 321 Examples of this issue include "forward-to-friend" functionality 322 commonly found on news/article websites or "send-as" functionality 323 present on some MUAs. 325 When an hMSA takes responsibility for transit of a message containing 326 a domain in the RFC5322.From header field that is outside of the 327 hMSA's ADMD, the hMSA faces DMARC interoperability issues if the 328 domain publishes a DMARC policy of "quarantine" or "reject". These 329 issues are marked by the inherent difficulty of establishing 330 alignment with the domain present in a message's RFC5322.From header 331 field. Examples of this issue include: 333 o Pseudo-open relays - a residential ISP that allows its customers 334 to relay non-local domains through its infrastructure. 336 o Embedded devices - cable/DSL modems, firewalls, wireless access 337 points, printers that send email using hardcoded domains. 339 o Devices that send mail on behalf of a user - scanners, security 340 cameras, alarms that send mail as their owner or a device user. 342 o Email service providers - ESPs that service customers who are 343 using domains which publish a DMARC "reject" policy. 345 o Calendaring software - an invited member of an event modifies the 346 event causing calendaring software to emit an update that claims 347 to come from the creator of the event. 349 3.1.2. Message Transfer Agents 351 MTAs relay a message until the message reaches a destination MDA. 353 3.1.2.1. Message Encoding 355 An MTA may modify the message encoding, for instance by converting 356 8-bit MIME sections to quoted-printable 7-bit sections. This 357 modification is outside the scope of DKIM canonicalization and will 358 invalidate DKIM signatures that include message content. 360 An MTA may also re-encode the message without changing the encoding 361 type, receiving a MIME-encoded message and producing a semantically 362 and syntactically equivalent MIME body that is not identical to the 363 original. This is characteristic of systems that use some other 364 message representation internally. 366 3.1.2.2. Header Standardization 368 An MTA may rewrite headers to bring headers into compliance with 369 existing RFCs. For example, some common MTAs will correct 370 comprehensible but non-compliant date formats to compliant ones. 372 Header rewriting is outside the scope of DKIM canonicalization and 373 will invalidate DKIM signatures. All downstream DMARC processing 374 with be unable to utilize DKIM to yield Authenticated Identifiers due 375 to header rewriting. 377 Providing solutions for issues relating to non RFC-compliant emails 378 is outside the scope of this document. 380 3.1.2.3. Content Validation 382 An MTA may also implement security-motivated changes to the content 383 of email messages, dropping or altering sections of messages, causing 384 breakage of DKIM signatures 386 3.1.3. Message Delivery Agents 388 The MDA transfers a message from the MHS to a mailbox. Like the MSA, 389 the MDA consists of two sub-components: 391 o MHS-focused MDA functions (hMDA) 393 o Recipient-focused MDA functions (rMDA) 395 Both the hMDA and the rMDA can redirect a message to an alternative 396 address. DMARC interoperability issues related to redirecting of 397 messages are described in Section 3.2. 399 SIEVE [RFC5228] functionality often lives in the rMDA sub-component 400 and can cause DMARC interoperability issues. The SIEVE 'addheader' 401 and 'deleteheader' filtering actions can modify messages and 402 invalidate DKIM signatures, removing DKIM-supplied Authenticated 403 Identifiers as inputs to the DMARC mechanism. There are also SIEVE 404 extensions that modify the body. SIEVE alterations may only become 405 an issue when the email is reintroduced into the transport 406 infrastructure. 408 3.2. Mediators 410 See [RFC5598] for a complete definition of Mediators. 412 Mediators forward messages through a re-posting process. Mediators 413 share some functionality with basic MTA relaying, but have greater 414 flexibility in both addressing and content modifications. 416 DMARC interoperability issues are common within the context of 417 Mediators, which are often used precisely for their ability to modify 418 messages. 420 3.2.1. Alias 422 An Alias is a simple re-addressing facility that provides one or more 423 new Internet Mail addresses, rather than a single, internal one. A 424 message continues through the transfer service for delivery to one or 425 more alternative addresses. 427 Aliases can be implemented by mailbox-level forwarding (e.g. through 428 "dot-forwarding") or SIEVE-level forwarding (through the SIEVE 429 'redirect' action) or other methods. When an Alias preserves message 430 content and does not make significant header changes, DKIM signatures 431 may remain valid. However, Aliases often extend the delivery path 432 outside of the scope covered by the originating ADMD's SPF record(s). 434 Examples of Aliasing include: 436 o Forwarding email between freemail providers to try different 437 interfaces while maintaining an original email address. 439 o Consolidating many email addresses into a single account to 440 centralize processing. 442 o Services that provide "activity based", "role based" , "vanity" or 443 "temporary" email addresses such as universities and professional 444 associations. For instance professional or alumni institutions 445 may offer their members an alias for the duration of their 446 membership but may not want to deal with the long term storage of 447 emails. 449 In most cases, the aMSA providing Alias services has no 450 administrative relationship to the ADMD of the originator or the 451 final recipient, so solutions to Alias-related DMARC failure should 452 not assume such a relationship. 454 3.2.2. ReSenders 456 ReSenders "splice" a message's addressing information to connect the 457 Author of the original message with the Recipient(s) of the new 458 message. The new Recipient sees the message as being from the 459 original Author, even if the Mediator adds commentary. 461 ReSenders introduce DMARC interoperability issues as content 462 modification invalidates DKIM signatures. SPF's ability to grant 463 authorization via alignment is removed as the new Recipient receives 464 the message from the Mediator rather than the initial organization. 466 Without Authenticated Identifiers aligned with the Author's 467 RFC5322.From header field domain, the new Recipient has no way to 468 achieve a passing DMARC evaluation. 470 Examples of ReSenders include MUA-level forwarding by resending a 471 message to a new recipient or by forwarding a message "inline" to a 472 new recipient (this does not include forwarding a message "as an 473 attachment"). An additional example comes in the form of calendaring 474 software that allows a meeting attendee (not the meeting organizer) 475 to modify the content of an invite generating new invitations that 476 claim to be reissued from the meeting organizer. 478 3.2.3. Mailing Lists 480 A Mailing List receives messages as an explicit addressee and then 481 reposts them to a list of subscribed members. The Mailing List 482 performs a task that can be viewed as an elaboration of the ReSender 483 actions. 485 Mailing Lists share the same DMARC interoperability issues as 486 ReSenders (Section 3.2.2), and very commonly modify headers or 487 message content in ways that will cause DKIM to fail, including: 489 o prepending the RFC5322.Subject header field with a tag, to allow 490 the recipient to easily identify the mailing list within a subject 491 line listing. 493 o adding a footer to the email body to contain administrative 494 instructions. 496 o removing some MIME-parts from the email or converting the message 497 to text only. 499 o PGP-encrypting or S/MIME encrypting the body with the receiver's 500 key. 502 o enforcing community standards by rewriting banned words. 504 o allowing moderators to add arbitrary commentary to messages. 506 Any such modifications would invalidate a DKIM signature. 508 Header and content modifications are common for many mailing lists 509 and are often central to present mailing list functionality and 510 usage. Furthermore, MUAs have come to rely on mailing list message 511 modifications to present messages to end users in expected ways. 513 3.2.3.1. Mailing List Operational Effects 515 Mailing Lists may also have the following DMARC interoperability 516 issues: 518 o Subscribed members may not receive email from members that post 519 using domains that publish a DMARC "p=reject" policy. 521 o Mailing Lists may interpret DMARC-related email rejections as an 522 inability to deliver email to the recipients that are checking and 523 enforcing DMARC policy. This processing may cause subscribers 524 that are checking and enforcing DMARC policy to be inadvertently 525 suspended or removed from the Mailing List. 527 3.2.4. Gateways 529 A Gateway performs the basic routing and transfer work of message 530 relaying, but it also is permitted to modify content, structure, 531 addressing, and/or other attributes as needed to send the message 532 into a messaging environment that operates under different standards 533 or potentially incompatible policies. 535 Gateways share the same DMARC interoperability issues as ReSenders 536 (Section 3.2.2). 538 Gateways may share also the same DMARC interoperability issues as 539 MTAs (Section 3.1.2). 541 Receiver systems on the non-SMTP side of a protocol gateway may be 542 unable to evaluate DKIM and SPF. If a message passes through a 543 second protocol gateway back into the SMTP domain, the 544 transformations commonly break the original DKIM signature(s). 546 Gateway-level forwarding can introduce DMARC interoperability issues 547 if the Gateway is configured to rewrite the message into alternate 548 recipient domains. For example, an acquisition may lead an acquiring 549 company to decide to decommission the acquired company's domains by 550 rewriting messages to use the domain of the acquiring company. Since 551 the RFC5322.To header field is usually DKIM-signed, this kind of 552 rewriting will invalidate such DKIM signatures. 554 3.2.5. Boundary Filters 556 To enforce security boundaries, organizations can subject messages to 557 analysis for conformance with their safety policies. A filter might 558 alter the content to render it safe, such as by removing or otherwise 559 altering content deemed unacceptable. 561 Boundary Filters share the same DMARC interoperability issues as 562 ReSenders. 564 Issues may arise with SPF and DKIM evaluation if performed after 565 filter modifications. 567 Examples of Boundary Filters include: 569 o Malware scanning: To protect readers and its reputation, an MTA 570 that transfers a message may remove content believed to be harmful 571 from messages, reformulate content to canonical formats in order 572 to make them more trustworthy or easier to scan, and/or add text 573 in the body to indicate the message has been scanned. Any such 574 modifications would invalidate a DKIM signature. 576 o Spam filtering: To protect reputation and assist other MTAs, an 577 MTA may modify a message to indicate its decision that the message 578 is likely to be unwanted, and/or add text in the body to indicate 579 that such filtering has been done. 581 o Other text additions: An MTA may add an organizational disclaimer 582 or advertisement, for instance. 584 o Secondary MX services: The secondary MX for an organization may be 585 external to the normal mail processing for the organization, and 586 queue and forward to the primary when it becomes available. This 587 will not invalidate DKIM but will prevent the primary from 588 validating SPF normally. In this case, however, it is 589 inappropriate for a primary MX server to perform an SPF check 590 against its own secondaries. Rather, the secondary MX should 591 perform this function and employ some trusted mechanism to 592 communicate the results of the SPF, DKIM and DMARC evaluation(s) 593 to the primary MX server. 595 3.3. Combinations 597 Indirect email flows can be combined. For example, a university 598 student may subscribe to a mailing list (using his university email 599 address) while this university email address is configured to forward 600 all emails to a freemail or a post-education corporate account 601 provider where a more permanent email address for this student 602 exists. 604 Within an organization the message may pass through various MTAs 605 (Section 3.1.2), each of which performs a different function 606 (authentication, filtering, distribution, etc.) 608 4. Possible Mitigations of Interoperability Issues 610 Solutions to interoperability issues between DMARC and indirect email 611 flows vary widely in their scope and implications. They range from 612 improvements to underlying processors, such as proper handling of 613 multiple DKIM signatures, to more radical changes to the messaging 614 architecture. This section describes possible ways to address 615 interoperability issues. Note that these particular mechanisms may 616 not be considered "best practices" and may, in some cases, violate 617 various conventions or expectations. 619 Receivers sometimes need to deliver email messages that do not 620 conform to any standard or protocol, but are otherwise desired by end 621 users. Mitigating the impact of DMARC on indirect email flows is 622 especially important to receivers that operate services where ease of 623 use and compatibility with existing email flows is a priority. 625 DMARC provides a mechanism (local policy) for receivers to make 626 decisions about identity alignment acceptability based on information 627 outside DMARC and communicate those decisions as "overrides" to the 628 sender. This facility can be used to ease some interoperability 629 issues, although care is needed to ensure that this does not create 630 loopholes for abuse. 632 To further complicate the usage of mitigations, mitigation may not be 633 desired if the email in question is of a certain category of high 634 value or high risk (security-related) transactional messages (dealing 635 with financial transactions or medical records, for example). In 636 these cases, mitigating the impact of DMARC due to indirect email 637 flows may not be desirable (counter-productive, or allowing for 638 abuse). 640 As a final note, mail systems are diverse and widely deployed. 641 Systems of various ages and capabilities are expected to preserve 642 interoperability with the rest of the SMTP ecosystem. For instance, 643 Qmail is still used and the base code has not been updated since 644 1998. Ezmlm, a once popular mailing list manager, is still deployed 645 and has not been updated since 1997, although a new version, Ezmlm- 646 idx exists. Old versions of other open and closed source MTAs are 647 still commonly in operation. When dealing with aging or unsupported 648 systems, some solutions may be time-consuming and/or disruptive to 649 implement. 651 4.1. Mitigations in Current Use 653 Because DMARC is already widely deployed, many operators already have 654 mitigations in use. These mitigations vary in their effectiveness 655 and side effects, but have the advantage that they are currently 656 available. 658 4.1.1. Mitigations for Senders 659 4.1.1.1. Identifier Alignment 661 o MTAs handling multiple domains may choose to change 662 RFC5321.MailFrom to align with RFC5322.From to improve SPF 663 usability for DMARC. 665 o MTAs handling multiple domains may also choose to align 666 RFC5321.HELO/EHLO to RFC5322.From, particularly when sending 667 bounce messages. Dynamically adjusting the RFC5321.HELO based on 668 the RFC5322.From may not be possible for some MTA software. 670 o MTAs may choose to DKIM sign bounces with an aligned domain to 671 allow DKIM-based DMARC pass. 673 o MTAs sending email on behalf of multiple domains may require 674 Domain Owners to provide DKIM keys to use DKIM to avoid SPF 675 alignment issues. Managing DKIM keys with a third party has 676 security risks which should be carefully managed. 678 o Senders who are sending on behalf of users in other Administrative 679 Domains may choose to use an RFC5322.From under the sender's 680 control. The new From can be either a forwarding address in a 681 domain controlled by the Sender, or a placeholder address, with 682 the original user's address in a RFC5322.Reply-to header field. 683 However, performing this modification may cause the recipient's 684 MUA to deviate from customary behavior. 686 o Senders can use domains with distinct DMARC policies for email 687 sent directly and email known to use indirect mail flows. 688 However, for known brands, all active domains are likely to be 689 targeted equally by abusers. 691 4.1.1.2. Message Modification 693 o Senders can maximize survivability of DKIM signatures by limiting 694 the header fields they sign and using relaxed canonicalization. 695 Using the DKIM length tag to allow appended signatures is 696 discouraged due to the security risk created by allowing arbitrary 697 content to be appended to legitimate email. 699 o Senders can also maximize survivability by starting with RFC- 700 compliant headers and common body formats. 702 o In order to minimize transport-based conversions, Senders can 703 convert messages to a lowest denominator MIME content-transfer 704 encoding such as quoted-printable or base64 before signing 705 ([RFC6376] Section 5.3). 707 4.1.2. Mitigations for Receivers 709 4.1.2.1. Identifier Alignment 711 o Receivers should update DKIM handling libraries to ensure that 712 they process all valid DKIM signatures and check each signature 713 for alignment. 715 4.1.2.2. Policy Override 717 o Receivers can amalgamate data from their user base to create lists 718 of forwarders and use such lists to inform DMARC local policy 719 overrides. This process may be easier for large receivers where 720 data and resources to create such lists are more readily available 721 than at smaller sites where the recipient footprint and other 722 resources may be scarce. 724 4.1.3. Mitigations for ReSenders 726 4.1.3.1. Changes to the RFC5322.From 728 Many ReSender issues can be avoided by using an RFC5322.From header 729 field under the ReSender's control, instead of the initial 730 RFC5322.From. This will correct identifier alignment issues and 731 allow arbitrary message modification as long as the ReSender signs 732 the message with an aligned domain signature. When ReSenders change 733 the RFC5322.From, it is desirable to preserve the information about 734 the original initiator of the message. 736 A first option is to use the Original-From [RFC5703] (or X-Original- 737 From) header field for this purpose in various contexts (X- header 738 fields name are discouraged by [RFC6648]). However, handling of 739 Original-From (or X-Original-From) is not defined anywhere. It is 740 not currently used consistently or displayed to the user, and in any 741 situation where it is used, it is a new unauthenticated identifier 742 available for exploitation unless included within the scope of the 743 new DKIM signature(s). 745 Another option for ReSenders is to rewrite the RFC5322.From header 746 field address to a locally controlled address which will be forwarded 747 back to the original sender (subject to its own ReSender forwarding 748 mitigations!). 750 4.1.3.2. Avoiding Message Modification 752 o Forwarders can choose to add email header fields instead of 753 modifying existing headers or bodies, for instance to indicate a 754 message may be spam. 756 o Forwarders can minimize the circumstances in which they choose to 757 fix messages, preferring to preserve non-compliant headers to 758 creating DKIM failures. 760 o Forwarders can choose to reject messages with suspect or harmful 761 content instead of modifying them. 763 4.1.3.3. Mailing Lists 765 [RFC6377] provides some guidance on using DKIM with Mailing lists. 766 The following mitigation techniques can be used to ease 767 interoperability issues with DMARC and Mailing lists: 769 o Configuring the Mailing List Manager (MLM) to alter the 770 RFC5322.From header field to use the domain of the MLM is a 771 mitigation policy which is now present in several different 772 Mailing List software distributions. Since most list subscribers 773 prefer to know the identity of the author of the original message, 774 typically this information may be provided in the display name 775 part of the RFC5322.From header field. This display name needs to 776 be carefully crafted as to not collide with the original display 777 name of the author, nor contain something that looks like an email 778 address or domain name. These modifications may to some extent 779 defeat the purpose of DMARC itself. It may make it difficult to 780 ensure that users of all email clients can easily reply to the 781 author, the list, or all using the email client features provided 782 for that purpose. Use of RFC5322.Reply-To header field can 783 alleviate this problem depending on whether the mailing list is 784 configured to reply-to-list, reply-to-author or reply-to-fixed- 785 address, however it is important to note that this header field 786 can take multiple email addresses. When altering the RFC5322.From 787 there are three possibilities: 789 1. change it to put the mailing list email address, 791 2. change it to a locally-defined address which will be forwarded 792 back to the original sender, or 794 3. "break" the address by modifying the domain to a non-existent 795 domain (such as by adding a suffix like ".invalid".) 797 The later modification may create issues because it is an invalid 798 domain name, and some MTAs may pay particular attention to the 799 validity of email addresses in RFC5322.From and the reputation of 800 the domains present there. 802 o Another mitigation policy is to configure the MLM to "wrap" the 803 message in a MIME message/rfc822 part and to send as the Mailing 804 List email address. Many email clients (as of August 2015), 805 especially mobile clients, have difficulty reading such messages 806 and this is not expected to change soon. 808 o Another mitigation policy, is to configure the MLM to not modify 809 the message so that the DKIM signature remains valid. Some 810 Mailing Lists are set up this way and require few additional 811 changes to ensure the DKIM signature is preserved. Moving lists 812 that currently modify mail to a policy like this, may be too much 813 of a change for the members of such lists. 815 o Another mitigation policy, is to reject posts or membership 816 requests from domains with a DMARC policy other than p=none. 817 However members or potential members of such Mailing Lists may 818 complain of unfair exclusion. 820 o To alleviate unsubscribes to the Mailing List due to the messages 821 bouncing because of DMARC, the MLM needs to not act on bounces due 822 to Message Authentication issues. [RFC3463] specifies Enhanced 823 Mail System Status Codes which help differentiate between various 824 bounces. Correctly interpreting Extended SMTP error messages is 825 useful in this case. In particular, extended status codes are 826 defined in [RFC7372] and in DMARC [RFC7489]. 828 All these techniques may provide some specific challenges to MUAs and 829 different operational usages for end users (like rewriting filters to 830 sort emails in folders). There will be some time before all 831 implications are understood and adjusted to. 833 4.2. Proposed and In-Progress Mitigations 835 The following mitigations are based on Internet Drafts which have not 836 yet received broad consensus. They are described here to offer 837 exploratory path for solutions. These solutions should not be used 838 in a production environment. 840 o Third party authorization, [RFC6541], [I-D.otis-tpa-label] and 841 [I-D.kucherawy-dkim-delegate] provide ways to extend identifier 842 alignment under the control of the domain owner. 844 o DKIM with constrained transformations, 845 [I-D.kucherawy-dkim-list-canon] is proposed to allow message 846 modification. 848 o DKIM with recorded transformations, [I-D.kucherawy-dkim-transform] 849 is proposed to indicate what limited transformations were done to 850 the message so that a receiver could reverse them and confirm the 851 validity of the orignal DKIM signature. 853 o [I-D.kucherawy-original-authres] is intended as a way to pass 854 along Original Authentication Results to "downstream" receivers. 855 It is not widely implemented and relies on a trust relationship 856 between the forwarder and the other receivers. 858 o [I-D.levine-dkim-conditional] could be used to have the sender add 859 a limited DKIM signature, that signs only a very limited set of 860 header fields and not the body of the message. This DKIM 861 signature would come with the condition that a subsequent known 862 domain fully DKIM sign the message. For instance a Mailing List 863 could transform the message, add its DKIM signature and there 864 would be a valid DKIM signature aligned with the RFC5322.From that 865 would satisfy DMARC while limiting the possibilities of replay 866 attack. 868 4.2.1. Getting More Radical: Requiring New Communication Paths Between 869 MUAs 871 In practice a number of operators are using strict alignment mode in 872 DMARC in order to avoid receiving new and innovative forms of 873 unwanted and unauthentic email through systems purporting to be 874 mailing list handlers. The receiving ADMD has no knowledge of which 875 lists the user has subscribed to and which they have not. One avenue 876 of exploration would be for the user to authorize mailing lists as 877 proxies for authentication, at which point the receiving ADMD would 878 be vesting some trust in the mailing list service. The creators of 879 DKIM foresaw precisely this possibility at the time by not tightly 880 binding any semantics to the RFC5322.From header field. Some 881 experimental work has taken place in this area, as mentioned above. 882 Additional work might examine a new communication path to the user to 883 authorize some form of transitive trust. 885 5. IANA Considerations 887 This document contains no actions for IANA. [RFC Editor: Please 888 delete this section prior to publication.] 890 6. Security Considerations 892 This document is an analysis of DMARC's impact on indirect email 893 flows. It describes the possibility of accidental denial-of-service 894 that can be created by rejections of messages by DMARC-aware Mail 895 Receivers. However, it introduces no new security issues to Internet 896 messaging. 898 7. Acknowledgments 900 Miles Fidelman, John Levine, David Crocker, Stephen J. Turnbull, 901 Rolf E. Sonneveld, Tim Draegen and Franck Martin contributed to the 902 IETF DMARC Working Group's wiki page listing all known 903 interoperability issues with DMARC and indirect email flows. 905 Tim Draegen created the first draft of this document from these 906 contributions and by hamfistedly mapping contributions into the 907 language of [RFC5598]. 909 8. References 911 8.1. Normative References 913 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 914 Extensions (MIME) Part One: Format of Internet Message 915 Bodies", RFC 2045, November 1996. 917 [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 918 3463, January 2003. 920 [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 921 for Authorizing Use of Domains in E-Mail, Version 1", RFC 922 4408, April 2006. 924 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 925 Language", RFC 5228, January 2008. 927 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 928 October 2008. 930 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 931 October 2008. 933 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 934 2009. 936 [RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part 937 Tests, Iteration, Extraction, Replacement, and Enclosure", 938 RFC 5703, October 2009. 940 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 941 Identified Mail (DKIM) Signatures", STD 76, RFC 6376, 942 September 2011. 944 [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and 945 Mailing Lists", BCP 167, RFC 6377, September 2011. 947 [RFC6541] Kucherawy, M., "DomainKeys Identified Mail (DKIM) 948 Authorized Third-Party Signatures", RFC 6541, February 949 2012. 951 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, 952 "Deprecating the "X-" Prefix and Similar Constructs in 953 Application Protocols", BCP 178, RFC 6648, June 2012. 955 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 956 Authorizing Use of Domains in Email, Version 1", RFC 7208, 957 April 2014. 959 [RFC7372] Kucherawy, M., "Email Authentication Status Codes", RFC 960 7372, September 2014. 962 8.2. Informative References 964 [I-D.kucherawy-dkim-delegate] 965 Kucherawy, M. and D. Crocker, "Delegating DKIM Signing 966 Authority", draft-kucherawy-dkim-delegate-01 (work in 967 progress), June 2014. 969 [I-D.kucherawy-dkim-list-canon] 970 Kucherawy, M., "A List-safe Canonicalization for 971 DomainKeys Identified Mail (DKIM)", draft-kucherawy-dkim- 972 list-canon-00 (work in progress), June 2014. 974 [I-D.kucherawy-dkim-transform] 975 Kucherawy, M., "Recognized Transformations of Messages 976 Bearing DomainKeys Identified Mail (DKIM) Signatures", 977 draft-kucherawy-dkim-transform-00 (work in progress), 978 April 2015. 980 [I-D.kucherawy-original-authres] 981 Chew, M. and M. Kucherawy, "Original-Authentication- 982 Results Header Field", draft-kucherawy-original-authres-00 983 (work in progress), February 2012. 985 [I-D.levine-dkim-conditional] 986 Levine, J., "DKIM Conditional Signatures", draft-levine- 987 dkim-conditional-00 (work in progress), June 2014. 989 [I-D.otis-tpa-label] 990 Otis, D. and D. Black, "Third-Party Authorization Label", 991 draft-otis-tpa-label-00 (work in progress), May 2014. 993 [RFC7489] Kucherawy, M. and E. Zwicky, "Domain-based Message 994 Authentication, Reporting, and Conformance (DMARC)", RFC 995 7489, March 2015. 997 Authors' Addresses 999 Franck Martin (editor) 1000 LinkedIn 1001 Mountain View, CA 1002 USA 1004 Email: fmartin@linkedin.com 1006 Eliot Lear (editor) 1007 Cisco Systems GmbH 1008 Richtistrasse 7 1009 Wallisellen, ZH CH-8304 1010 Switzerland 1012 Phone: +41 44 878 9200 1013 Email: lear@cisco.com 1015 Tim Draegen (editor) 1016 dmarcian, inc. 1017 PO Box 1007 1018 Brevard, NC 28712 1019 USA 1021 Email: tim@dmarcian.com 1023 Elizabeth Zwicky (editor) 1024 Yahoo 1025 Sunnyvale, CA 1026 USA 1028 Email: zwicky@yahoo-inc.com 1030 Kurt Andersen (editor) 1031 LinkedIn 1032 2029 Stierlin Court 1033 Mt. View, CA 94043 1034 USA 1036 Email: kandersen@linkedin.com