--- 1/draft-ietf-dmarc-interoperability-02.txt 2015-05-22 17:14:54.130500803 -0700 +++ 2/draft-ietf-dmarc-interoperability-03.txt 2015-05-22 17:14:54.170501760 -0700 @@ -1,23 +1,23 @@ DMARC Working Group F. Martin, Ed. Internet-Draft LinkedIn Intended status: Informational E. Lear, Ed. -Expires: October 30, 2015 Cisco Systems GmbH +Expires: November 23, 2015 Cisco Systems GmbH T. Draegen, Ed. Eudaemonic Development LLC E. Zwicky, Ed. Yahoo - April 28, 2015 + May 22, 2015 Interoperability Issues Between DMARC and Indirect Email Flows - draft-ietf-dmarc-interoperability-02 + draft-ietf-dmarc-interoperability-03 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 @@ -31,92 +31,96 @@ 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 October 30, 2015. + This Internet-Draft will expire on November 23, 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as 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 + 2. Causes of Interoperability Issues . . . . . . . . . . . . . . 4 + 2.1. Originator vs Receiver Perspective . . . . . . . . . . . 4 + 2.2. Identifier Alignment . . . . . . . . . . . . . . . . . . 4 + 2.3. Message Forwarding . . . . . . . . . . . . . . . . . . . 5 + 2.4. Message Modification . . . . . . . . . . . . . . . . . . 6 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.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. Email Address Internationalization . . . . . . . 8 - 3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 8 + 3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 11 - 3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 11 + 3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 12 3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 12 - 4. Possible Mitigations of Interoperability Issues . . . . . . . 12 + 4. Possible Mitigations of Interoperability Issues . . . . . . . 13 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.1.2. Message Modification . . . . . . . . . . . . . . 14 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.2.3. Email Address Internationalization . . . . . . . 15 + 4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 15 + 4.1.3.1. Changes to the RFC5322.From . . . . . . . . . . . 15 4.1.3.2. Avoiding Message Modification . . . . . . . . . . 15 - 4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 15 - 4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 16 + 4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 16 + 4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 17 4.2.1. Getting More Radical: Requiring New Communication - Paths Between MUAs . . . . . . . . . . . . . . . . . 17 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 + Paths Between MUAs . . . . . . . . . . . . . . . . . 18 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 18 - 8.2. Informative References . . . . . . . . . . . . . . . . . 19 + 8.2. Informative References . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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. + DMARC is, as this writing, an Informational RFC, however it has a + significant deployment within the email community. + 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. 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. @@ -138,21 +142,33 @@ 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 +2.1. Originator vs Receiver Perspective + + Some Receivers are concerned that wanted email messages are received, + regardless if such email messages are not strictly in conformance to + any standard or protocol. + + Some Originators, particularly for high value transactional messages, + want the message discarded if it passes through an intermediary and + is modified in any way resulting in a failure to validate. Examples + of such messages include those related to financial organizations and + medical establishments. + +2.2. 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 @@ -172,32 +188,32 @@ 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 erroneously apply DMARC based policy to otherwise legitimate messages. - SPF can provides two Authenticated Identifiers based on two different + SPF can provide 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 +2.3. 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 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: @@ -209,21 +225,21 @@ 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 +2.4. Message Modification 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 @@ -324,41 +340,42 @@ 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. 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 + A DMARC related issue may arise 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. + aware MTA, the non aware MTA will reject it. While an MTA will not + downgrade a message. The MUA or MSA may resend the message using the + 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 another case, a MDA, may use the group syntax to pass a message to + a non EAI/SMTPUTF8-aware MS (or user email client). This message + could then be forwarded to another recipient. - In addition, the group syntax may result in the impossibility of + For an MTA, 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. + This case is not an interoperability issue with DMARC, but with other + email policies an MTA may have to support 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 @@ -456,21 +473,22 @@ o prepending the RFC5322.Subject header field with a tag, to allow the receiver to identify visually the mailing list. o adding a footer to the email body to contain administrative instructions. o removing some MIME-parts from the email or converting the message to text only. - o PGP-encrypting the body to the receiver's key. + o PGP-encrypting or S/MIME encrypting the body to the receiver's + key. o enforcing community standards by rewriting banned words. o allowing moderators to add arbitrary commentary to messages. Any such modifications would invalidate a DKIM signature. Mailing Lists may also have the following DMARC interoperability issues: @@ -599,20 +617,25 @@ provide DKIM keys and use DKIM to avoid SPF alignment issues. Handling DKIM keys with a third party has its security challenges. 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. + o Senders can use different domains with different DMARC policies + for email sent directly and email known to use indirect mail flow. + However for 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, 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 In order to minimize the chances of transport conversions, Senders @@ -642,21 +665,21 @@ 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 + the RFC5322.From). The practical solution is to upgrade MTAs to support EAI (SMTPUTF8), avoiding the transition issue. 4.1.3. Mitigations for ReSenders 4.1.3.1. Changes to the RFC5322.From 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, @@ -679,56 +702,65 @@ o Forwarders can minimize the circumstances in which they choose to fix messages, preferring to preserve non-compliant headers to creating DKIM failures. o Forwarders can choose to reject messages with suspect or harmful content instead of modifying them. 4.1.3.3. Mailing Lists [RFC6377] provides some guidance on using DKIM with Mailing lists. - Here are some other remediation techniques: + Here are some remediation techniques on using DMARC with Mailing + lists: - 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 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 One mitigation policy, which is now present on several Mailing + List software, 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 + 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 and to send as the - Mailing List email address. Many email clients (as of August - 2014) have difficulty reading such messages. + o Another mitigation policy is to configure the MLM to "wrap" 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 A, now, less common mitigation policy, is to configure the MLM to - not modify the message so that the DKIM signature remains valid. + o Another mitigation policy, is to configure the MLM to not modify + the message so that the DKIM signature remains valid. Some + Mailing Lists are mainly setup this way and require little + modifications to ensure the DKIM signature is preserved. However + moving to this policy a list that do extensive modification to the + email, may be too much of a change for the members of such list. - o To alleviate unsubscribes to the mailing list due to the messages + o Another mitigation policy, is to reject posts from domains with a + DMARC policy other than p=none. However members of such Mailing + Lists may complain of unfair exclusion. + + 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. [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