--- 1/draft-ietf-dmarc-interoperability-13.txt 2016-01-18 12:15:43.750667821 -0800 +++ 2/draft-ietf-dmarc-interoperability-14.txt 2016-01-18 12:15:43.802669067 -0800 @@ -1,25 +1,25 @@ DMARC F. Martin, Ed. Internet-Draft LinkedIn Intended status: Informational E. Lear, Ed. -Expires: June 10, 2016 Cisco Systems GmbH +Expires: July 21, 2016 Cisco Systems GmbH T. Draegen, Ed. dmarcian, inc. E. Zwicky, Ed. Yahoo K. Andersen, Ed. LinkedIn - December 8, 2015 + January 18, 2016 Interoperability Issues Between DMARC and Indirect Email Flows - draft-ietf-dmarc-interoperability-13 + draft-ietf-dmarc-interoperability-14 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,85 +33,89 @@ 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 10, 2016. + This Internet-Draft will expire on July 21, 2016. Copyright Notice - Copyright (c) 2015 IETF Trust and the persons identified as the + Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . 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 + 2.1.3. Multiple RFC5322.from Addresses . . . . . . . . . . . 6 + 2.2. Message Forwarding . . . . . . . . . . . . . . . . . . . 6 + 2.3. Message Modification . . . . . . . . . . . . . . . . . . 7 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.1. Message Submission Agents . . . . . . . . . . . . . . 8 + 3.1.2. Message Transfer Agents . . . . . . . . . . . . . . . 9 + 3.1.2.1. Message Encoding . . . . . . . . . . . . . . . . 9 3.1.2.2. Header Standardization . . . . . . . . . . . . . 9 3.1.2.3. Content Validation . . . . . . . . . . . . . . . 9 - 3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 9 + 3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 10 3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 11 3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 11 3.2.3.1. Mailing List Operational Effects . . . . . . . . 12 - 3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 12 + 3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . 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.2. Mitigations for Receivers . . . . . . . . . . . . . . 17 + 4.1.2.1. Identifier Alignment . . . . . . . . . . . . . . 17 + 4.1.2.2. Policy Override . . . . . . . . . . . . . . . . . 17 + 4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 17 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.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 18 4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 19 4.2.1. Getting More Radical: Requiring New Communication - Paths Between MUAs . . . . . . . . . . . . . . . . . 19 + Paths Between MUAs . . . . . . . . . . . . . . . . . 20 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . 22 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 + Appendix A. Appendix A - Example SPF Bounce . . . . . . . . . . 22 + A.1. Initial Message . . . . . . . . . . . . . . . . . . . . . 22 + A.2. Bounce message . . . . . . . . . . . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 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 @@ -155,82 +160,108 @@ passes standard DMARC validation do not have any interoperability issues. Email messages that do not conform to IETF email specifications but are considered legitimate by the intended recipients are not discussed in this document. The rest of this section describes several conceptual causes of interoperability issues. 2.1. Identifier Alignment + Note to operators and administrators: The identifiers which are used + by DKIM and SPF are technical components of the transport process for + SMTP. They may or may not, as described below, bear a meaningful + relationship to the content or source of the message itself. This + "relationship by proximity" can be a point of confusion for non- + technical end users, either recipients or senders. + 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 - related to the domain found in the message's RFC5322.from header - field [RFC5322]. This relationship is referred to as Identifier - Alignment. + source validation. The DMARC [RFC7489] specification refers to + source domains that are validated by DKIM or SPF as "Authenticated + Identifiers". To be used by DMARC an "Authenticated Identifier" must + also be related to the domain found in the message's RFC5322.from + header field [RFC5322]. This relationship between an Authenticated + Identifier's domain and the domain of the RFC5322.from is referred to + as "Identifier Alignment". - DMARC allows for Identifier Alignment to be achieved in two different - 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. + DMARC allows for Identifier Alignment to be determined in two + different modes: strict and relaxed. Strict mode requires an exact + match between the domain of any of the Authenticated Identifiers and + 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, DMARC interoperability issues are + the same for both strict and relaxed alignment, but strict alignment + constrains the possible solutions because of the more rigorous + matching requirement. The mitigations described in this document + generally require the relaxed mode of Identifier Alignment. 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]. + technology DKIM identifiers are not required to be related to the + source of the message's content. 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. + processing multiple signatures. Implementations that cannot process + multiple DKIM signatures may incorrectly flag messages as "not + passing" (DMARC alignment) and erroneously apply DMARC-based policy + to otherwise conforming messages. 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. + definition has occasionally been misunderstood by operators of MTA + systems since "bounce" messages are often an "automatic" feature of + MTA software. Some MTA software does not provide the ability to + apply a DKIM signature to such bounce messages. + + See Appendix A for an example treatment of this scenario. 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.1.3. Multiple RFC5322.from Addresses + + [RFC5322] permits only one From header field, but it may contain + multiple mailboxes. Since this is an extremely rare usage, DMARC + specifies that the handling of this situation is implementation + dependent. + + Because the presence of multiple domains can be used by an attacker + (an attacker could add their domain to the RFC5322.from field, + provide arbitrary new content, and sign the message) the DMARC + specification recommends that the strictest policy be applied to such + messages (section 6.6.1 [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 field. Forwarding introduces specific issues to the availability of @@ -990,22 +1021,118 @@ [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, . [RFC7601] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 7601, DOI 10.17487/RFC7601, August 2015, . -Authors' Addresses +Appendix A. Appendix A - Example SPF Bounce + +A.1. Initial Message + + Here is the message as it exits the Origin MTA (segv.d1.example): + + Return-Path: + Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) + (authenticated bits=0) + by segv.d1.example with ESMTP id t0FN4a8O084569; + Thu, 14 Jan 2015 15:00:01 -0800 (PST) + (envelope-from jqd@d1.example) + DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; + s=20130426; t=1421363082; + bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; + h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: + Content-Transfer-Encoding; + b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw + bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl + gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= + Message-ID: <54B84785.1060301@d1.example> + Date: Thu, 14 Jan 2015 15:00:01 -0800 + From: John Q Doe + To: no-recipient@dmarc.org + Subject: Example 1 + + Hey gang, + This is a test message. + --J. + +A.2. Bounce message + + When dmarc.org bounces the message without a DKIM signature, it + specifies the HELO/EHLO domain as dmarc.org.local which has no SPF + record. dmarc.org has a reject policy in place for such non-passing + cases. Since there is no DKIM signature on the bounce message, the + failed SPF lookup results in a dmarc=fail and d1.example could be + expected to discard the bounce message itself: + + Return-Path: <> + Received: from dmarc.org.local (mail.dmarc.org. [10.255.0.1]) + by mx.d1.example with ESMTPS id Lkm25302jJR;5 + for + (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); + Thu, 14 Jan 2015 15:00:24 -0800 (PST) + Authentication-Results: mx.d1.example; + spf=none (d1.example: dmarc.org.local does not designate + permitted sender hosts) smtp.mail=; + dmarc=fail (p=REJECT dis=NONE) header.from=dmarc.org + MIME-Version: 1.0 + Return-Path: <> + Received: by 10.10.10.131 with SMTP id u67mr102828634qge.33; Thu, + 14 Jan 2015 15:00:24 -0800 (PST) + From: Mail Delivery Subsystem + To: jqd@d1.example + Subject: Delivery Status Notification (Failure) + Message-ID: <001a11c16e6a9ead220528df294a@dmarc.org> + Date: Thu, 14 Jan 2016 23:00:24 +0000 + Content-Type: text/plain; charset=UTF-8 + + This is an automatically generated Delivery Status Notification + + Delivery to the following recipient failed permanently: + + no-recipient@dmarc.org + + Technical details of permanent failure: + Your message was rejected by the server for the recipient domain + dmarc.org by mail.dmarc.org. [10.255.0.1]. + The error that the other server returned was: + 550 5.1.1 ... User unknown + + ----- Original message ----- + Received: from [10.10.10.131] (w-x-y-z.dsl.static.isp.com [w.x.y.z]) + (authenticated bits=0) + by segv.d1.example with ESMTP id t0FN4a8O084569; + Thu, 14 Jan 2015 15:00:01 -0800 (PST) + (envelope-from jqd@d1.example) + DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; + s=20130426; t=1421363082; + bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; + h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: + Content-Transfer-Encoding; + b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw + bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl + gotsX4RkbNcUhlfnoQ0p+CywWjieI8aR6eof6WDQ= + Message-ID: <54B84785.1060301@d1.example> + Date: Thu, 14 Jan 2015 15:00:01 -0800 + From: John Q Doe + To: no-recipient@dmarc.org + Subject: Example 1 + + Hey gang, + This is a test message. + --J. + +Authors' Addresses Franck Martin (editor) LinkedIn Mountain View, CA USA Email: fmartin@linkedin.com Eliot Lear (editor) Cisco Systems GmbH Richtistrasse 7