| DMARC Working Group | F. Martin, Ed. |
| Internet-Draft | |
| Intended status: Informational | E. Lear, Ed. |
| Expires: November 23, 2015 | Cisco Systems GmbH |
| T. Draegen, Ed. | |
| Eudaemonic Development LLC | |
| E. Zwicky, Ed. | |
| Yahoo | |
| May 22, 2015 |
Interoperability Issues Between DMARC and Indirect Email Flows
draft-ietf-dmarc-interoperability-03
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 addressing interoperability issues are presented.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
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.
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.
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 significant deployment within the email community.
Cases in which email does not flow directly from the author's administrative domain to the recipients 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 both direct and indirect email flows can be significant.
Several known causes of interoperability issues are presented, followed by a description of components within the Internet Mail Architecture [RFC5598] where interoperability issues can arise.
Lastly, known and possible methods for addressing interoperability issues are presented. There are often multiple ways to address any given interoperability issue. While this document strives to be comprehensive in its review, it should not be treated as complete.
Notation regarding structured fields is taken from [RFC5598].
Organizational Domain and Authenticated Identifiers are specified in DMARC [RFC7489].
Interoperability issues between DMARC and indirect email flows arise when conformance to the DMARC specification leads an implementation to apply DMARC based policy to messages that are both compliant with the architecture as specified in [RFC5598] and viewed as legitimate by the intended recipient. To be clear, this document does not address emails considered legitimate by the intended recipient but which are not conformant to other email specifications. The rest of this section describes several conceptual causes of interoperability issues.
Some Receivers are concerned that wanted email messages are received, regardless if such email messages are not strictly in conformance to any standard or protocol.
Some Originators, particularly for high value transactional messages, want the message discarded if it passes through an intermediary and is modified in any way resulting in a failure to validate. Examples of such messages include those related to financial organizations and medical establishments.
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 relevant to the domain found in the message's RFC5322.From header field [RFC5322]. This relevancy is referred to as Identifier Alignment.
Identifier Alignment can be strict, where the domains exactly match each others, or relaxed where the domains are part of the same Organizational Domain. There are, in general, the same interoperability issues between strict and relaxed alignment, however in strict mode the possible solutions are more constrained when possible. This Document mainly implies relaxed Identifier Alignment.
DKIM provides a cryptographic means for a domain to be associated with a particular message. DKIM does not make any constraints on what domains may or must present this association. 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 erroneously apply DMARC based policy to otherwise legitimate messages.
SPF can provide two Authenticated Identifiers based on two different SPF identities: RFC7208.HELO [RFC7208] and RFC7208.MAILFROM [RFC7208]. DMARC uses only the RFC7208.MAILFROM identifier for alignment. 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 in RFC7208.MAILFROM, furthermore, RFC7208.MAILFROM definition is different from RFC5321.MailFrom [RFC5321] definition.
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 of these behaviors involve email being retransmitted by a new SMTP server. As discussed above, for SPF to cause a DMARC pass, the domain of the RFC7208.MAILFROM, must be aligned with that of the RFC5322.From header field:
In either case, SPF cannot produce a DMARC pass, and DKIM will be required to get DMARC to pass.
Modification of email content invalidates most DKIM signatures, and many message forwarding systems modify email content. Mailing list processors are the most common example of such systems, but other forwarding systems also make modifications. Although DKIM provides a length flag so that content can be appended (See Section 8.2 of [RFC6376] for additional security considerations), in practice, particularly with MIME-encoded [RFC2045] messages, a mailing list processor will do more than append (See Section 5.3 of [RFC5598] for details). Furthermore, the use of the length flag is seldom found in emails in part because of its security challenges.
DKIM has two canonicalizations to use for headers and body separately: simple and relaxed. The latter allows some modest in transit modifications that do not change the interpretation of the content of the email. The relaxed canonicalization is more computing intensive and may not have been preferred in the early deployment of DKIM as this may have been more significant than today.
This section describes components within the Internet Mail Architecture [RFC5598] where interoperability issues between DMARC and indirect email flows can be found.
Section 4 of [RFC5598] describes six basic components that make up the Message Handling System (MHS):
Of these components MSA, MTA, and MDA are discussed in relation to interoperability with DMARC.
A Mediator is a special class of MUA that is given special consideration in this section due to the unique issues Mediators face when attempting to interoperate with DMARC.
An MSA accepts messages submitted by a Message User Agent (MUA) and enforces the policies of the hosting ADministrative Management Domain (ADMD) and the requirements of Internet standards.
MSAs are split into two sub-components:
MSA interoperability issues with DMARC begin when an aMSA accepts a message where the RFC5322.From header field contains a domain that is outside of the ADMD of the MSA. The ADMD will almost certainly not be capable of sending email that yields Authenticated Identifiers aligned with the domain found in the RFC5322.From header field. Examples of this issue include "forward-to-friend" functionality commonly found on news/article websites or "send-as" functionality present on some MUAs.
When an hMSA takes responsibility for transit of a message containing a domain in the RFC5322.From header field that is outside of the hMSA's ADMD, the hMSA faces DMARC interoperability issues if the domain publishes a DMARC policy of "quarantine" or "reject". These issues are marked by an inherent difficulty in establishing alignment with the domain present in a message's RFC5322.From header field. Examples of this issue include:
MTAs relay a message until the message reaches a destination MDA.
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 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.
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.
The MDA transfers a message from the MHS to a mailbox. Like the MSA, the MDA consists of two sub-components:
Both the hMDA and the rMDA can redirect a message to an alternative address. DMARC interoperability issues related to redirecting of messages are described in Section 3.2.
SIEVE [RFC5228] functionality often lives in the rMDA sub-component and can cause DMARC interoperability issues. The SIEVE 'addheader' and 'deleteheader' filtering actions can modify messages and invalidate DKIM signatures, removing DKIM-supplied Authenticated Identifiers as inputs to the DMARC mechanism. There are also SIEVE extensions that modify the body. SIEVE may only become an issue when the email is reintroduced in the transport infrastructure.
See [RFC5598] for a complete definition of Mediators.
Mediators forward messages through a re-posting process. Mediators share some functionality with basic MTA relaying, but have greater flexibility in both addressing and content modifications.
DMARC interoperability issues are prevalent within the context of Mediators, which are often used precisely for their ability to modify messages.
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 "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 beyond SPF's ability to grant authorization.
Examples of Aliasing include:
In most cases, the aMSA providing Alias services has no administrative relationship to the ADMD of the final recipient, so solutions to Alias-related DMARC failure should not assume such a relationship.
ReSenders "splice" a message's addressing information to connect the Author of the original message with the Recipient(s) of the new message. The new Recipient sees the message as being from the original Author, even if the Mediator adds commentary.
ReSenders introduce DMARC interoperability issues as content modification invalidates DKIM signatures. SPF's ability to grant authorization via alignment is removed as the new Recipient receives the message from the Mediator.
Without an ability to produce Authenticated Identifiers relevant to the Author's RFC5322.From header field domain using either DKIM or SPF, the new Recipient has almost no chance of successfully applying the DMARC mechanism.
Examples of ReSenders include MUA-level forwarding by resending a message to a new recipient or by forwarding a message "inline" to a new recipient (this does not include forwarding a message "as an attachment"). An additional example comes in the form of calendaring software that allows a meeting attendee (not the meeting organizer) to modify the content of an invite causing the invitations to appear to be reissued from the meeting organizer.
A Mailing List receives messages as an explicit addressee and then re-posts them to a list of subscribed members. The Mailing List performs a task that can be viewed as an elaboration of the ReSender.
Mailing Lists share the same DMARC interoperability issues as ReSenders [resenders], and very commonly modify headers or message content in ways that will cause DKIM to fail, including:
Any such modifications would invalidate a DKIM signature.
Mailing Lists may also have the following DMARC interoperability issues:
These changes are common for many mailing lists and receivers are used to them. Furthermore MUA expects certain mailing list behavior in presenting emails to the end users
A Gateway performs the basic routing and transfer work of message relaying, but it also is permitted to modify content, structure, address, or 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 [resenders].
Gateways may share also the same DMARC interoperability issues as MTAs [mta].
Gateway-level forwarding can introduce DMARC interoperability issues if the Gateway is configured to rewrite the message to map between recipient domains. For example, an acquisition may lead the acquiring company to decide to decommission the acquired company's domains by rewriting messages to use the domain of the acquiring company. Since the RFC5322.To header field is usually DKIM-signed, this kind of rewriting will also cause DKIM signatures to fail.
To enforce security boundaries, organizations can subject messages to analysis for conformance with their safety policies. A filter might alter the content to render it safe, such as by removing content deemed unacceptable.
Boundary Filters share the same DMARC interoperability issues as ReSenders.
Issues may arise if SPF and DKIM is evaluated after the filter modifications.
Examples of Boundary Filters include:
The causes of 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 provider where a more permanent email address for this student exists.
Within an organization the message may pass through various MTAs [mta], each of which performs a different function (authentication, filtering, distribution, etc.)
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 multiple DKIM signatures, to more radical approaches to the messaging architecture. This section describes possible ways to address interoperability issues.
Mail systems are diverse and widely deployed and are expected to continue to work with old systems. For instance, Qmail is still used and the base code has not been updated since 1998. Ezmlm, a once popular mailing list manager, is still deployed and has not been updated since 1997, although a new version, Ezmlm-idx exists. In this constrained environment, some solutions may be time-consuming and/or disruptive to implement.
DMARC provides for receivers to make decisions about identity alignment acceptability based on information 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 that abusers can use arbitrarily.
At many places where DMARC is already deployed, mitigations are in use. These mitigations vary in their effectiveness and side effects, but have the advantage that they are currently available.
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]).
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.
[RFC6377] provides some guidance on using DKIM with Mailing lists. Here are some remediation techniques on using DMARC with Mailing lists:
All these techniques may provide some specific challenges in MUAs and different operational usages for end users (like rewriting filters to sort emails in folders). There will be some time before all implications are understood and alleviated.
The following mitigations are based on Internet Drafts which have not yet received broad consensus. They are described here to offer exploratory path for solutions. These solutions should not be used in a production environment.
In practice a number of operators are using strict alignment mode in DMARC in order to avoid receiving new and innovative forms of unwanted and unauthentic email through systems purporting to be mailing list handlers. The receiving ADMD has no knowledge of which lists the user has subscribed to and which they have not. One avenue of exploration would be for the user to authorize mailing lists as proxies for authentication, at which point the receiving ADMD would be vesting some trust in the mailing list service. The creators of DKIM foresaw precisely this possibility at the time by not tightly binding any semantics to the RFC5322.From header field. Some experimental work has taken place in this area, as mentioned above. Additional work might examine a new communication path to the user to authorize some form of transitive trust.
This document contains no actions for IANA. [RFC Editor: Please delete this section prior to publication.]
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. However, it introduces no new security issues to Internet messaging.
Miles Fidelman, John Levine, David Crocker, Stephen J. Turnbull, 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].
| [I-D.kucherawy-dkim-delegate] | Kucherawy, M. and D. Crocker, "Delegating DKIM Signing Authority", Internet-Draft draft-kucherawy-dkim-delegate-01, June 2014. |
| [I-D.kucherawy-dkim-list-canon] | Kucherawy, M., "A List-safe Canonicalization for DomainKeys Identified Mail (DKIM)", Internet-Draft draft-kucherawy-dkim-list-canon-00, June 2014. |
| [I-D.kucherawy-dkim-transform] | Kucherawy, M., "Recognized Transformations of Messages Bearing DomainKeys Identified Mail (DKIM) Signatures", Internet-Draft draft-kucherawy-dkim-transform-00, April 2015. |
| [I-D.kucherawy-original-authres] | Chew, M. and M. Kucherawy, "Original-Authentication-Results Header Field", Internet-Draft draft-kucherawy-original-authres-00, February 2012. |
| [I-D.levine-dkim-conditional] | Levine, J., "DKIM Conditional Signatures", Internet-Draft draft-levine-dkim-conditional-00, June 2014. |
| [I-D.otis-tpa-label] | Otis, D. and D. Black, "Third-Party Authorization Label", Internet-Draft draft-otis-tpa-label-00, May 2014. |
| [RFC7489] | Kucherawy, M. and E. Zwicky, "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, March 2015. |