--- 1/draft-ietf-dmarc-interoperability-16.txt 2016-06-21 22:15:56.578905955 -0700 +++ 2/draft-ietf-dmarc-interoperability-17.txt 2016-06-21 22:15:56.630907256 -0700 @@ -1,53 +1,55 @@ DMARC F. Martin, Ed. Internet-Draft LinkedIn Intended status: Informational E. Lear, Ed. -Expires: December 10, 2016 Cisco Systems GmbH +Expires: December 23, 2016 Cisco Systems GmbH T. Draegen, Ed. dmarcian, inc. E. Zwicky, Ed. Yahoo K. Andersen, Ed. LinkedIn - June 8, 2016 + June 21, 2016 Interoperability Issues Between DMARC and Indirect Email Flows - draft-ietf-dmarc-interoperability-16 + draft-ietf-dmarc-interoperability-17 Abstract - DMARC introduces a mechanism for expressing domain-level policies and - preferences for email message validation, disposition, and reporting. - The DMARC mechanism can encounter interoperability issues when - messages do not flow directly from the author's administrative domain - to the final recipients. Collectively these email flows are referred - to as indirect email flows. This document describes interoperability + DMARC (Domain-based Message Authentication, Reporting, and + Conformance) introduces a mechanism for expressing domain-level + policies and preferences for email message validation, disposition, + and reporting. The use of restrictive policies through the DMARC + framework can cause interoperability issues when messages do not flow + directly from the author's administrative domain to the final + recipients. Collectively these email flows are referred to as + indirect email flows. This document describes interoperability issues between DMARC and indirect email flows. Possible methods for addressing interoperability issues are presented. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 10, 2016. + This Internet-Draft will expire on December 23, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -62,68 +64,69 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Document Conventions . . . . . . . . . . . . . . . . . . 4 2. Causes of Interoperability Issues . . . . . . . . . . . . . . 4 2.1. Identifier Alignment . . . . . . . . . . . . . . . . . . 4 2.1.1. DKIM Identifier(s) . . . . . . . . . . . . . . . . . 5 2.1.2. SPF Identifier(s) . . . . . . . . . . . . . . . . . . 5 2.1.3. Multiple RFC5322.From Addresses . . . . . . . . . . . 6 2.2. Message Forwarding . . . . . . . . . . . . . . . . . . . 6 2.3. Message Modification . . . . . . . . . . . . . . . . . . 7 3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 7 - 3.1. Message Handling System . . . . . . . . . . . . . . . . . 7 + 3.1. Message Handling System . . . . . . . . . . . . . . . . . 8 3.1.1. Message Submission Agents . . . . . . . . . . . . . . 8 3.1.2. Message Transfer Agents . . . . . . . . . . . . . . . 9 3.1.2.1. Message Encoding . . . . . . . . . . . . . . . . 9 - 3.1.2.2. Header Standardization . . . . . . . . . . . . . 9 + 3.1.2.2. Header Standardization . . . . . . . . . . . . . 10 3.1.2.3. Content Validation . . . . . . . . . . . . . . . 10 3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 10 3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 11 - 3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 11 + 3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 12 3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 12 - 3.2.3.1. Mailing List Operational Effects . . . . . . . . 12 + 3.2.3.1. Mailing List Operational Effects . . . . . . . . 13 3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 13 - 3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 13 - 3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 14 - 4. Possible Mitigations of Interoperability Issues . . . . . . . 14 - 4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 15 - 4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 15 + 3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 14 + 3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 15 + 4. Possible Mitigations of Interoperability Issues . . . . . . . 15 + 4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 16 + 4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 16 4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 16 - 4.1.1.2. Message Modification . . . . . . . . . . . . . . 16 + 4.1.1.2. Message Modification . . . . . . . . . . . . . . 17 4.1.2. Mitigations for Receivers . . . . . . . . . . . . . . 17 4.1.2.1. Identifier Alignment . . . . . . . . . . . . . . 17 4.1.2.2. Policy Override . . . . . . . . . . . . . . . . . 17 4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 17 - 4.1.3.1. Changes to the RFC5322.From . . . . . . . . . . . 17 + 4.1.3.1. Changes to the RFC5322.From . . . . . . . . . . . 18 4.1.3.2. Avoiding Message Modification . . . . . . . . . . 18 4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 18 - 4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 19 + 4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 20 4.2.1. Getting More Radical: Requiring New Communication Paths Between MUAs . . . . . . . . . . . . . . . . . 20 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 - 8.2. Informative References . . . . . . . . . . . . . . . . . 22 - Appendix A. Appendix A - Example SPF Bounce . . . . . . . . . . 22 + 8.2. Informative References . . . . . . . . . . . . . . . . . 23 + Appendix A. Appendix A - Example SPF Bounce . . . . . . . . . . 23 A.1. Initial Message . . . . . . . . . . . . . . . . . . . . . 23 A.2. Notification message . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction DMARC [RFC7489] introduces a mechanism for expressing domain-level policies and preferences for message validation, disposition, and - reporting. The DMARC mechanism can encounter several different types - of interoperability issues due to third-party message sourcing, - message transformation, or rerouting. + reporting. The DMARC mechanism, especially when employed with + restrictive policies, encounters several different types of + interoperability issues due to third-party message sourcing, message + transformation, or rerouting. At the time of the writing of this document, the DMARC base specification is published as Informational RFC 7489 [RFC7489] and has seen significant deployment within the email community. Cases in which email does not flow directly from the author's administrative domain to the recipient's domain(s) are collectively referred to in this document as indirect email flows. Due to existing and increasing adoption of DMARC, the impact of DMARC-based email rejection policies on indirect email flows can be significant @@ -391,22 +395,25 @@ o Email service providers - ESPs that service customers who are using domains that publish a DMARC "reject" policy. o Calendaring software - an invited member of an event modifies the event causing calendaring software to emit an update that claims to come from the creator of the event. 3.1.2. Message Transfer Agents - MTAs relay a message until the message reaches a destination MDA. As - such, they are in a position to introduce interoperability problems. + MTAs relay a message until the message reaches a destination MDA. + Some common message handling strategies break the integrity of DKIM + signatures. A restrictive DMARC policy along with a broken DKIM + signature causes latent interoperability problems to become overt + problems. 3.1.2.1. Message Encoding An MTA may modify the message encoding, for instance by converting 8-bit MIME sections to quoted-printable 7-bit sections. This modification is outside the scope of DKIM canonicalization and will invalidate DKIM signatures that include message content. An MTA could also re-encode the message without changing the encoding type, receiving a MIME-encoded message and producing a semantically @@ -740,22 +748,22 @@ However, performing this modification may cause the recipient's MUA to deviate from customary behavior. o When implementing "forward-to-friend" functionality, one approach to avoid DMARC failures is to pass a well-formed message to the user's MUA so that it may fill in an appropriate identity and submit through its own MSA. o Senders can use domains with distinct DMARC policies for email sent directly and email known to use indirect mail flows. - However, for known brands, all active domains are likely to be - targeted equally by abusers. + However, for most well-known brands, all active domains are likely + to be targeted equally by abusers. 4.1.1.2. Message Modification o Senders can maximize survivability of DKIM signatures by limiting the header fields they sign and using relaxed canonicalization. Using the DKIM length tag to allow appended signatures is discouraged due to the security risk created by allowing arbitrary content to be appended to legitimate email. o Senders can also maximize survivability by starting with RFC- @@ -946,22 +954,22 @@ 6. Security Considerations This document is an analysis of DMARC's impact on indirect email flows. It describes the possibility of accidental denial-of-service that can be created by rejections of messages by DMARC-aware Mail Receivers. Section 4.1.1.1 discusses the importance of appropriate DKIM key management vis-a-vis third-party email senders. - Section 4.1.3.3 warns that rewriting the RFC5322.From header field - and changing the domain name should not be done with any domain. + Section 4.1.3.3 warns that rewriting the RFC5322.From header field to + create an artificial domain name should not be done with any domain. 7. Acknowledgments Miles Fidelman, John Levine, David Crocker, Stephen J. Turnbull, Rolf E. Sonneveld, Tim Draegen, and Franck Martin contributed to the IETF DMARC Working Group's wiki page listing all known interoperability issues with DMARC and indirect email flows. Tim Draegen created the first draft of this document from these contributions and by hamfistedly mapping contributions into the