--- 1/draft-ietf-dmarc-interoperability-01.txt 2015-04-28 17:14:57.326294259 -0700 +++ 2/draft-ietf-dmarc-interoperability-02.txt 2015-04-28 17:14:57.366295229 -0700 @@ -1,52 +1,51 @@ DMARC Working Group F. Martin, Ed. Internet-Draft LinkedIn Intended status: Informational E. Lear, Ed. -Expires: September 21, 2015 Cisco Systems GmbH +Expires: October 30, 2015 Cisco Systems GmbH T. Draegen, Ed. - Eudaemon + Eudaemonic Development LLC E. Zwicky, Ed. Yahoo - March 20, 2015 + April 28, 2015 Interoperability Issues Between DMARC and Indirect Email Flows - draft-ietf-dmarc-interoperability-01 + draft-ietf-dmarc-interoperability-02 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 originate from third party sources, are modified in transit, - or are forwarded enroute to their final destination. 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. + 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 September 21, 2015. + This Internet-Draft will expire on October 30, 2015. 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 @@ -57,180 +56,192 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Document Conventions . . . . . . . . . . . . . . . . . . 3 2. Causes of Interoperability Issues . . . . . . . . . . . . . . 3 2.1. Identifier Alignment . . . . . . . . . . . . . . . . . . 4 2.2. Message Forwarding . . . . . . . . . . . . . . . . . . . 5 2.3. Message Modification . . . . . . . . . . . . . . . . . . 5 - 3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 5 - 3.1. Message Handling System . . . . . . . . . . . . . . . . . 5 + 3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 6 + 3.1. Message Handling System . . . . . . . . . . . . . . . . . 6 3.1.1. Message Submission Agents . . . . . . . . . . . . . . 6 3.1.2. Message Transfer Agents . . . . . . . . . . . . . . . 7 3.1.2.1. Message Encoding . . . . . . . . . . . . . . . . 7 3.1.2.2. Header Standardization . . . . . . . . . . . . . 7 - 3.1.2.3. Email Address Internationalization . . . . . . . 7 + 3.1.2.3. Email Address Internationalization . . . . . . . 8 3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 8 - 3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 9 + 3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 10 3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 10 - 3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 10 + 3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 11 3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 11 - 3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 11 - 4. Possible Solutions to Interoperability Issues . . . . . . . . 12 - 4.1. Identifier Alignment . . . . . . . . . . . . . . . . . . 12 - 4.2. Message Modification . . . . . . . . . . . . . . . . . . 13 - 4.3. Message Forwarding . . . . . . . . . . . . . . . . . . . 14 - 4.3.1. Original-Authentication-Results . . . . . . . . . . . 14 - 4.4. Message Handling Services . . . . . . . . . . . . . . . . 14 - 4.4.1. Message Transfer Agents . . . . . . . . . . . . . . . 14 - 4.4.1.1. Encoding . . . . . . . . . . . . . . . . . . . . 14 - 4.4.1.2. Filters . . . . . . . . . . . . . . . . . . . . . 14 - 4.4.1.3. Email Address Internationalization . . . . . . . 15 - 4.5. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 15 - 4.5.1. Mailing Lists . . . . . . . . . . . . . . . . . . . . 15 - 4.6. Getting More Radical: Requiring New Communication Paths - Between MUA and the Message Store . . . . . . . . . . . . 16 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 - 8.2. Informative References . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 + 3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 12 + 4. Possible Mitigations of Interoperability Issues . . . . . . . 12 + 4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 13 + 4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 13 + 4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 13 + 4.1.1.2. Message Modification . . . . . . . . . . . . . . 13 + 4.1.2. Mitigations for Receivers . . . . . . . . . . . . . . 14 + 4.1.2.1. Identifier Alignment . . . . . . . . . . . . . . 14 + 4.1.2.2. Policy Override . . . . . . . . . . . . . . . . . 14 + 4.1.2.3. Email Address Internationalization . . . . . . . 14 + 4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 14 + 4.1.3.1. Changes to the RFC5322.From . . . . . . . . . . . 14 + 4.1.3.2. Avoiding Message Modification . . . . . . . . . . 15 + 4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 15 + 4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 16 + 4.2.1. Getting More Radical: Requiring New Communication + Paths Between MUAs . . . . . . . . . . . . . . . . . 17 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 + 8.2. Informative References . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction DMARC [RFC7489] introduces a mechanism for expressing domain-level policies and preferences for message validation, disposition, and - reporting. DMARC is used to combat exact-domain phishing, to gain - visibility into email infrastructure, and to provide email egress - controls. Due to wide adoption, the impact of DMARC-based email + reporting. The DMARC mechanism can encounter several different types + of interoperability issues due to third-party message sourcing, + message transformation or rerouting. + + Cases in which email does not flow directly from the author's + administrative domain to the recipients 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 both direct and indirect email flows can be significant. - The DMARC mechanism can encounter several different types of - interoperability issues due to third-party message sourcing, message - transformation or rerouting. These cases in which mail does not go - directly from the author's administrative domain to the recipients - are known collectively as indirect email flows. - - The next section describes interoperability issues between DMARC and - indirect email flows. These issues are first described in the - context of configuration behavior that DMARC requires from underlying - authentication technology, and then described as they appear in - context of the Internet Mail Architecture [RFC5598]. + 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. - Lastly, 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 + Lastly, 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. 1.1. Document Conventions Notation regarding structured fields is taken from [RFC5598]. Organizational Domain and Authenticated Identifiers are specified in DMARC [RFC7489]. 2. Causes of Interoperability Issues - What do we mean by "interoperability issues"? We say that DMARC - introduces interoperability issues or problems, when conformance to - the DMARC specification leads an implementation to reject a message - that is both compliant with the architecture as specified in - [RFC5598] and would have been viewed as legitimate in the eyes of the - intended recipient. Therefore, we can already conclude that DMARC - poses no interoperability problems when legitimate messages properly - validate through its specified processes. The rest of this section - delves into how legitimate messages may get rejected. + Interoperability issues between DMARC and indirect email flows arise + when conformance to the DMARC specification leads an implementation + to apply DMARC based policy to messages that are both compliant with + the architecture as specified in [RFC5598] and viewed as legitimate + by the intended recipient. To be clear, this document does not + address emails considered legitimate by the intended recipient but + which are not conformant to other email specifications. The rest of + this section describes several conceptual causes of interoperability + issues. 2.1. Identifier Alignment - A fundamental aspect of message source validation is understanding - what defines the source that is validated. Each of the underlying - mechanisms that DMARC uses (DKIM [RFC6376] and SPF [RFC7208]) takes a - different approach. Therefore, the DMARC [RFC7489] mechanism - attempts to predictably specify the domain of the originator that - will be used for its purposes (reporting/message disposition). This - step is referred to as Identifier Alignment. + DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform message + source validation. The DMARC [RFC7489] mechanism refers to source + domains that are validated by DKIM or SPF as Authenticated + Identifiers. DMARC requires an Authenticated Identifier to be + relevant to the domain found in the message's RFC5322.From header + field [RFC5322]. This relevancy is referred to as Identifier + Alignment. + + Identifier Alignment can be strict, where the domains exactly match + each others, or relaxed where the domains are part of the same + Organizational Domain. There are, in general, the same + interoperability issues between strict and relaxed alignment, however + in strict mode the possible solutions are more constrained when + possible. This Document mainly implies relaxed Identifier Alignment. DKIM provides a cryptographic means for a domain to be associated with a particular message. DKIM does not make any constraints on what domains may or must present this association. However, for a - DKIM identifier to align in DMARC, the signing domain must be part of - the same Organizational Domain as the domain in the RFC5322.From - header field [RFC5322], and the signature must be valid. + DKIM identifier to align in DMARC, the signing domain of a valid + signature must be part of the same Organizational Domain as the + domain in the RFC5322.From header field [RFC5322]. 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: if an implementation cannot process multiple DKIM signatures - it may lead to perfectly valid messages being flagged as not - authentic. + clear: implementations that cannot process multiple DKIM signatures + may erroneously apply DMARC based policy to otherwise legitimate + messages. - SPF provides two Authenticated Identifiers the first one is - RFC7208.HELO [RFC7208] based on RFC5321.HELO/EHLO and the second one - is RFC7208.MAILFROM [RFC7208] based on the RFC5321.MailFrom - [RFC5321] domain or, if the RFC5321.MailFrom address is absent (as in - the case of "bounces"), on the domain found in the HELO/EHLO SMTP - command. Local policies, as well as DMARC often only use the - RFC7208.MAILFROM identifier. Again, for an SPF identifier to align - in DMARC, the validated domain must be part of the same - Organizational Domain as the domain in the RFC5322.From header field. - Even when an SPF record exists for the domain in RFC5322.From, SPF - will not authenticate it unless it is also the domain SPF checks. - While aligning RFC5322.From and RFC5321.MailFrom is usually possible, - it can be difficult to change the domain in the HELO/EHLO used for - bounces to the domain in the RFC5322.From header field, especially - when several mail streams share the same sending IP address. + SPF can provides two Authenticated Identifiers based on two different + SPF identities: RFC7208.HELO [RFC7208] and RFC7208.MAILFROM + [RFC7208]. DMARC uses only the RFC7208.MAILFROM identifier for + alignment. 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 in RFC7208.MAILFROM, + furthermore, 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 of these behaviors involve mail being retransmitted by a new SMTP - server. As discussed above, for SPF to cause a DMARC pass, the - domain of the RFC5321.MailFrom or RFC5321.HELO/EHLO must be aligned - with that of the RFC5322.From header field. If the forwarder keeps - the RFC5321.MailFrom, the SPF validation will fail altogether unless - the forwarder is an authorized part of the originator's mail sending - infrastructure. If the forwarder uses its own domain in the - RFC5321.MailFrom and/or RFC5321.HELO/EHLO, SPF passes but the - alignment with the RFC5322.From header field fails. In either case, - SPF cannot produce a DMARC pass, and DKIM will be required to get - DMARC to pass. + All of these behaviors involve email being retransmitted by a new + SMTP server. As discussed above, for SPF to cause a DMARC pass, the + domain of the RFC7208.MAILFROM, must be aligned with that of the + RFC5322.From header field: + + o If the RFC5321.MailFrom is not empty and if the forwarder keeps + the RFC5321.MailFrom, the SPF validation will fail altogether + unless the forwarder is an authorized part of the originator's + email sending infrastructure. On another hand, if the forwarder + uses its own domain in the RFC5321.MailFrom, SPF passes but the + alignment with the RFC5322.From header field fails. + + o If the RFC5321.MailFrom is empty, the RFC5321.Helo of the + forwarder will likely be in different organizational domain of the + RFC5322.From. SPF may pass but the alignment with the + RFC5322.From header field fails. + + In either case, SPF cannot produce a DMARC pass, and DKIM will be + required to get DMARC to pass. 2.3. Message Modification - Modification of email content invalidates most DKIM signatures. For - instance while DKIM provides a length flag so that content can be - appended (See Section 8.2 of RFC6376 [RFC6376] for additional - security considerations), in practice, particularly with MIME-encoded - [RFC2045] messages, a mailing list processor will do more than append - (See Section 5.3 of [RFC5598] for details). Even forwarding systems - make content modifications. Furthermore, the use of the length flag - is by no means universal. + Modification of email content invalidates most DKIM signatures, and + many message forwarding systems modify email content. Mailing list + processors are the most common example of such systems, but other + forwarding systems also make modifications. Although DKIM provides a + length flag so that content can be appended (See Section 8.2 of + [RFC6376] for additional security considerations), in practice, + particularly with MIME-encoded [RFC2045] messages, a mailing list + processor will do more than append (See Section 5.3 of [RFC5598] for + details). Furthermore, the use of the length flag is seldom found in + emails in part because of its security challenges. - DKIM has two canonicalizations: simple and relaxed. The latter - allows some modest in transit modifications that do not change the - interpretation of the content of the email. The relaxed - canonicalization used to be computing intensive and may not have been - preferred in the early deployment of DKIM. + DKIM has two canonicalizations to use for headers and body + separately: simple and relaxed. The latter allows some modest in + transit modifications that do not change the interpretation of the + content of the email. The relaxed canonicalization is more computing + intensive and may not have been preferred in the early deployment of + DKIM as this may have been more significant than today. 3. Internet Mail Architecture, DMARC, and Indirect Email Flows This section describes components within the Internet Mail Architecture [RFC5598] where interoperability issues between DMARC and indirect email flows can be found. 3.1. Message Handling System Section 4 of [RFC5598] describes six basic components that make up @@ -272,97 +284,101 @@ be capable of sending email that yields Authenticated Identifiers aligned with the domain found in the RFC5322.From header field. Examples of this issue include "forward-to-friend" functionality commonly found on news/article websites or "send-as" functionality present on some MUAs. When an hMSA takes responsibility for transit of a message containing a domain in the RFC5322.From header field that is outside of the hMSA's ADMD, the hMSA faces DMARC interoperability issues if the domain publishes a DMARC policy of "quarantine" or "reject". These - issues are marked by an inherent difficulty in modifying the domain - present in a message's RFC5322.From header field. Examples of this - issue include: + issues are marked by an inherent difficulty in establishing alignment + with the domain present in a message's RFC5322.From header field. + Examples of this issue include: o Pseudo-open relays - a residential ISP that allows its customers to relay any domains through its infrastructure. o Embedded devices - cable/dsl modems, firewalls, wireless access points that send email using hardcoded domains. o Email service providers - ESPs that service customers that 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 appears 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. 3.1.2.1. Message Encoding - An MTA may change the message encoding, for instance by converting - 8-bit mail sections to quoted-printable 7-bit sections. This is - outside the scope of DKIM canonicalization and will invalidate DKIM - signatures that include message content. + 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. 3.1.2.2. Header Standardization An MTA may standardize headers, usually in order to make non-RFC compliant headers properly compliant. For instance, some common MTAs will correct comprehensible but non-compliant date formats to - compliant ones. Again, this is outside the scope of DKIM - canonicalization and will invalidate DKIM signatures. + compliant ones. This correction is outside the scope of DKIM + canonicalization and will invalidate DKIM signatures. This + correction is also outside the scope of this document in providing + solutions for non RFC compliant emails. 3.1.2.3. Email Address Internationalization A DMARC interoperability issue arises in the context of Email Address Internationalization [RFC6530]. [RFC6854] allows group syntax in the RFC5322.From header field during the transition period to SMTPUTF8. If an EAI/SMTPUTF8-aware MTA needs to transmit a message to a non- aware MTA, the EAI/SMTPUTF8-aware system may transform the RFC5322.From header field of the message to include group syntax to allow the non-aware MTA to receive the email. This transformation will modify the original content of the message and may invalidate any DKIM signatures if the transformation is not done by the MSA or MUA. In addition, group syntax will remove the ability for the DMARC mechanism to find an Organizational Domain that aligns with any authenticated domain identifier from SPF or DKIM. - In addition, the group syntax will result in an invalid domain in the - RFC5322.From header field. If the receiving MTA pays attention to - the validity and reputation of domains, this may present its own set - of delivery problems. + In addition, the group syntax may result in the impossibility of + finding a domain with a DMARC policy associated with it. If the + receiving MTA pays attention to the validity and reputation of + domains, this may present its own set of delivery problems. For + instance an MTA may refuse emails with no valid or emailable domain + in the RFC5322.From as to avoid simple workarounds against DMARC. 3.1.3. Message Delivery Agents The MDA transfers a message from the MHS to a mailbox. Like the MSA, the MDA consists of two sub-components: o MHS-focused MDA functions (hMDA) o Recipient-focused MDA functions (rMDA) Both the hMDA and the rMDA can redirect a message to an alternative address. DMARC interoperability issues related to redirecting of messages are described in Section 3.2. SIEVE [RFC5228] functionality often lives in the rMDA sub-component and can cause DMARC interoperability issues. The SIEVE 'addheader' and 'deleteheader' filtering actions can modify messages and invalidate DKIM signatures, removing DKIM-supplied Authenticated Identifiers as inputs to the DMARC mechanism. There are also SIEVE - extensions that modify the body. SIEVE may become an issue when the - email is reintroduced in the transport infrastructure. + extensions that modify the body. SIEVE may only become an issue when + the email is reintroduced in the transport infrastructure. 3.2. Mediators 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 prevalent within the context of @@ -399,23 +415,23 @@ storage of emails. In most cases, the aMSA providing Alias services has no administrative relationship to the ADMD of the 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 of the new message. - The new Recipient sees the message as being from the original Author, - even if the Mediator adds commentary. + 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. Without an ability to produce Authenticated Identifiers relevant to the Author's RFC5322.From header field domain using either DKIM or SPF, the new Recipient has almost no chance of successfully applying the DMARC mechanism. @@ -458,56 +474,60 @@ Mailing Lists may also have the following DMARC interoperability issues: o Subscribed members may not receive email from members that post using domains that publish a DMARC "p=reject" policy. o Mailing Lists may interpret DMARC-related email rejection as an inability to deliver email to the recipients that are checking and enforcing DMARC policy. This processing may cause subscribed members to be suspended or removed from the Mailing List. - [RFC3463] specifies Enhanced Mail System Status Codes which help - differentiate between various bounces. DMARC even defines - specific codes to be used. + + These changes are common for many mailing lists and receivers are + used to them. Furthermore MUA expects certain mailing list behavior + in presenting emails to the end users 3.2.4. Gateways A Gateway performs the basic routing and transfer work of message relaying, but it also is permitted to modify content, structure, address, or attributes as needed to send the message into a messaging environment that operates under different standards or potentially incompatible policies. Gateways share the same DMARC interoperability issues as ReSenders (Section 3.2.2). Gateways may share also the same DMARC interoperability issues as MTAs (Section 3.1.2). Gateway-level forwarding can introduce DMARC interoperability issues if the Gateway is configured to rewrite the message to map between recipient domains. For example, an acquisition may lead the - acquiring company to decide to decommission the acquired companies + acquiring company to decide to decommission the acquired company's domains by rewriting messages to use the domain of the acquiring - company. Since the To: header is usually DKIM-signed, this kind of - rewriting will also cause DKIM signatures to fail. + company. Since the RFC5322.To header field is usually DKIM-signed, + this kind of rewriting will also cause DKIM signatures to fail. 3.2.5. Boundary Filters To enforce security boundaries, organizations can subject messages to analysis for conformance with their safety policies. A filter might alter the content to render it safe, such as by removing content deemed unacceptable. Boundary Filters share the same DMARC interoperability issues as ReSenders. + Issues may arise if SPF and DKIM is evaluated after the filter + modifications. + Examples of Boundary Filters include: o Anti-spam: To keep its reputation, an MTA that transfers a message may remove harmful content from messages that are likely to be unwanted by the next MTA and/or add text in the body to indicate the message has been scanned. Any such modifications would invalidate a DKIM signature. o Any service that reformulates the RFC5322.body for any other reason, for instance adding an organizational disclaimer. @@ -522,253 +542,280 @@ The causes of indirect email flows can be combined. For example, a university student may subscribe to a mailing list (using his university email address) while this university email address is configured to forward all emails to a freemail provider where a more permanent email address for this student exists. Within an organization the message may pass through various MTAs (Section 3.1.2), each of which performs a different function (authentication, filtering, distribution, etc.) -4. Possible Solutions to Interoperability Issues +4. Possible Mitigations of Interoperability Issues Solutions to interoperability issues between DMARC and indirect email flows vary widely in their scope and implications. They range from - improvements to underlying processors, such as proper handling + improvements to underlying processors, such as proper handling of multiple DKIM signatures, to more radical approaches to the messaging architecture. This section describes possible ways to address interoperability issues. Mail systems are diverse and widely deployed and are expected to continue to work with old systems. For instance, Qmail is still used and the base code has not been updated since 1998. Ezmlm, a once popular mailing list manager, is still deployed and has not been updated since 1997, although a new version, Ezmlm-idx exists. In this constrained environment, some solutions may be time-consuming and/or disruptive to implement. DMARC provides for receivers to make decisions about identity - alignment acceptability based on information outside the DMARC - headers and communicate those decisions as "overrides" to the sender. - This facility can be used to ease some interoperability issues, - although care is needed to ensure that this does not create loopholes - that abusers can use arbitrarily. + alignment acceptability based on information outside DMARC and + communicate those decisions as "overrides" to the sender. This + facility can be used to ease some interoperability issues, although + care is needed to ensure that this does not create loopholes that + abusers can use arbitrarily. -4.1. Identifier Alignment +4.1. Mitigations in Current Use - Currently used work-arounds and fixes to identifier alignment issues: + At many places where DMARC is already deployed, mitigations are in + use. These mitigations vary in their effectiveness and side effects, + but have the advantage that they are currently available. + +4.1.1. Mitigations for Senders + +4.1.1.1. Identifier Alignment o MTAs handling multiple domains may choose to change RFC5321.MailFrom to align with RFC5322.From to improve SPF usability for DMARC. - o MTAs handling multiple domains may also choose to align HELO/EHLO - to RFC5322.From, particularly when sending bounce messages. + o MTAs handling multiple domains may also choose to align + RFC5321.HELO/EHLO to RFC5322.From, particularly when sending + bounce messages. Adjusting dynamically the RFC5321.HELO based on + the RFC5322.From may not be possible for some MTA software. - o MTAs may choose to DKIM sign bounces to allow DKIM-based DMARC - pass. + o MTAs may choose to DKIM sign bounces with an aligned domain to + allow DKIM-based DMARC pass. o MTAs handling multiple domains may require DMARC-using senders to provide DKIM keys and use DKIM to avoid SPF alignment issues. + Handling DKIM keys with a third party has its security challenges. - o ReSenders may choose to change RFC5322.From to one under the - ReSender's control, avoiding alignment issues with the original. - - o Receivers should update DKIM handling libraries to ensure that - they process all valid DKIM signatures and check them for - alignment. - - Proposed and in-progress work-arounds and fixes to identifier - alignment issues: - - o Third party authorization, [RFC6541], [I-D.otis-tpa-label] and - [I-D.kucherawy-dkim-delegate] provide ways to extend identifier - alignment under the control of the domain owner. - -4.2. Message Modification - - Message modification invalidates DKIM signatures and complicates a - receiver's ability to generate Authenticated Identifiers from a - message. Avoiding message modification wherever possible is - therefore desirable. + 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 this may affect what the recipient expects in its MUA. - Currently used work-arounds and fixes to message modification issues: +4.1.1.2. Message Modification o Senders can maximize survivability of DKIM signatures by limiting the header fields they sign, using relaxed canonicalization and by using length to allow appended signatures. o Senders can also maximize survivability by starting with RFC- compliant headers and common body formats. - o Forwarders can choose to add email headers instead of modifying - existing headers or bodies. - - o Forwarders can minimize the circumstances in which they choose to - fix messages, preferring preserving non-compliant headers to - creating DKIM failures. - - o Forwarders can choose to reject messages with suspect or harmful - content instead of modifying them. - - o If message modification is required, the RFC5322.From may be - changed. - - Proposed and in-progress work-arounds and fixes to message - modification issues: - - o DKIM with constrained transformations, - [I-D.kucherawy-dkim-list-canon] - -4.3. Message Forwarding - - Forwarding messages without modification is referred to as - "transparent forwarding", and is a way to preserve the validity of - DKIM signatures. - - Currently used work-arounds and fixes to message forwarding issues: + o In order to minimize the chances of transport conversions, Senders + can convert the message to a suitable MIME content-transfer + encoding such as quoted-printable or base64 before signing + ([RFC6376] Section 5.3). - o Senders should use DKIM signing to allow transparent forwarding to - succeed. +4.1.2. Mitigations for Receivers - o ReSenders may choose to change RFC5322.From to one under the - ReSender's control, avoiding alignment issues with the original. +4.1.2.1. Identifier Alignment - The Original-From [RFC5703] (or X-Original-From) header is used in - various contexts (X- header fields name are discouraged by - [RFC6648]). + o Receivers should update DKIM handling libraries to ensure that + they process all valid DKIM signatures and check them for + alignment. - Note that Original-From (or X-Original-From) is merely adding - complexity to the 'who was the author of this message' assessment, - very possibly creating yet-another security hole. +4.1.2.2. Policy Override -4.3.1. Original-Authentication-Results + o Receivers can amalgamate data from their user base to identify + forwarders and use such list for a DMARC local policy override. + This process may be easier for large receivers, where there is + data and resources to create such lists, than for small receivers. - [I-D.kucherawy-original-authres] has been mentioned in early DMARC - drafts as a way to pass along Original Authentication Results to - "downstream" receivers. +4.1.2.3. Email Address Internationalization -4.4. Message Handling Services + o During the transition from email systems that do not allow EAI + (SMTPUTF8) to email systems that allow it, [RFC6854] allows the + MUA or MSA to use the group syntax for the RFC5322.From header + field to avoid a known MTA to reject the message (if RFC5322 is + implemented strictly). While this will alleviate the EAI problem, + it will allow a simple DMARC workaround since the message may no + longer have a single usable domain in the RFC5322.From header + field, making DMARC inapplicable. DMARC implementations that pay + attention to the validity of the domains in the RFC5322.From may + then have to choose between EAI transitioning compliance + (accepting the email without a domain in RFC5322.From) and + security (rejecting RFC-compliant email for lack of a domain in + the RFC5322.From). The real solution is to upgrade MTAs to + support EAI (SMTPUTF8), avoiding the transition issue. -4.4.1. Message Transfer Agents +4.1.3. Mitigations for ReSenders -4.4.1.1. Encoding +4.1.3.1. Changes to the RFC5322.From - There are few reasons to modify the encoding of the message, - compatibility issues between international character sets are few - nowadays. More mail systems supports 8bitMIME, therefore the need - for transport encoding changes are rarer. By default no modification - of the message should be done when simply forwarding the message. + Many ReSender issues can be avoided by using an RFC5322.From under + the ReSender's control, instead of the initial RFC5322.From. This + will correct identifier alignment issues and allow arbitrary message + modification, for instance. When ReSenders change the RFC5322.From, + it is desirable to preserve the information about the original + initiator of the message. The Original-From [RFC5703] (or X- + Original-From) header field is used for this purpose in various + contexts (X- header fields name are discouraged by [RFC6648]). -4.4.1.2. Filters + However, handling of Original-From (or X-Original-From) is not + defined anywhere. It is not currently used consistently or displayed + to the user, but in any situation where it is used, it is a new + unauthenticated identifier available for exploitation. - Filters should not add to or modify the body of the message, but - either should reject the message or add new email headers (not under - DKIM) to indicate the result of the filter. +4.1.3.2. Avoiding Message Modification -4.4.1.3. Email Address Internationalization + o Forwarders can choose to add email header fields instead of + modifying existing headers or bodies, for instance to indicate a + message may be spam. - During the transition from email systems that do not allow EAI - (SMTPUTF8) to email system that allows it, [RFC6854] allows using the - group syntax for the RFC5322.From header field rather than rejecting - the message (if RFC5322 is implemented strictly). Allowing the group - syntax is at the appreciation of the postmaster, that will always - choose the solution best for its user, but really to avoid DMARC not - finding a single useable domain in the RFC5322.From header field, the - real solution is to upgrade your MTAs, to support EAI (SMTPUTF8). In - that case a sending SMTPUTF8 MTA does not need to require a downgrade - of the message to ASCII identifiers. Encouraging, by rejection or - reputation scoring, the presence of a domain in the RFC5322.From - header field is easier. + o Forwarders can minimize the circumstances in which they choose to + fix messages, preferring to preserve non-compliant headers to + creating DKIM failures. -4.5. Mediators + o Forwarders can choose to reject messages with suspect or harmful + content instead of modifying them. -4.5.1. Mailing Lists +4.1.3.3. Mailing Lists [RFC6377] provides some guidance on using DKIM with Mailing lists. - Here are some other remediations techniques: + Here are some other remediation techniques: o One common mitigation policy is to configure the Mailing List Manager (MLM) to alter the RFC5322.From header field to use the domain of the MLM. Since most list subscribers prefer to know the identity of the author of the original message, typically this information may be provided in the display name part of the RFC5322.From header field. This display name needs to be carefully crafted as to not collide with the original display name of the author, nor contain something that looks like an email - address or domain name. These modification may to some extent - defeats the purpose of DMARC itself. It may make it difficult to - ensure that users of all email clients can easily reply to author, - list, or all using the email client features provided for that - purpose. Use of "Reply-To" can alleviate this problem depending - if the mailing list is configured to reply-to-list, reply-to- - author or reply-to-fixed-address. + address or domain name. These modifications may to some extent + defeat the purpose of DMARC itself. It may make it difficult to + ensure that users of all email clients can easily reply to the + author, the list, or all using the email client features provided + for that purpose. Use of RFC5322.Reply-To header field can + alleviate this problem depending on whether the mailing list is + configured to reply-to-list, reply-to-author or reply-to-fixed- + address, however it is important to note that this header field + can take multiple email addresses. When altering the RFC5322.From + there are two possibilities, to change it to put the mailing list + email address, or to change it to add a suffix like ".invalid" to + the domain of the email address present there. The later + modification may create issues because it is an invalid domain + name, and some MTAs may take particular attention to the validity + of email addresses in RFC5322.From and the reputation of the + domains present there. o Another common mitigation policy is to configure the MLM to "wrap" - the message in a MIME message/rfc822 part. This completely - bypasses the DMARC policy in clients that allow reading the part - as a message. Many email clients (as of August 2014) have - difficulty reading such messages. + the message in a MIME message/rfc822 part and to send as the + Mailing List email address. Many email clients (as of August + 2014) have difficulty reading such messages. - o Finally a less common mitigation policy, is to configure the MLM - to not modify the message so that the DKIM signature remains - valid. + o A, now, less common mitigation policy, is to configure the MLM to + not modify the message so that the DKIM signature remains valid. o To alleviate unsubscribes to the mailing list due to the messages bouncing because of DMARC, the MLM needs to not act on bounces due - to Message Authentication issues. Correctly interpreting Extended - SMTP error messages is useful in this case ([RFC7372]). + to Message Authentication issues. [RFC3463] specifies Enhanced + Mail System Status Codes which help differentiate between various + bounces. Correctly interpreting Extended SMTP error messages is + useful in this case in particular codes defined in [RFC7372] and + in DMARC. All these techniques may provide some specific challenges in MUAs and different operational usages for end users (like rewriting filters to sort emails in folders). There will be some time before all implications are understood and alleviated. -4.6. Getting More Radical: Requiring New Communication Paths Between - MUA and the Message Store +4.2. Proposed and In-Progress Mitigations - In practice a number of operators are using strict alignement mode in + The following mitigations are based on Internet Drafts which have not + yet received broad consensus. They are described here to offer + exploratory path for solutions. These solutions should not be used + in a production environment. + + o Third party authorization, [RFC6541], [I-D.otis-tpa-label] and + [I-D.kucherawy-dkim-delegate] provide ways to extend identifier + alignment under the control of the domain owner. + + o DKIM with constrained transformations, + [I-D.kucherawy-dkim-list-canon] is proposed to allow message + modification. + + o DKIM with recorded transformations, [I-D.kucherawy-dkim-transform] + is proposed to indicate what limited transformations were done to + the message so that a receiver could reverse them and confirm the + validity of the orignal DKIM signature. + + o [I-D.kucherawy-original-authres] is intended as a way to pass + along Original Authentication Results to "downstream" receivers. + + It is not widely implemented and relies on a trust relationship + between the forwarder and the other receivers. + + 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. + +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 mail through systems purporting to be + 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 be vesting some trust in the mailing list service. The creators of DKIM foresaw precisely this possibility at the time by not tightly binding any semantics to the RFC5322.From header field. Some experimental work has taken place in this area, as mentioned above. Additional work might examine a new communication path to the user to - authorize third party signatures. + authorize some form of transitive trust. 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. 7. Acknowledgments Miles Fidelman, John Levine, David Crocker, Stephen J. Turnbull, - Rolf E. Sonneveld, Tim Dragen and Franck Martin contributed to the + 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 mail flows. + interoperability issues with DMARC and indirect email flows. Tim Draegen created the first draft of this document from these - contributions and by carefully mapping contributions into the + 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. @@ -825,20 +872,26 @@ [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. + [I-D.kucherawy-dkim-transform] + Kucherawy, M., "Recognized Transformations of Messages + Bearing DomainKeys Identified Mail (DKIM) Signatures", + draft-kucherawy-dkim-transform-00 (work in progress), + April 2015. + [I-D.kucherawy-original-authres] Chew, M. and M. Kucherawy, "Original-Authentication- Results Header Field", draft-kucherawy-original-authres-00 (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] @@ -860,22 +914,23 @@ Eliot Lear (editor) Cisco Systems GmbH Richtistrasse 7 Wallisellen, ZH CH-8304 Switzerland Phone: +41 44 878 9200 Email: lear@cisco.com Tim Draegen (editor) - Eudaemon - NC + Eudaemonic Development LLC + PO Box 19443 + Asheville, NC 28815 USA - Email: tim@eudaemon.net + Email: tim@eudev.net Elizabeth Zwicky (editor) Yahoo Sunnyvale, CA USA Email: zwicky@yahoo-inc.com