--- 1/draft-ietf-dmarc-interoperability-06.txt 2015-09-28 23:15:07.097823660 -0700 +++ 2/draft-ietf-dmarc-interoperability-07.txt 2015-09-28 23:15:07.149824919 -0700 @@ -1,25 +1,25 @@ DMARC F. Martin, Ed. Internet-Draft LinkedIn Intended status: Informational E. Lear, Ed. -Expires: February 29, 2016 Cisco Systems GmbH +Expires: March 31, 2016 Cisco Systems GmbH T. Draegen, Ed. dmarcian, inc. E. Zwicky, Ed. Yahoo K. Andersen, Ed. LinkedIn - August 28, 2015 + September 28, 2015 Interoperability Issues Between DMARC and Indirect Email Flows - draft-ietf-dmarc-interoperability-06 + draft-ietf-dmarc-interoperability-07 Abstract DMARC introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting. The DMARC mechanism can encounter interoperability issues when messages do not flow directly from the author's administrative domain to the final recipients. Collectively these email flows are referred to as indirect email flows. This document describes interoperability issues between DMARC and indirect email flows. Possible methods for @@ -33,21 +33,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on February 29, 2016. + This Internet-Draft will expire on March 31, 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 @@ -84,27 +84,27 @@ 4. Possible Mitigations of Interoperability Issues . . . . . . . 13 4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 14 4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 14 4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 15 4.1.1.2. Message Modification . . . . . . . . . . . . . . 15 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.2. Avoiding Message Modification . . . . . . . . . . 16 + 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.1. Getting More Radical: Requiring New Communication Paths Between MUAs . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction DMARC [RFC7489] introduces a mechanism for expressing domain-level policies and preferences for message validation, disposition, and @@ -193,28 +193,28 @@ 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 domain found in the RFC5321.HELO/EHLO SMTP command. - The SPF validated domain in RFC7208.MAILFROM must be part of the same - Organizational Domain as the domain in the RFC5322.From header field - to be aligned. It is important to note that even when an SPF record - exists for the domain in RFC5322.From, SPF will not authenticate it - unless it is also the domain which the SPF analysis has checked. - Also note that RFC7208.MAILFROM definition is different from - RFC5321.MailFrom [RFC5321] definition. + 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, SPF will not authenticate it unless it is + also the domain which the SPF analysis has checked. Also note that + RFC7208.MAILFROM definition is different from RFC5321.MailFrom + [RFC5321] definition. 2.2. Message Forwarding Message forwarding is a generic concept encapsulating a variety of behaviors. Section 3 describes forwarding behavior as it relates to the components of the Internet Mail Architecture. All forwarding behavior involves the retransmission of email. As discussed above, in order for SPF to yield an Authenticated Identifier that is pertinent to DMARC, the domain of the @@ -658,24 +658,26 @@ o MTAs handling multiple domains may also choose to align RFC5321.HELO/EHLO to RFC5322.From, particularly when sending bounce messages. Dynamically adjusting the RFC5321.HELO based on the RFC5322.From may not be possible for some MTA software. o MTAs may choose to DKIM sign bounces with an aligned domain to allow DKIM-based DMARC pass. o MTAs sending email on behalf of multiple domains may require - Domain Owners to provide DKIM keys to use DKIM to avoid DMARC - alignment issues with SPF. Managing DKIM keys with a third party - has security risks which should be carefully managed. Methods - involving CNAMEs and/or subdomains may alleviate some risks. + Domain Owners to provide DKIM keys to use DKIM to avoid SPF + validation issues, given the requirement for DMARC alignment with + the RFC5322.From header field. Managing DKIM keys with a third + party has security risks which should be carefully managed. + Methods involving CNAMEs and/or subdomains may alleviate some + risks. o Senders who are sending on behalf of users in other Administrative Domains may choose to use an RFC5322.From under the sender's control. The new From can be either a forwarding address in a domain controlled by the Sender, or a placeholder address, with the original user's address in a RFC5322.Reply-to header field. However, performing this modification may cause the recipient's MUA to deviate from customary behavior. o Senders can use domains with distinct DMARC policies for email