--- 1/draft-ietf-dmarc-interoperability-07.txt 2015-10-19 13:15:24.397821055 -0700 +++ 2/draft-ietf-dmarc-interoperability-08.txt 2015-10-19 13:15:24.445822228 -0700 @@ -1,25 +1,25 @@ DMARC F. Martin, Ed. Internet-Draft LinkedIn Intended status: Informational E. Lear, Ed. -Expires: March 31, 2016 Cisco Systems GmbH +Expires: April 21, 2016 Cisco Systems GmbH T. Draegen, Ed. dmarcian, inc. E. Zwicky, Ed. Yahoo K. Andersen, Ed. LinkedIn - September 28, 2015 + October 19, 2015 Interoperability Issues Between DMARC and Indirect Email Flows - draft-ietf-dmarc-interoperability-07 + draft-ietf-dmarc-interoperability-08 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 issues between DMARC and indirect email flows. Possible methods for @@ -33,21 +33,21 @@ 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 March 31, 2016. + This Internet-Draft will expire on April 21, 2016. Copyright Notice Copyright (c) 2015 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 @@ -76,52 +76,52 @@ 3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 10 3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 11 3.2.3.1. Mailing List Operational Effects . . . . . . . . 11 3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 12 3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 12 3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 13 4. Possible Mitigations of Interoperability Issues . . . . . . . 13 4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 14 - 4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 14 + 4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 15 4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 15 4.1.1.2. Message Modification . . . . . . . . . . . . . . 15 4.1.2. Mitigations for Receivers . . . . . . . . . . . . . . 16 4.1.2.1. Identifier Alignment . . . . . . . . . . . . . . 16 4.1.2.2. Policy Override . . . . . . . . . . . . . . . . . 16 4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 16 4.1.3.1. Changes to the RFC5322.From . . . . . . . . . . . 16 4.1.3.2. Avoiding Message Modification . . . . . . . . . . 17 4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 17 4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 18 4.2.1. Getting More Radical: Requiring New Communication Paths Between MUAs . . . . . . . . . . . . . . . . . 19 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 - 8.2. Informative References . . . . . . . . . . . . . . . . . 21 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 + 8.2. Informative References . . . . . . . . . . . . . . . . . 22 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 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. At the time of the writing of this document, the DMARC base - specification is published as an Informational RFC and has seen - significant deployment within the email community. + specification is published as Informational RFC7489 [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 for a select subset of general email traffic. Several known causes of interoperability issues are presented, followed by a description of components within the Internet Mail @@ -568,20 +568,23 @@ modifications would invalidate a DKIM signature. o Spam filtering: To protect reputation and assist other MTAs, an MTA may modify a message to indicate its decision that the message is likely to be unwanted, and/or add text in the body to indicate that such filtering has been done. o Other text additions: An MTA may add an organizational disclaimer or advertisement, for instance. + o URL alteration: Some systems will rewrite or alter embedded URLs + as a way to control the potential threat form malware. + o Secondary MX services: The secondary MX for an organization may be external to the normal mail processing for the organization, and queue and forward to the primary when it becomes available. This will not invalidate DKIM but will prevent the primary from validating SPF normally. In this case, however, it is inappropriate for a primary MX server to perform an SPF check against its own secondaries. Rather, the secondary MX should perform this function and employ some trusted mechanism to communicate the results of the SPF, DKIM and DMARC evaluation(s) to the primary MX server. @@ -855,20 +859,28 @@ o [I-D.levine-dkim-conditional] could be used to have the sender add a limited DKIM signature, that signs only a very limited set of header fields and not the body of the message. This DKIM signature would come with the condition that a subsequent known domain fully DKIM sign the message. For instance a Mailing List could transform the message, add its DKIM signature and there would be a valid DKIM signature aligned with the RFC5322.From that would satisfy DMARC while limiting the possibilities of replay attack. + o [I-D.andersen-arc] (and the accompanying usage recommendations + [I-D.jones-arc-usage]) provides a proposed mechanism to provide an + authenticated channel for the initial received authentication + results to be conveyed through multiple ReSenders + ("intermediaries" in the terminology used in the draft) to the + ultimate receiving system. This information is proposed as the + basis for improved local policy decisions by the receiver. + 4.2.1. Getting More Radical: Requiring New Communication Paths Between MUAs In practice a number of operators are using strict alignment mode in DMARC in order to avoid receiving new and innovative forms of unwanted and unauthentic email through systems purporting to be mailing list handlers. The receiving ADMD has no knowledge of which lists the user has subscribed to and which they have not. One avenue of exploration would be for the user to authorize mailing lists as proxies for authentication, at which point the receiving ADMD would @@ -908,65 +920,90 @@ Tim Draegen created the first draft of this document from these contributions and by hamfistedly mapping contributions into the language of [RFC5598]. 8. References 8.1. Normative References [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message - Bodies", RFC 2045, November 1996. + Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, + . [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC - 3463, January 2003. + 3463, DOI 10.17487/RFC3463, January 2003, + . - [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering - Language", RFC 5228, January 2008. + [RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email + Filtering Language", RFC 5228, DOI 10.17487/RFC5228, + January 2008, . [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, - October 2008. + DOI 10.17487/RFC5321, October 2008, + . - [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, - October 2008. + [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI + 10.17487/RFC5322, October 2008, + . - [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July - 2009. + [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI + 10.17487/RFC5598, July 2009, + . [RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure", - RFC 5703, October 2009. + RFC 5703, DOI 10.17487/RFC5703, October 2009, + . - [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys - Identified Mail (DKIM) Signatures", STD 76, RFC 6376, - September 2011. + [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., + "DomainKeys Identified Mail (DKIM) Signatures", STD 76, + RFC 6376, DOI 10.17487/RFC6376, September 2011, + . [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and - Mailing Lists", BCP 167, RFC 6377, September 2011. + Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377, + September 2011, . [RFC6541] Kucherawy, M., "DomainKeys Identified Mail (DKIM) - Authorized Third-Party Signatures", RFC 6541, February - 2012. + Authorized Third-Party Signatures", RFC 6541, DOI + 10.17487/RFC6541, February 2012, + . [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in - Application Protocols", BCP 178, RFC 6648, June 2012. + Application Protocols", BCP 178, RFC 6648, DOI 10.17487/ + RFC6648, June 2012, + . [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, - April 2014. + DOI 10.17487/RFC7208, April 2014, + . [RFC7372] Kucherawy, M., "Email Authentication Status Codes", RFC - 7372, September 2014. + 7372, DOI 10.17487/RFC7372, September 2014, + . 8.2. Informative References + [I-D.andersen-arc] + None, N., Andersen, K., JohnRG, J., Long, B., Adams, J., + and S. Jones, "Authenticated Received Chain (ARC)", draft- + andersen-arc-00 (work in progress), October 2015. + + [I-D.jones-arc-usage] + None, N., Jones, S., JohnRG, J., Adams, J., and K. + Andersen, "Recommended Usage of the Authenticated Received + Chain (ARC)", draft-jones-arc-usage-00 (work in progress), + October 2015. + [I-D.kucherawy-dkim-delegate] Kucherawy, M. and D. Crocker, "Delegating DKIM Signing Authority", draft-kucherawy-dkim-delegate-01 (work in progress), June 2014. [I-D.kucherawy-dkim-list-canon] Kucherawy, M., "A List-safe Canonicalization for DomainKeys Identified Mail (DKIM)", draft-kucherawy-dkim- list-canon-00 (work in progress), June 2014. @@ -982,23 +1019,24 @@ (work in progress), February 2012. [I-D.levine-dkim-conditional] Levine, J., "DKIM Conditional Signatures", draft-levine- dkim-conditional-00 (work in progress), June 2014. [I-D.otis-tpa-label] Otis, D. and D. Black, "Third-Party Authorization Label", draft-otis-tpa-label-00 (work in progress), May 2014. - [RFC7489] Kucherawy, M. and E. Zwicky, "Domain-based Message - Authentication, Reporting, and Conformance (DMARC)", RFC - 7489, March 2015. + [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based + Message Authentication, Reporting, and Conformance + (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, + . Authors' Addresses Franck Martin (editor) LinkedIn Mountain View, CA USA Email: fmartin@linkedin.com