--- 1/draft-ietf-dmarc-interoperability-12.txt 2015-12-08 16:15:01.572111746 -0800 +++ 2/draft-ietf-dmarc-interoperability-13.txt 2015-12-08 16:15:01.620112897 -0800 @@ -1,25 +1,25 @@ DMARC F. Martin, Ed. Internet-Draft LinkedIn Intended status: Informational E. Lear, Ed. -Expires: June 2, 2016 Cisco Systems GmbH +Expires: June 10, 2016 Cisco Systems GmbH T. Draegen, Ed. dmarcian, inc. E. Zwicky, Ed. Yahoo K. Andersen, Ed. LinkedIn - November 30, 2015 + December 8, 2015 Interoperability Issues Between DMARC and Indirect Email Flows - draft-ietf-dmarc-interoperability-12 + draft-ietf-dmarc-interoperability-13 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 June 2, 2016. + This Internet-Draft will expire on June 10, 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 @@ -56,60 +56,62 @@ 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 . . . . . . . . . . . . . . . . . . 4 2. Causes of Interoperability Issues . . . . . . . . . . . . . . 4 2.1. Identifier Alignment . . . . . . . . . . . . . . . . . . 4 + 2.1.1. DKIM Identifier(s) . . . . . . . . . . . . . . . . . 5 + 2.1.2. SPF Identifier(s) . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . 6 + 3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 7 + 3.1. Message Handling System . . . . . . . . . . . . . . . . . 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.2. Header Standardization . . . . . . . . . . . . . 9 3.1.2.3. Content Validation . . . . . . . . . . . . . . . 9 3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 9 - 3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 10 - 3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 10 + 3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 11 3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 11 - 3.2.3.1. Mailing List Operational Effects . . . . . . . . 11 + 3.2.3.1. Mailing List Operational Effects . . . . . . . . 12 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 + 3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 13 + 3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 14 + 4. Possible Mitigations of Interoperability Issues . . . . . . . 14 + 4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 15 4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 15 4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 15 - 4.1.1.2. Message Modification . . . . . . . . . . . . . . 15 + 4.1.1.2. Message Modification . . . . . . . . . . . . . . 16 4.1.2. Mitigations for Receivers . . . . . . . . . . . . . . 16 4.1.2.1. Identifier Alignment . . . . . . . . . . . . . . 16 4.1.2.2. Policy Override . . . . . . . . . . . . . . . . . 16 4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 16 - 4.1.3.1. Changes to the RFC5322.from . . . . . . . . . . . 16 + 4.1.3.1. Changes to the RFC5322.from . . . . . . . . . . . 17 4.1.3.2. Avoiding Message Modification . . . . . . . . . . 17 4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 17 - 4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 18 + 4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 19 4.2.1. Getting More Radical: Requiring New Communication Paths Between MUAs . . . . . . . . . . . . . . . . . 19 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 - 8.2. Informative References . . . . . . . . . . . . . . . . . 21 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 + 8.2. Informative References . . . . . . . . . . . . . . . . . 22 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction DMARC [RFC7489] introduces a mechanism for expressing domain-level policies and preferences for message validation, disposition, and reporting. The DMARC mechanism can encounter several different types of interoperability issues due to third-party message sourcing, message transformation or rerouting. At the time of the writing of this document, the DMARC base @@ -172,50 +174,62 @@ modes: strict and relaxed. Strict mode requires an exact match of either of the Authenticated Identifiers to the message's RFC5322.from header field [RFC5322]. Relaxed mode allows for Identifier Alignment if Authenticated Identifiers and the message's RFC5322.from header field [RFC5322] share the same Organizational Domain. In general, interoperability issues between strict and relaxed modes are the same, with strict mode constraining the application of possible solutions. The mitigations described in this document generally require a relaxed mode of Identifier Alignment. - DKIM provides a cryptographic means for a domain identifier to be - associated with a particular message. As a standalone technology - DKIM identifiers are not required to be relevant to the content of a - message. However, for a 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]. +2.1.1. DKIM Identifier(s) + + DKIM provides a cryptographic means for one or more domain identifier + to be associated with a particular message. As a standalone + technology DKIM identifiers are not required to be relevant to the + content of a message. However, for a 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: 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 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 RFC5321.HELO/EHLO SMTP domain. 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 [RFC5322], SPF will not authenticate it unless - it is also the domain checked by SPF. Also note that the - RFC7208.MAILFROM definition is different from the RFC5321.mailfrom - [RFC5321] definition. +2.1.2. SPF Identifier(s) + + The SPF specification [RFC7208] defines two Authenticated Identifiers + for each message. These identifiers derive from: + + a. the RFC5321.mailfrom [RFC5321] domain, and + + b. the RFC5321.HELO/EHLO SMTP domain. + + In the SPF specification, the RFC7208.MAILFROM [RFC7208] value is + defined to be based on RFC5321.mailfrom unless that value is absent + (as in the case of "bounce" messages) in which case, the second + (RFC5321.HELO/EHLO) identifier value is used. This "fallback" + definition has occasionally been misunderstood by senders since + "bounce" messages are often an "automatic" feature of MTA software. + + For the purposes of DMARC validation/alignment, the hybrid + RFC7208.MAILFROM [RFC7208] identifier's domain is used if, and only + if, it is aligned with the RFC5322.from [RFC5322] domain. The + alignment of the validated domain is determined based on the DMARC + record's "strict" or "relaxed" designation as described above for the + DKIM identifiers and in [RFC7489]. 2.2. Message Forwarding 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