--- 1/draft-ietf-dmarc-interoperability-05.txt 2015-08-28 18:14:56.163744728 -0700 +++ 2/draft-ietf-dmarc-interoperability-06.txt 2015-08-28 18:14:56.207745775 -0700 @@ -1,25 +1,25 @@ DMARC F. Martin, Ed. Internet-Draft LinkedIn Intended status: Informational E. Lear, Ed. -Expires: February 18, 2016 Cisco Systems GmbH +Expires: February 29, 2016 Cisco Systems GmbH T. Draegen, Ed. dmarcian, inc. E. Zwicky, Ed. Yahoo K. Andersen, Ed. LinkedIn - August 17, 2015 + August 28, 2015 Interoperability Issues Between DMARC and Indirect Email Flows - draft-ietf-dmarc-interoperability-05 + draft-ietf-dmarc-interoperability-06 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 February 18, 2016. + This Internet-Draft will expire on February 29, 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 @@ -59,29 +59,29 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Document Conventions . . . . . . . . . . . . . . . . . . 4 2. Causes of Interoperability Issues . . . . . . . . . . . . . . 4 2.1. Identifier Alignment . . . . . . . . . . . . . . . . . . 4 2.2. Message Forwarding . . . . . . . . . . . . . . . . . . . 5 2.3. Message Modification . . . . . . . . . . . . . . . . . . 6 3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 6 - 3.1. Message Handling System . . . . . . . . . . . . . . . . . 7 + 3.1. Message Handling System . . . . . . . . . . . . . . . . . 6 3.1.1. Message Submission Agents . . . . . . . . . . . . . . 7 3.1.2. Message Transfer Agents . . . . . . . . . . . . . . . 8 3.1.2.1. Message Encoding . . . . . . . . . . . . . . . . 8 3.1.2.2. Header Standardization . . . . . . . . . . . . . 8 3.1.2.3. Content Validation . . . . . . . . . . . . . . . 9 3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 9 3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 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.1. Identifier Alignment . . . . . . . . . . . . . . 15 @@ -113,22 +113,22 @@ 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. 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 email flows can be significant for a - select subset of general email traffic. + 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 Architecture [RFC5598] where interoperability issues can arise. Finally, known and possible methods for addressing interoperability issues are presented. There are often multiple ways to address any given interoperability issue. While this document strives to be comprehensive in its review, it should not be treated as complete. Also, some practices which are in use at the time of this document @@ -189,58 +189,51 @@ In addition, DKIM allows for the possibility of multiple valid signatures. The DMARC mechanism will process Authenticated Identifiers that are based on DKIM signatures until an aligned Authenticated Identifier is found (if any). However, operational experience has shown that some implementations have difficulty processing multiple signatures. The impact on DMARC processing is clear: implementations that cannot process multiple DKIM signatures may incorrectly flag messages as "failing DMARC" and erroneously apply DMARC based policy to otherwise conforming messages. - SPF can provide two Authenticated Identifiers. The first one is the - RFC7208.HELO [RFC7208] based on the RFC5321.HELO/EHLO. The second - one is the RFC7208.MAILFROM [RFC7208] based on the RFC5321.MailFrom - [RFC5321] domain, or, if the RFC5321.MailFrom address is absent (as - in the case of "bounce" messages, on the domain found in the HELO/ - EHLO SMTP command. DMARC uses only the SPF results for the - RFC7208.MAILFROM identifier for alignment (this is often true for - local policies outside of DMARC as well). The SPF validated domain - in RFC7208.MAILFROM must be part of the same Organizational Domain as - the domain in the RFC5322.From header field to be aligned. It is - important to note that even when an SPF record exists for the domain - in RFC5322.From, SPF will not authenticate it unless it is also the - domain which the SPF analysis has checked. Also note that - RFC7208.MAILFROM definition is different from RFC5321.MailFrom - [RFC5321] definition. The RFC7208.MAILFROM definition has not - changed from the RFC4408.MAILFROM [RFC4408] definition, the earlier - version of the SPF specification, however, not all implementations - have updated to the [RFC7208] algorithm which can lead to unexpected - results. + SPF can provide two Authenticated Identifiers. The DMARC relevant + Authenticated Identifiers that SPF provides is the RFC7208.MAILFROM + [RFC7208] based on the RFC5321.MailFrom [RFC5321] domain, or, if the + RFC5321.MailFrom address is absent (as in the case of "bounce" + messages, on the domain found in the RFC5321.HELO/EHLO SMTP command. + The SPF validated domain in RFC7208.MAILFROM must be part of the same + Organizational Domain as the domain in the RFC5322.From header field + to be aligned. It is important to note that even when an SPF record + exists for the domain in RFC5322.From, SPF will not authenticate it + unless it is also the domain which the SPF analysis has checked. + Also note that RFC7208.MAILFROM definition is different from + RFC5321.MailFrom [RFC5321] definition. 2.2. Message Forwarding Message forwarding is a generic concept encapsulating a variety of behaviors. Section 3 describes forwarding behavior as it relates to the components of the Internet Mail Architecture. All forwarding behavior involves the retransmission of email. As discussed above, in order for SPF to yield an Authenticated Identifier that is pertinent to DMARC, the domain of the RFC7208.MAILFROM must be in alignment with the RFC5322.From header field. Forwarding introduces specific issues to the availability of SPF-based Authenticated Identifiers: o If the RFC5321.MailFrom is present and the forwarder maintains the original RFC5321.MailFrom, SPF validation will fail unless the forwarder is an authorized part of the originator's email sending infrastructure. If the forwarder replaces the RFC5321.MailFrom - with its own domain, SPF may pass but Identifier Alignment with + with its own domain, SPF might pass but Identifier Alignment with the RFC5322.From header field will fail. o If the RFC5321.MailFrom is empty (as in the case of Delivery Status Notifications), the RFC5321.Helo domain of the forwarder will likely be in different organizational domain of the RFC5322.From header field. SPF may pass but Identifier Alignment with the RFC5322.From header field fails. In both cases, SPF cannot yield relevant Authenticated Identifiers, and DKIM must be relied upon to produce results that are relevant to @@ -252,21 +245,22 @@ many message forwarding systems modify email content. Mailing list processors are a common example of such systems, but other forwarding systems also make modifications. Although DKIM provides a length flag so that content can be appended without invalidating the signature, in practice, particularly with MIME-encoded [RFC2045] messages, a mailing list processor will do more than simply append content (see Section 5.3 of [RFC5598] for details). Furthermore, the length flag is seldom used due to security issues (see Section 8.2 of [RFC6376] for additional security - considerations). + considerations), therefore, this method is only here mentionned for + completeness. DKIM describes two canonicalizations for use when preparing headers and body for DKIM processing: simple and relaxed. The latter allows for trivial modifications (largely regarding whitespace folding) that maintain the integrity of the content of the email. However, the relaxed canonicalization is more computationally intensive and may not have been preferred in the early deployment of DKIM, leaving some deployments using the less forgiving "simple" canonicalization. While the prevalence is unknown, there are some DKIM checkers which have problems evaluating relaxed canonicalization correctly. @@ -410,20 +403,26 @@ See [RFC5598] for a complete definition of Mediators. Mediators forward messages through a re-posting process. Mediators share some functionality with basic MTA relaying, but have greater flexibility in both addressing and content modifications. DMARC interoperability issues are common within the context of Mediators, which are often used precisely for their ability to modify messages. + The DMARC design does not cope with some Mediator functionality such + as content modifications that invalidate DKIM signatures and Mail + From rewriting to support SPF authentication of resent mail when the + new Recipient receives the message from the Mediator rather than the + initial organization. + 3.2.1. Alias An Alias is a simple re-addressing facility that provides one or more new Internet Mail addresses, rather than a single, internal one. A message continues through the transfer service for delivery to one or more alternative addresses. Aliases can be implemented by mailbox-level forwarding (e.g. through "dot-forwarding") or SIEVE-level forwarding (through the SIEVE 'redirect' action) or other methods. When an Alias preserves message @@ -451,25 +450,20 @@ final recipient, so solutions to Alias-related DMARC failure should not assume such a relationship. 3.2.2. ReSenders ReSenders "splice" a message's addressing information to connect the Author of the original message with the Recipient(s) of the new message. The new Recipient sees the message as being from the original Author, even if the Mediator adds commentary. - ReSenders introduce DMARC interoperability issues as content - modification invalidates DKIM signatures. SPF's ability to grant - authorization via alignment is removed as the new Recipient receives - the message from the Mediator rather than the initial organization. - Without Authenticated Identifiers aligned with the Author's RFC5322.From header field domain, the new Recipient has no way to achieve a passing DMARC evaluation. Examples of ReSenders include MUA-level forwarding by resending a message to a new recipient or by forwarding a message "inline" to a new recipient (this does not include forwarding a message "as an attachment"). An additional example comes in the form of calendaring software that allows a meeting attendee (not the meeting organizer) to modify the content of an invite generating new invitations that @@ -664,23 +658,24 @@ o MTAs handling multiple domains may also choose to align RFC5321.HELO/EHLO to RFC5322.From, particularly when sending bounce messages. Dynamically adjusting the RFC5321.HELO based on the RFC5322.From may not be possible for some MTA software. o MTAs may choose to DKIM sign bounces with an aligned domain to allow DKIM-based DMARC pass. o MTAs sending email on behalf of multiple domains may require - Domain Owners to provide DKIM keys to use DKIM to avoid SPF - alignment issues. Managing DKIM keys with a third party has - security risks which should be carefully managed. + Domain Owners to provide DKIM keys to use DKIM to avoid DMARC + alignment issues with SPF. Managing DKIM keys with a third party + has security risks which should be carefully managed. Methods + involving CNAMEs and/or subdomains may alleviate some risks. o Senders who are sending on behalf of users in other Administrative Domains may choose to use an RFC5322.From under the sender's control. The new From can be either a forwarding address in a domain controlled by the Sender, or a placeholder address, with the original user's address in a RFC5322.Reply-to header field. However, performing this modification may cause the recipient's MUA to deviate from customary behavior. o Senders can use domains with distinct DMARC policies for email @@ -885,22 +880,28 @@ 5. IANA Considerations This document contains no actions for IANA. [RFC Editor: Please delete this section prior to publication.] 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. However, it introduces no new security issues to Internet - messaging. + Receivers. + + In Section 4.1.1.1, it is discussed that DKIM key management with + third party email senders need to be done appropriately. + + In Section 4.1.3.3, it is discussed that rewriting the RFC5322.From + header field and changing the 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 @@ -910,24 +911,20 @@ 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. [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003. - [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) - for Authorizing Use of Domains in E-Mail, Version 1", RFC - 4408, April 2006. - [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July