--- 1/draft-ietf-dmarc-interoperability-15.txt 2016-06-08 06:15:51.781721683 -0700 +++ 2/draft-ietf-dmarc-interoperability-16.txt 2016-06-08 06:15:51.829722902 -0700 @@ -1,25 +1,25 @@ DMARC F. Martin, Ed. Internet-Draft LinkedIn Intended status: Informational E. Lear, Ed. -Expires: November 14, 2016 Cisco Systems GmbH +Expires: December 10, 2016 Cisco Systems GmbH T. Draegen, Ed. dmarcian, inc. E. Zwicky, Ed. Yahoo K. Andersen, Ed. LinkedIn - May 13, 2016 + June 8, 2016 Interoperability Issues Between DMARC and Indirect Email Flows - draft-ietf-dmarc-interoperability-15 + draft-ietf-dmarc-interoperability-16 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 November 14, 2016. + This Internet-Draft will expire on December 10, 2016. Copyright Notice 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 @@ -79,21 +79,21 @@ 3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 11 3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 12 3.2.3.1. Mailing List Operational Effects . . . . . . . . 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 . . . . . . . . . . . . . . . 16 + 4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 15 4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 16 4.1.1.2. Message Modification . . . . . . . . . . . . . . 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 . . . . . . . . . . 18 4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 18 4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 19 @@ -109,25 +109,25 @@ A.1. Initial Message . . . . . . . . . . . . . . . . . . . . . 23 A.2. Notification message . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 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. + message transformation, or rerouting. At the time of the writing of this document, the DMARC base - specification is published as Informational RFC7489 [RFC7489] and has - seen significant deployment within the email community. + specification is published as Informational RFC 7489 [RFC7489] and + has seen significant deployment within the email community. Cases in which email does not flow directly from the author's administrative domain to the recipient's domain(s) 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 indirect email flows can be significant for a select subset of general email traffic. Several known causes of interoperability issues are presented, followed by a description of components within the Internet Mail @@ -139,31 +139,31 @@ comprehensive in its review, it should not be treated as complete. Note that some practices which are in use at the time of this document may or may not be "best practices", especially as future standards evolve. 1.1. Document Conventions The notation used in this document for structured fields is taken from [RFC5598] section 1.3. - The term "notification message" [RFC5321] secton 4.5.5 is used to + The term "notification message" [RFC5321] section 4.5.5 is used to refer to a message with a null RFC5321.MailFrom. The terms "Organizational Domain" and "Authenticated Identifiers" are specified in DMARC [RFC7489] section 3. 2. Causes of Interoperability Issues Interoperability issues between DMARC and indirect email flows arise when conformance to the DMARC specification leads a receiving - implementation to apply DMARC based policy restrictions to messages + implementation to apply DMARC-based policy restrictions to messages that are both compliant with the architecture as specified in [RFC5598] and viewed as legitimate by the intended recipient. Note that domains which assert a "p=none" policy and email which 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. @@ -237,25 +237,25 @@ (as in the case of notification messages) in which case, the second (RFC5321.HELO/.EHLO) identifier value is used. This "fallback" definition has occasionally been misunderstood by operators of MTA systems since notification messages are often an "automatic" feature of MTA software. Some MTA software does not provide the ability to apply a DKIM signature to such notification 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]. + 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, @@ -277,22 +277,22 @@ o If the RFC5321.MailFrom is present and the forwarder maintains the original RFC5321.MailFrom, SPF validation will fail unless the forwarder is an authorized part of the originator's email sending infrastructure. If the forwarder replaces the RFC5321.MailFrom with its own domain, SPF might pass but Identifier Alignment with the RFC5322.From header field will fail. o If the RFC5321.MailFrom is empty (as in the case of Delivery Status Notifications), the RFC5321.HELO/.EHLO domain of the - forwarder will likely be in different organizational domain than - the orignal RFC5322.From header field's domain. SPF may pass but + forwarder will likely be in a different organizational domain than + the original RFC5322.From header field's domain. SPF may pass but Identifier Alignment with the RFC5322.From header field will fail. In both cases, SPF cannot yield relevant Authenticated Identifiers, and DKIM must be relied upon to produce results that are relevant to DMARC. 2.3. Message Modification Modification of email content invalidates most DKIM signatures, and many message forwarding systems modify email content. Mailing list @@ -303,21 +303,21 @@ without invalidating the signature, in practice, particularly with MIME-encoded [RFC2045] messages, a mailing list processor will do more than simply append content (see Section 5.3 of [RFC5598] for details). Furthermore, the length flag is seldom used due to security issues (see Section 8.2 of [RFC6376] for additional security considerations), therefore, this method is only here mentioned for completeness. DKIM describes two canonicalizations for use when preparing header and body for DKIM processing: simple and relaxed. The latter is - designed to accomodate trivial modifications to whitespace and + designed to accommodate trivial modifications to whitespace and folding which, at least in the header case, generally have no semantic significance. However, the relaxed canonicalization is more computationally intensive and may not have been preferred in the early deployment of DKIM, leaving some deployments using the less forgiving "simple" canonicalization. While the prevalence is unknown, there are some DKIM verifiers which have problems evaluating relaxed canonicalization correctly. 3. Internet Mail Architecture, DMARC, and Indirect Email Flows @@ -403,21 +403,21 @@ 3.1.2.1. Message Encoding An MTA may modify the message encoding, for instance by converting 8-bit MIME sections to quoted-printable 7-bit sections. This modification is outside the scope of DKIM canonicalization and will invalidate DKIM signatures that include message content. An MTA could also re-encode the message without changing the encoding type, receiving a MIME-encoded message and producing a semantically - and semiotically equivalent MIME body that is not identical to the + and semiotically-equivalent MIME body that is not identical to the original. This is characteristic of systems that use some other message representation internally. 3.1.2.2. Header Standardization An MTA may rewrite headers to bring them into compliance with existing RFCs. For example, some common MTAs will correct comprehensible but non-compliant date formats to compliant ones. Header rewriting is outside the scope of DKIM canonicalization and @@ -472,36 +472,36 @@ mail when the new Recipient receives the message from the Mediator rather than the initial organization. 3.2.1. Alias An Alias is a simple re-addressing facility that provides one or more new Internet Mail addresses, rather than a single, internal one. A message continues through the transfer service for delivery to one or more alternative addresses. - Aliases can be implemented by mailbox-level forwarding (e.g. through + Aliases can be implemented by mailbox-level forwarding (e.g., through "dot-forwarding") or SIEVE-level forwarding (through the SIEVE 'redirect' action) or other methods. When an Alias preserves message content and does not make significant header changes, DKIM signatures may remain valid. However, Aliases often extend the delivery path outside of the scope covered by the originating ADMD's SPF record(s). Examples of Aliasing include: o Forwarding email between free email (freemail) providers to try different interfaces while maintaining an original email address; o Consolidating many email addresses into a single account to centralize processing; - o Services that provide "activity based", "role based" , "vanity" or + o Services that provide "activity-based", "role-based" , "vanity" or "temporary" email addresses such as universities and professional associations. For instance professional or alumni institutions may offer their members an alias for the duration of their membership but may not want to deal with the long term storage of emails. In most cases, the aMSA providing Alias services has no administrative relationship to the ADMD of the originator or the final recipient, so solutions to Alias-related DMARC failure should not assume such a relationship. @@ -579,21 +579,21 @@ A Gateway performs the basic routing and transfer work of message relaying, but it also is permitted to modify content, structure, addressing, and/or other attributes as needed to send the message into a messaging environment that operates under different standards or potentially incompatible policies. Gateways share the same DMARC interoperability issues as ReSenders (Section 3.2.2). - Gateways may share also the same DMARC interoperability issues as + Gateways may also share the same DMARC interoperability issues as MTAs (Section 3.1.2). Receiver systems on the non-SMTP side of a protocol gateway may be unable to evaluate DKIM and SPF. If a message passes through a second protocol gateway back into the SMTP domain, the transformations commonly break the original DKIM signature(s). Gateway-level forwarding can introduce DMARC interoperability issues if the Gateway is configured to rewrite the message into alternate recipient domains. For example, an acquisition may lead an acquiring @@ -636,41 +636,41 @@ as a way to control the potential threat from malware. o Secondary MX services: The secondary MX for an organization may be external to the normal mail processing for the organization, and queue and forward to the primary when it becomes available. This will not invalidate DKIM but will prevent the primary from validating SPF normally. In this case, however, it is inappropriate for a primary MX server to perform an SPF check against its own secondaries. Rather, the secondary MX should perform this function and employ some trusted mechanism to - communicate the results of the SPF, DKIM and DMARC evaluation(s) + communicate the results of the SPF, DKIM, and DMARC evaluation(s) to the primary MX server. 3.3. Combinations Indirect email flows can be combined. For example, a university student may subscribe to a mailing list (using his university email address) while this university email address is configured to forward all emails to a freemail or a post-education corporate account provider where a more permanent email address for this student exists. Within an organization the message may pass through various MTAs (Section 3.1.2), each of which performs a different function (authentication, filtering, distribution, etc.) 4. Possible Mitigations of Interoperability Issues Solutions to interoperability issues between DMARC and indirect email flows vary widely in their scope and implications. They range from - improvements to underlying processors, such as proper handling of + improvements to underlying processing, such as proper handling of multiple DKIM signatures, to more radical changes to the messaging architecture. This section describes possible ways to address interoperability issues. Note that these particular mechanisms may not be considered "best practices" and may, in some cases, violate various conventions or expectations. Receivers sometimes need to deliver email messages that do not conform to any standard or protocol, but are otherwise desired by end users. Mitigating the impact of DMARC on indirect email flows is especially important to receivers that operate services where ease of @@ -681,22 +681,21 @@ outside DMARC and communicate those decisions as "overrides" to the sender. This facility can be used to ease some interoperability issues, although care is needed to ensure that this does not create loopholes for abuse. To further complicate the usage of mitigations, mitigation may not be desired if the email in question is of a certain category of high value or high risk (security-related) transactional messages (dealing with financial transactions or medical records, for example). In these cases, mitigating the impact of DMARC due to indirect email - flows may not be desirable (counter-productive, or allowing for - abuse). + flows may not be desirable (counterproductive or allowing for abuse). As a final note, mail systems are diverse and widely deployed. Systems of various ages and capabilities are expected to preserve interoperability with the rest of the SMTP ecosystem. For instance, Qmail is still used, although the base code has not been updated since 1998. ezmlm, a once popular mailing list manager, is still deployed but has not been updated since 1997, although a new version, ezmlm-idx exists. Old versions of other open and closed source MTAs are still commonly in operation. When dealing with aging or unsupported systems, some solutions may be time-consuming and/or @@ -716,41 +714,41 @@ o MTAs handling multiple domains may choose to change RFC5321.MailFrom to align with RFC5322.From to improve SPF usability for DMARC. o MTAs handling multiple domains may also choose to align RFC5321.HELO/.EHLO to RFC5322.From, particularly when sending notification messages. Dynamically adjusting the RFC5321.HELO/.EHLO based on the RFC5322.From may not be possible for some MTA software. - o MTAs may choose to DKIM sign notification messages with an aligned - domain to allow DKIM-based DMARC pass. + o MTAs may choose to DKIM-sign notification messages with an aligned + domain to allow a 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 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 that should be carefully managed (see also [RFC6376] section 8). 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. + the original user's address in an RFC5322.Reply-to header field. However, performing this modification may cause the recipient's MUA to deviate from customary behavior. - o When implementing "forward-to-friend" functionality one approach - to avoid DMARC failures is to pass a well formed message to the + o When implementing "forward-to-friend" functionality, one approach + to avoid DMARC failures is to pass a well-formed message to the user's MUA so that it may fill in an appropriate identity and submit through its own MSA. o Senders can use domains with distinct DMARC policies for email sent directly and email known to use indirect mail flows. However, for known brands, all active domains are likely to be targeted equally by abusers. 4.1.1.2. Message Modification @@ -792,21 +790,21 @@ 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 as long as the ReSender signs the message with an aligned domain signature. When ReSenders change the RFC5322.From, it is desirable to preserve the information about the original initiator of the message. 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 + field names 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, and in any situation where it is used, it is a new unauthenticated identifier available for exploitation unless included within the scope of the new DKIM signature(s). Another option for ReSenders is to rewrite the RFC5322.From header field address to a locally controlled address which will be forwarded back to the original sender (subject to its own ReSender forwarding mitigations!). @@ -866,21 +864,21 @@ o Configuring 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 the publication of this document), especially mobile clients, have difficulty reading such messages and this is not expected to change soon. o Configuring the MLM to not modify the message so that the DKIM signature remains valid. Some Mailing Lists are set up this way and require few additional changes to ensure the DKIM signature is preserved. Moving lists that currently modify mail to a policy - like this, may be too much of a change for the members of such + like this may be too much of a change for the members of such lists. o Rejecting posts or membership requests from domains with a DMARC policy other than "p=none". However members or potential 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 notification messages due to Message Authentication issues. [RFC3463] specifies Enhanced Mail System Status Codes which help @@ -898,21 +896,21 @@ 4.2. Proposed and In-Progress Mitigations The following mitigations are based on Internet Drafts (I-Ds) which are still in process. They are described here to offer exploratory path for solutions. These solutions should not be used in a production environment. Because of the transient nature of I-Ds, specific citations are not included because a number of them will inevitably become obsolete and those which gain consensus in the community will become RFCs and should be discovered as such. - o Third party authorization schemes provide ways to extend + o Third-party authorization schemes provide ways to extend identifier alignment under control of the domain owner. o Ways to canonicalize messages that transit mailing lists so that their alterations can be isolated from the original signed content. o Mechanisms to record message transformations applied at each hop so they can be reversed and the original signed content recovered. o "Conditional" DKIM signatures, whereby the author domain indicates @@ -946,29 +944,29 @@ delete this section prior to publication.] 6. Security Considerations This document is an analysis of DMARC's impact on indirect email flows. It describes the possibility of accidental denial-of-service that can be created by rejections of messages by DMARC-aware Mail Receivers. Section 4.1.1.1 discusses the importance of appropriate DKIM key - management vis a vis third party email senders. + management vis-a-vis third-party email senders. Section 4.1.3.3 warns that rewriting the RFC5322.From header field and changing the domain name should not be done with any domain. 7. Acknowledgments Miles Fidelman, John Levine, David Crocker, Stephen J. Turnbull, - Rolf E. Sonneveld, Tim Draegen and Franck Martin contributed to the + Rolf E. Sonneveld, Tim Draegen, and Franck Martin contributed to the IETF DMARC Working Group's wiki page listing all known interoperability issues with DMARC and indirect email flows. Tim Draegen created the first draft of this document from these contributions and by hamfistedly mapping contributions into the language of [RFC5598]. 8. References 8.1. Normative References @@ -1073,57 +1071,57 @@ A.2. Notification message When dmarc.org rejects the message without a DKIM signature, it specifies the RFC5321.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 notification message, the failed SPF lookup results in a dmarc=fail and d1.example could be expected to discard the notification message itself: Return-Path: <> - Received: from dmarc.org.local (mail.dmarc.org. [10.255.0.1]) + Received: from dmarc.org.local (mail.dmarc.org. [192.0.2.1]) by mx.d1.example with ESMTPS id Lkm25302jJR5 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 - Received: from segv.d1.example (segv.d1.example [10.15.20.25]) - by 10.10.10.131 with SMTP id u67mr102828634qge33; Thu, + Received: from segv.d1.example (segv.d1.example [198.51.100.1]) + by 192.0.2.2 with SMTP id u67mr102828634qge33; 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]. + dmarc.org by mail.dmarc.org [192.0.2.1]. The error that the other server returned was: 550 5.1.1 ... User unknown ----- Original message ----- Return-Path: - Received: from [10.10.10.131] (131-10-10-10.dsl.static.example.com - [10.10.10.131]) (authenticated bits=0) + Received: from [203.252.0.131] (131-0-252-203-dsl.static.example.com + [203.252.0.131]) (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