--- 1/draft-ietf-dmarc-interoperability-03.txt 2015-06-09 04:15:10.686634509 -0700 +++ 2/draft-ietf-dmarc-interoperability-04.txt 2015-06-09 04:15:10.726635474 -0700 @@ -1,23 +1,23 @@ DMARC Working Group F. Martin, Ed. Internet-Draft LinkedIn Intended status: Informational E. Lear, Ed. -Expires: November 23, 2015 Cisco Systems GmbH +Expires: December 11, 2015 Cisco Systems GmbH T. Draegen, Ed. Eudaemonic Development LLC E. Zwicky, Ed. Yahoo - May 22, 2015 + June 9, 2015 Interoperability Issues Between DMARC and Indirect Email Flows - draft-ietf-dmarc-interoperability-03 + draft-ietf-dmarc-interoperability-04 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,84 +31,83 @@ 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 November 23, 2015. + This Internet-Draft will expire on December 11, 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 . . . . . . . . . . . . . . 4 + 2. Causes of Interoperability Issues . . . . . . . . . . . . . . 3 2.1. Originator vs Receiver Perspective . . . . . . . . . . . 4 2.2. Identifier Alignment . . . . . . . . . . . . . . . . . . 4 2.3. Message Forwarding . . . . . . . . . . . . . . . . . . . 5 - 2.4. Message Modification . . . . . . . . . . . . . . . . . . 6 + 2.4. Message Modification . . . . . . . . . . . . . . . . . . 5 3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 6 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.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 . . . . . . . . . . . . . 8 - 3.1.2.3. Email Address Internationalization . . . . . . . 8 - 3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 9 - 3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 10 + 3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 8 + 3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 9 3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 10 3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 11 - 3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 12 + 3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 11 3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 12 - 4. Possible Mitigations of Interoperability Issues . . . . . . . 13 + 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 . . . . . . . . . . . . . . 14 + 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 . . . . . . . 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 . . . . . . . . . . . . . . . . . . 16 - 4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 17 + 4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 14 + 4.1.3.1. Changes to the RFC5322.From . . . . . . . . . . . 14 + 4.1.3.2. Avoiding Message Modification . . . . . . . . . . 14 + 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 . . . . . . . . . . . . . . . . . 18 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 + 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 . . . . . . . . . . . . . . . . . 20 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 + 8.2. Informative References . . . . . . . . . . . . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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 @@ -338,44 +338,20 @@ 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. 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 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 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. - - 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. - - 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 @@ -651,54 +627,42 @@ they process all valid DKIM signatures and check them for alignment. 4.1.2.2. Policy Override 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. -4.1.2.3. Email Address Internationalization - - 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 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, - 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]). + Many ReSender issues can be avoided by using an RFC5322.From header + field 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. - 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. + A first option is to use the Original-From [RFC5703] (or X-Original- + From) header field for this purpose in various contexts (X- header + fields name are discouraged by [RFC6648]). 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. + + Another option for ReSenders is to rewrite the RFC5322.From header + field address to a valid forwarding address to the original sender, + in a domain that the ReSender controls. 4.1.3.2. Avoiding Message Modification 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. o Forwarders can minimize the circumstances in which they choose to fix messages, preferring to preserve non-compliant headers to creating DKIM failures. @@ -869,35 +833,28 @@ Tests, Iteration, Extraction, Replacement, and Enclosure", RFC 5703, October 2009. [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, September 2011. [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and Mailing Lists", BCP 167, RFC 6377, September 2011. - [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for - Internationalized Email", RFC 6530, February 2012. - [RFC6541] Kucherawy, M., "DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures", RFC 6541, 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. - [RFC6854] Leiba, B., "Update to Internet Message Format to Allow - Group Syntax in the "From:" and "Sender:" Header Fields", - RFC 6854, March 2013. - [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, April 2014. [RFC7372] Kucherawy, M., "Email Authentication Status Codes", RFC 7372, September 2014. 8.2. Informative References [I-D.kucherawy-dkim-delegate]