| DMARC Working Group | F. Martin, Ed. |
| Internet-Draft | |
| Intended status: Informational | E. Lear, Ed. |
| Expires: August 2, 2015 | Cisco Systems GmbH |
| T. Draegen, Ed. | |
| Eudaemon | |
| January 29, 2015 |
Interoperability Issues Between DMARC and Indirect Email Flows
draft-ietf-dmarc-interoperability-00
DMARC introduces a mechanism for expressing domain-level policies and preferences for message validation, disposition, and reporting. The DMARC mechanism can encounter interoperability issues when messages originate from third party sources, are modified in transit, or are forwarded enroute to their final destination. 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 August 2, 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 [I-D.kucherawy-dmarc-base] introduces a mechanism for expressing domain-level policies and preferences for message validation, disposition, and reporting. DMARC is used to combat exact-domain phishing, to gain visibility into email infrastructure, and to provide email egress controls. Due to wide adoption, the impact of DMARC-based email rejection policies on both direct and indirect email flows can be significant.
The DMARC mechanism can encounter several different types of interoperability issues due to message transformation or rerouting. This is known collectively as indirect email flows. In some of these cases, message content is modified as a result.
The next section describes interoperability issues between DMARC and indirect email flows. These issues are first described in the context of configuration behavior that DMARC requires from underlying authentication technology, and then described as they appear in context of the Internet Mail Architecture [RFC5598].
Lastly, possible methods for addressing interoperability issues are presented. There are often multiple ways to address any given interoperability issue. Whereas this document strives to be comprehensive in its review, it should not be treated as complete.
Notation regarding structured fields is taken from [RFC5598].
What do we mean by "interoperability issues"? We say that DMARC introduces interoperability issues or problems, when conformance to the DMARC specification leads an implementation to reject a message that is both compliant with the architecture as specified in [RFC5598] and would have been viewed as legitimate in the eyes of the intended recipient. This the secondary effects of behaviors caused by that rejection. Therefore, we can already conclude that DMARC poses no interoperability problems when messages properly validate through its specified processes. The rest of this section, therefore, delves into how legitimate messages may get rejected.
A fundamental aspect of message source validation is understanding how the originator of a message is validated. Each of the underlying mechanisms that DMARC uses (DKIM [RFC6376] or SPF [RFC7208]) takes a different approach. Therefore, the DMARC [I-D.kucherawy-dmarc-base] mechanism attempts to predictably specify the domain of the originator that will be used for its purposes (reporting/message disposition). This step is referred to as Identifier Alignment.
DKIM provides a cryptographic means for a domain to be associated with a particular message. However, the signing domain is not required to be related to the domain contained in the 5322.From field [RFC5322]. The DMARC identifier alignment process posits just such a relationship. For an identifier to align in DKIM, the signing domain must be part of the same organizational domain as the domain in the 5322.From field, and the signature must be valid.
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: if an implementation cannot process multiple DKIM signatures it may lead to perfectly valid messages being flagged as not authentic.
SPF provides authenticated domain identifiers based on either the 5321.MailFrom [RFC5321] domain or, if the 5321.MailFrom address is absent (as in the case of "bounces"), the domain found in the HELO/EHLO SMTP command. More often than not operators have not put an SPF record on domains found in the HELO/EHLO SMTP command and when present, it could be difficult to change this domain to the domain in the 5322.From, especially when several mail streams share the same sending IP address.
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.
When a message has been transmitted through a forwarder, there will be no such relationship. With SPF, the domain of the 5321.MailFrom or 5321.HELO/EHLO must match that of the 5322.From. Because forwarders generally do not modify the 5322.From, this test will fail. Thus a DMARC implementation must rely on DKIM, if available, in these cases.
Modification of email content invalidates most DKIM signatures. While DKIM provides a length flag so that content can be appended (See Section 8.2 of RFC6376 [RFC6376] for additional discussion), in practice, particularly with MIME-encoded messages, a mailing list processor will do more than append (See Section 5.3 of [RFC5598] for details).
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 fulfill the purpose of 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 5322.From header 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 domain identifiers related to the domain found in the 5322.From header. 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 5322.From header 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 modifying the domain present in a message's 5322.From header. Examples of this issue include:
MTAs relay a message until the message reaches a destination MDA.
An MTA may change the message encoding. For instance it may convert 8bits mail sections to quoted-printable 7bits sections, or just change the character set from US-ASCII to ISO-8859-4. Such transformations invalidate any present DKIM signature.
To keep its reputation, an MTA that transfers message, may block or otherwise remove harmful content from messages that are likely to be unwanted by the next MTA. Any such modifications would invalidate a DKIM signature.
A DMARC interoperability issue arises in the context of Email Address Internationalization [RFC6530]. [RFC6854] allows group syntax in the 5322.From header during the transition period to SMTPUTF8. In the case where an EAI/SMTPUTF8-aware MTA relays a message to a non-aware MTA, the EAI/SMTPUTF8-aware MTA may transform the 5322.From header of the message to include group syntax that allows the non-aware MTA to process the email.
This transformation modifies the content of the message and will invalide any DKIM signatures and possibly remove the ability for the DMARC mechanism to receive an authenticated domain identifier from a DKIM module.
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 domain identifiers as inputs to the DMARC mechanism.
Descriptions of Mediators are largely imported from [RFC5598].
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, as Mediators represent a class of transformations that mirror the concept of "indirect email flows".
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 alternate addresses.
Aliases can be implemented by mailbox-level forwarding (e.g. through "dot-forwarding") or SIEVE-level forwarding (through the SIEVE 'redirect' action). When an Alias preserves message content, DKIM signatures may remain valid. However, Aliases extend the delivery path beyond SPF's ability to grant authorization.
Examples of Aliasing include:
A fundamental challenge in dealing with workarounds involving Aliases is that in many instances, the aMSA has no administrative relationship to the ADMD of the alias. Another challenge is that the underlying mechanisms upon which DMARC relies do not consider the local-part of the addr-spec. While normally considered a perfectly reasonable scaling feature, the underlying assumption is that Authors will make use of aMSAs that are always authorized for a given domain. For vanity domains, this assumption turns out to not hold.
ReSenders "splice" a message's addressing information to connect the Author of the original message with the Recipient 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 alignement is removed as the new Recipient receives the message from the Mediator.
Without an ability to produce authenticated domain identifiers relevant to the Author's 5322.From 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 calendering 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], plus the following:
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 interopreability 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 companies domains by rewriting messages to use the domain of the acquiring company.
To enforce security boundaries, organizations can subject messages to analysis for conformance with its 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.
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 organisation the message may passes through various MTAs [mta] that performs each one a different function, authentication, filtering, distribution,...
Solutions to interoperability issues between DMARC and indirect email flows vary from improving of underlying processors, such as proper handling multiple DKIM signatures, to more radical approaches to the messaging architecture. This section decribes possible ways to address interoperability issues.
Through external knowledge it may be possible to determinine that the DMARC mechanism cannot be applied to a particular message because modification and/or forwarding is to be expected through the normal course of operations for a given sender. This is known as an "override".
In the case of forwarders, identity alignment poses a substantial concern. A receiving ADMD may track subscriptions to mailing lists, so that different processing may be applied to those messages.
Various proposals have been submitted to provide either some form of transitive trust between an email sender, a realy and an email receiver, or to allow a modified version of DKIM to survive light transformation to the message:
Message modification invalidates DKIM signatures and complicates a receiver's ability to generate authenticated domain identifiers from a message. It is therefore important to review the MTAs [mta] configuration to ensure no modification of the message is done when simply forwarding the message. Furthermore Filters should not add to or modify the body of the message, but either rejecting the message or adding email headers to indicate the result of the filter.
Forwarding messages without modification is referred to as "transparent forwarding", and is a way to preserve the validity of DKIM signatures.
The X-Original-From header is used in various contexts.
Note that Original-From is merely adding complexity to the 'who was the author of this message' assessment, very possibly creating yet-another security hole.
Mentioned in early drafts [I-D.kucherawy-original-authres] as a way to pass along Original Authentication Results to "downstream" receivers.
There is very little reason to modify the encoding of the message, compatibility issues between international character sets are few nowadays. No modification of the message should be done when simply forwarding the message.
Filters should not add to or modify the body of the message, but either should reject the message or add new email headers (not under DKIM) to indicate the result of the filter.
The postmaster will choose the solution best for its users but really to avoid DMARC not finding a single useable domain in the 5322.From, the real solution is to upgrade your MTAs, if you want to do DMARC, to support EAI (SMTPUTF8) so that the group syntax in the 5322.From is not needed for interoperability issues during transition, and such syntax be considered at least as suspicious when present.
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.
In practice a number of operators are using strict alignement mode in DMARC in order to avoid receiving new and innovative forms of unwanted and unauthentic mail 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 5322.From. 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 third party signatures.
No IANA considerations.
No Security considerations.
Miles Fidelman, John Levine, David Crocker, Stephen J. Turnbull, Rolf E. Sonneveld, Tim Dragen and Franck Martin contributed to the IETF DMARC Working Group's wiki page listing all known interoperability issues with DMARC and indirect mail flows.
Tim Draegen created the first draft of this document from these contributions and by carefully mapping contributions into the language of [RFC5598].
| [RFC5228] | Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008. |
| [RFC5321] | Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. |
| [RFC5322] | Resnick, P., "Internet Message Format", RFC 5322, October 2008. |
| [RFC5598] | Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009. |
| [RFC6376] | Crocker, D., Hansen, T. and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011. |
| [RFC6530] | Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, February 2012. |
| [RFC6541] | Kucherawy, M., "DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures", RFC 6541, February 2012. |
| [RFC6854] | Leiba, B., "Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields", RFC 6854, March 2013. |
| [RFC7208] | Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, April 2014. |
| [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-dmarc-base] | Kucherawy, M. and E. Zwicky, "Domain-based Message Authentication, Reporting and Conformance (DMARC)", Internet-Draft draft-kucherawy-dmarc-base-11, January 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. |