draft-ietf-dmarc-interoperability-04.txt   draft-ietf-dmarc-interoperability-05.txt 
DMARC Working Group F. Martin, Ed. DMARC F. Martin, Ed.
Internet-Draft LinkedIn Internet-Draft LinkedIn
Intended status: Informational E. Lear, Ed. Intended status: Informational E. Lear, Ed.
Expires: December 11, 2015 Cisco Systems GmbH Expires: February 18, 2016 Cisco Systems GmbH
T. Draegen, Ed. T. Draegen, Ed.
Eudaemonic Development LLC dmarcian, inc.
E. Zwicky, Ed. E. Zwicky, Ed.
Yahoo Yahoo
June 9, 2015 K. Andersen, Ed.
LinkedIn
August 17, 2015
Interoperability Issues Between DMARC and Indirect Email Flows Interoperability Issues Between DMARC and Indirect Email Flows
draft-ietf-dmarc-interoperability-04 draft-ietf-dmarc-interoperability-05
Abstract Abstract
DMARC introduces a mechanism for expressing domain-level policies and DMARC introduces a mechanism for expressing domain-level policies and
preferences for email message validation, disposition, and reporting. preferences for email message validation, disposition, and reporting.
The DMARC mechanism can encounter interoperability issues when The DMARC mechanism can encounter interoperability issues when
messages do not flow directly from the author's administrative domain messages do not flow directly from the author's administrative domain
to the final recipients. Collectively these email flows are referred to the final recipients. Collectively these email flows are referred
to as indirect email flows. This document describes interoperability to as indirect email flows. This document describes interoperability
issues between DMARC and indirect email flows. Possible methods for issues between DMARC and indirect email flows. Possible methods for
skipping to change at page 1, line 42 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 11, 2015. This Internet-Draft will expire on February 18, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Document Conventions . . . . . . . . . . . . . . . . . . 3 1.1. Document Conventions . . . . . . . . . . . . . . . . . . 4
2. Causes of Interoperability Issues . . . . . . . . . . . . . . 3 2. Causes of Interoperability Issues . . . . . . . . . . . . . . 4
2.1. Originator vs Receiver Perspective . . . . . . . . . . . 4 2.1. Identifier Alignment . . . . . . . . . . . . . . . . . . 4
2.2. Identifier Alignment . . . . . . . . . . . . . . . . . . 4 2.2. Message Forwarding . . . . . . . . . . . . . . . . . . . 5
2.3. Message Forwarding . . . . . . . . . . . . . . . . . . . 5 2.3. Message Modification . . . . . . . . . . . . . . . . . . 6
2.4. Message Modification . . . . . . . . . . . . . . . . . . 5
3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 6 3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 6
3.1. Message Handling System . . . . . . . . . . . . . . . . . 6 3.1. Message Handling System . . . . . . . . . . . . . . . . . 7
3.1.1. Message Submission Agents . . . . . . . . . . . . . . 6 3.1.1. Message Submission Agents . . . . . . . . . . . . . . 7
3.1.2. Message Transfer Agents . . . . . . . . . . . . . . . 7 3.1.2. Message Transfer Agents . . . . . . . . . . . . . . . 8
3.1.2.1. Message Encoding . . . . . . . . . . . . . . . . 7 3.1.2.1. Message Encoding . . . . . . . . . . . . . . . . 8
3.1.2.2. Header Standardization . . . . . . . . . . . . . 8 3.1.2.2. Header Standardization . . . . . . . . . . . . . 8
3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 8 3.1.2.3. Content Validation . . . . . . . . . . . . . . . 9
3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 9
3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 10 3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 10
3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 11 3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 11
3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 11 3.2.3.1. Mailing List Operational Effects . . . . . . . . 11
3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 12 3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 12
4. Possible Mitigations of Interoperability Issues . . . . . . . 12 3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 12
4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 13 3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 13 4. Possible Mitigations of Interoperability Issues . . . . . . . 13
4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 13 4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 14
4.1.1.2. Message Modification . . . . . . . . . . . . . . 13 4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 14
4.1.2. Mitigations for Receivers . . . . . . . . . . . . . . 14 4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 15
4.1.2.1. Identifier Alignment . . . . . . . . . . . . . . 14 4.1.1.2. Message Modification . . . . . . . . . . . . . . 15
4.1.2.2. Policy Override . . . . . . . . . . . . . . . . . 14 4.1.2. Mitigations for Receivers . . . . . . . . . . . . . . 16
4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 14 4.1.2.1. Identifier Alignment . . . . . . . . . . . . . . 16
4.1.3.1. Changes to the RFC5322.From . . . . . . . . . . . 14 4.1.2.2. Policy Override . . . . . . . . . . . . . . . . . 16
4.1.3.2. Avoiding Message Modification . . . . . . . . . . 14 4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 16
4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 15 4.1.3.1. Changes to the RFC5322.From . . . . . . . . . . . 16
4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 16 4.1.3.2. Avoiding Message Modification . . . . . . . . . . 16
4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 17
4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 18
4.2.1. Getting More Radical: Requiring New Communication 4.2.1. Getting More Radical: Requiring New Communication
Paths Between MUAs . . . . . . . . . . . . . . . . . 17 Paths Between MUAs . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
DMARC [RFC7489] introduces a mechanism for expressing domain-level DMARC [RFC7489] introduces a mechanism for expressing domain-level
policies and preferences for message validation, disposition, and policies and preferences for message validation, disposition, and
reporting. The DMARC mechanism can encounter several different types reporting. The DMARC mechanism can encounter several different types
of interoperability issues due to third-party message sourcing, of interoperability issues due to third-party message sourcing,
message transformation or rerouting. message transformation or rerouting.
DMARC is, as this writing, an Informational RFC, however it has a At the time of the writing of this document, the DMARC base
specification is published as an Informational RFC and has seen
significant deployment within the email community. significant deployment within the email community.
Cases in which email does not flow directly from the author's Cases in which email does not flow directly from the author's
administrative domain to the recipients are collectively referred to administrative domain to the recipient's domain(s) are collectively
in this document as indirect email flows. Due to existing and referred to in this document as indirect email flows. Due to
increasing adoption of DMARC, the impact of DMARC-based email existing and increasing adoption of DMARC, the impact of DMARC-based
rejection policies on both direct and indirect email flows can be email rejection policies on email flows can be significant for a
significant. select subset of general email traffic.
Several known causes of interoperability issues are presented, Several known causes of interoperability issues are presented,
followed by a description of components within the Internet Mail followed by a description of components within the Internet Mail
Architecture [RFC5598] where interoperability issues can arise. Architecture [RFC5598] where interoperability issues can arise.
Lastly, known and possible methods for addressing interoperability Finally, known and possible methods for addressing interoperability
issues are presented. There are often multiple ways to address any issues are presented. There are often multiple ways to address any
given interoperability issue. While this document strives to be given interoperability issue. While this document strives to be
comprehensive in its review, it should not be treated as complete. comprehensive in its review, it should not be treated as complete.
Also, some practices which are in use at the time of this document
may or may not be "best practices" as future standards evolve.
1.1. Document Conventions 1.1. Document Conventions
Notation regarding structured fields is taken from [RFC5598]. Notation regarding structured fields is taken from [RFC5598].
Organizational Domain and Authenticated Identifiers are specified in Organizational Domain and Authenticated Identifiers are specified in
DMARC [RFC7489]. DMARC [RFC7489].
2. Causes of Interoperability Issues 2. Causes of Interoperability Issues
Interoperability issues between DMARC and indirect email flows arise Interoperability issues between DMARC and indirect email flows arise
when conformance to the DMARC specification leads an implementation when conformance to the DMARC specification leads a receiving
to apply DMARC based policy to messages that are both compliant with implementation to apply DMARC based policy restrictions to messages
the architecture as specified in [RFC5598] and viewed as legitimate that are both compliant with the architecture as specified in
by the intended recipient. To be clear, this document does not [RFC5598] and viewed as legitimate by the intended recipient.
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.
2.1. Originator vs Receiver Perspective
Some Receivers are concerned that wanted email messages are received, Note that domains which assert a p=None policy and email which passes
regardless if such email messages are not strictly in conformance to standard DMARC validation do not have any interoperability issues.
any standard or protocol.
Some Originators, particularly for high value transactional messages, Email messages that do not conform to other email specifications but
want the message discarded if it passes through an intermediary and are considered legitimate by the intended recipients are not
is modified in any way resulting in a failure to validate. Examples discussed in this document. The rest of this section describes
of such messages include those related to financial organizations and several conceptual causes of interoperability issues.
medical establishments.
2.2. Identifier Alignment 2.1. Identifier Alignment
DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform message DMARC relies on DKIM [RFC6376] and SPF [RFC7208] to perform message
source validation. The DMARC [RFC7489] mechanism refers to source source validation. The DMARC [RFC7489] mechanism refers to source
domains that are validated by DKIM or SPF as Authenticated domains that are validated by DKIM or SPF as Authenticated
Identifiers. DMARC requires an Authenticated Identifier to be Identifiers. DMARC requires an Authenticated Identifier to be
relevant to the domain found in the message's RFC5322.From header related to the domain found in the message's RFC5322.From header
field [RFC5322]. This relevancy is referred to as Identifier field [RFC5322]. This relationship is referred to as Identifier
Alignment. Alignment.
Identifier Alignment can be strict, where the domains exactly match DMARC allows for Identifier Alignment to be achieved in two different
each others, or relaxed where the domains are part of the same modes: strict and relaxed. Strict mode requires an exact match of
Organizational Domain. There are, in general, the same either of the Authenticated Identifiers to the message's RFC5322.From
interoperability issues between strict and relaxed alignment, however header field [RFC5322]. Relaxed mode allows for Identifier Alignment
in strict mode the possible solutions are more constrained when if Authenticated Identifiers and the message's RFC5322.From header
possible. This Document mainly implies relaxed Identifier Alignment. 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.
DKIM provides a cryptographic means for a domain to be associated DKIM provides a cryptographic means for a domain identifier to be
with a particular message. DKIM does not make any constraints on associated with a particular message. As a standalone technology
what domains may or must present this association. However, for a DKIM identifiers are not required to be relevant to the content of a
DKIM identifier to align in DMARC, the signing domain of a valid message. However, for a DKIM identifier to align in DMARC, the
signature must be part of the same Organizational Domain as the signing domain of a valid signature must be part of the same
domain in the RFC5322.From header field [RFC5322]. Organizational Domain as the domain in the RFC5322.From header field
[RFC5322].
In addition, DKIM allows for the possibility of multiple valid In addition, DKIM allows for the possibility of multiple valid
signatures. The DMARC mechanism will process Authenticated signatures. The DMARC mechanism will process Authenticated
Identifiers that are based on DKIM signatures until an aligned Identifiers that are based on DKIM signatures until an aligned
Authenticated Identifier is found (if any). However, operational Authenticated Identifier is found (if any). However, operational
experience has shown that some implementations have difficulty experience has shown that some implementations have difficulty
processing multiple signatures. The impact on DMARC processing is processing multiple signatures. The impact on DMARC processing is
clear: implementations that cannot process multiple DKIM signatures clear: implementations that cannot process multiple DKIM signatures
may erroneously apply DMARC based policy to otherwise legitimate may incorrectly flag messages as "failing DMARC" and erroneously
messages. apply DMARC based policy to otherwise conforming messages.
SPF can provide two Authenticated Identifiers based on two different SPF can provide two Authenticated Identifiers. The first one is the
SPF identities: RFC7208.HELO [RFC7208] and RFC7208.MAILFROM RFC7208.HELO [RFC7208] based on the RFC5321.HELO/EHLO. The second
[RFC7208]. DMARC uses only the RFC7208.MAILFROM identifier for one is the RFC7208.MAILFROM [RFC7208] based on the RFC5321.MailFrom
alignment. The SPF validated domain in RFC7208.MAILFROM must be part [RFC5321] domain, or, if the RFC5321.MailFrom address is absent (as
of the same Organizational Domain as the domain in the RFC5322.From in the case of "bounce" messages, on the domain found in the HELO/
header field to be aligned. It is important to note that even when EHLO SMTP command. DMARC uses only the SPF results for the
an SPF record exists for the domain in RFC5322.From, SPF will not RFC7208.MAILFROM identifier for alignment (this is often true for
authenticate it unless it is also the domain in RFC7208.MAILFROM, local policies outside of DMARC as well). The SPF validated domain
furthermore, RFC7208.MAILFROM definition is different from in RFC7208.MAILFROM must be part of the same Organizational Domain as
RFC5321.MailFrom [RFC5321] definition. 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. The RFC7208.MAILFROM definition has not
changed from the RFC4408.MAILFROM [RFC4408] definition, the earlier
version of the SPF specification, however, not all implementations
have updated to the [RFC7208] algorithm which can lead to unexpected
results.
2.3. Message Forwarding 2.2. Message Forwarding
Message forwarding is a generic concept encapsulating a variety of Message forwarding is a generic concept encapsulating a variety of
behaviors. Section 3 describes forwarding behavior as it relates to behaviors. Section 3 describes forwarding behavior as it relates to
the components of the Internet Mail Architecture. the components of the Internet Mail Architecture.
All of these behaviors involve email being retransmitted by a new All forwarding behavior involves the retransmission of email. As
SMTP server. As discussed above, for SPF to cause a DMARC pass, the discussed above, in order for SPF to yield an Authenticated
domain of the RFC7208.MAILFROM, must be aligned with that of the Identifier that is pertinent to DMARC, the domain of the
RFC5322.From header field: RFC7208.MAILFROM must be in alignment with the RFC5322.From header
field. Forwarding introduces specific issues to the availability of
SPF-based Authenticated Identifiers:
o If the RFC5321.MailFrom is not empty and if the forwarder keeps o If the RFC5321.MailFrom is present and the forwarder maintains the
the RFC5321.MailFrom, the SPF validation will fail altogether original RFC5321.MailFrom, SPF validation will fail unless the
unless the forwarder is an authorized part of the originator's forwarder is an authorized part of the originator's email sending
email sending infrastructure. On another hand, if the forwarder infrastructure. If the forwarder replaces the RFC5321.MailFrom
uses its own domain in the RFC5321.MailFrom, SPF passes but the with its own domain, SPF may pass but Identifier Alignment with
alignment with the RFC5322.From header field fails. the RFC5322.From header field will fail.
o If the RFC5321.MailFrom is empty, the RFC5321.Helo of the o If the RFC5321.MailFrom is empty (as in the case of Delivery
forwarder will likely be in different organizational domain of the Status Notifications), the RFC5321.Helo domain of the forwarder
RFC5322.From. SPF may pass but the alignment with the will likely be in different organizational domain of the
RFC5322.From header field fails. RFC5322.From header field. SPF may pass but Identifier Alignment
with the RFC5322.From header field fails.
In either case, SPF cannot produce a DMARC pass, and DKIM will be In both cases, SPF cannot yield relevant Authenticated Identifiers,
required to get DMARC to pass. and DKIM must be relied upon to produce results that are relevant to
DMARC.
2.4. Message Modification 2.3. Message Modification
Modification of email content invalidates most DKIM signatures, and Modification of email content invalidates most DKIM signatures, and
many message forwarding systems modify email content. Mailing list many message forwarding systems modify email content. Mailing list
processors are the most common example of such systems, but other processors are a common example of such systems, but other forwarding
forwarding systems also make modifications. Although DKIM provides a systems also make modifications.
length flag so that content can be appended (See Section 8.2 of
[RFC6376] for additional security considerations), in practice, Although DKIM provides a length flag so that content can be appended
particularly with MIME-encoded [RFC2045] messages, a mailing list without invalidating the signature, in practice, particularly with
processor will do more than append (See Section 5.3 of [RFC5598] for MIME-encoded [RFC2045] messages, a mailing list processor will do
details). Furthermore, the use of the length flag is seldom found in more than simply append content (see Section 5.3 of [RFC5598] for
emails in part because of its security challenges. details). Furthermore, the length flag is seldom used due to
security issues (see Section 8.2 of [RFC6376] for additional security
considerations).
DKIM has two canonicalizations to use for headers and body DKIM describes two canonicalizations for use when preparing headers
separately: simple and relaxed. The latter allows some modest in and body for DKIM processing: simple and relaxed. The latter allows
transit modifications that do not change the interpretation of the for trivial modifications (largely regarding whitespace folding) that
content of the email. The relaxed canonicalization is more computing maintain the integrity of the content of the email. However, the
intensive and may not have been preferred in the early deployment of relaxed canonicalization is more computationally intensive and may
DKIM as this may have been more significant than today. 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 checkers which
have problems evaluating relaxed canonicalization correctly.
3. Internet Mail Architecture, DMARC, and Indirect Email Flows 3. Internet Mail Architecture, DMARC, and Indirect Email Flows
This section describes components within the Internet Mail This section describes components within the Internet Mail
Architecture [RFC5598] where interoperability issues between DMARC Architecture [RFC5598] where interoperability issues between DMARC
and indirect email flows can be found. and indirect email flows can be found.
3.1. Message Handling System 3.1. Message Handling System
Section 4 of [RFC5598] describes six basic components that make up Section 4 of [RFC5598] describes six basic components that make up
skipping to change at page 6, line 44 skipping to change at page 7, line 25
o Message Transfer Agent (MTA) o Message Transfer Agent (MTA)
o Message Delivery Agent (MDA) o Message Delivery Agent (MDA)
o Message Store (MS) o Message Store (MS)
Of these components MSA, MTA, and MDA are discussed in relation to Of these components MSA, MTA, and MDA are discussed in relation to
interoperability with DMARC. interoperability with DMARC.
A Mediator is a special class of MUA that is given special A Mediator is a hybrid of several component types that is given
consideration in this section due to the unique issues Mediators face special consideration in this section due to the unique issues
when attempting to interoperate with DMARC. Mediators face when attempting to interoperate with DMARC.
3.1.1. Message Submission Agents 3.1.1. Message Submission Agents
An MSA accepts messages submitted by a Message User Agent (MUA) and An MSA accepts messages submitted by a Message User Agent (MUA) and
enforces the policies of the hosting ADministrative Management Domain enforces the policies of the hosting ADministrative Management Domain
(ADMD) and the requirements of Internet standards. (ADMD) and the requirements of Internet standards.
MSAs are split into two sub-components: MSAs are split into two sub-components:
o Author-focused MSA functions (aMSA) o Author-focused MSA functions (aMSA)
skipping to change at page 7, line 24 skipping to change at page 8, line 5
be capable of sending email that yields Authenticated Identifiers be capable of sending email that yields Authenticated Identifiers
aligned with the domain found in the RFC5322.From header field. aligned with the domain found in the RFC5322.From header field.
Examples of this issue include "forward-to-friend" functionality Examples of this issue include "forward-to-friend" functionality
commonly found on news/article websites or "send-as" functionality commonly found on news/article websites or "send-as" functionality
present on some MUAs. present on some MUAs.
When an hMSA takes responsibility for transit of a message containing When an hMSA takes responsibility for transit of a message containing
a domain in the RFC5322.From header field that is outside of the a domain in the RFC5322.From header field that is outside of the
hMSA's ADMD, the hMSA faces DMARC interoperability issues if the hMSA's ADMD, the hMSA faces DMARC interoperability issues if the
domain publishes a DMARC policy of "quarantine" or "reject". These domain publishes a DMARC policy of "quarantine" or "reject". These
issues are marked by an inherent difficulty in establishing alignment issues are marked by the inherent difficulty of establishing
with the domain present in a message's RFC5322.From header field. alignment with the domain present in a message's RFC5322.From header
Examples of this issue include: field. Examples of this issue include:
o Pseudo-open relays - a residential ISP that allows its customers o Pseudo-open relays - a residential ISP that allows its customers
to relay any domains through its infrastructure. to relay non-local domains through its infrastructure.
o Embedded devices - cable/dsl modems, firewalls, wireless access o Embedded devices - cable/DSL modems, firewalls, wireless access
points that send email using hardcoded domains. points, printers that send email using hardcoded domains.
o Email service providers - ESPs that service customers that are o Devices that send mail on behalf of a user - scanners, security
using domains that publish a DMARC "reject" policy. cameras, alarms that send mail as their owner or a device user.
o Email service providers - ESPs that service customers who are
using domains which publish a DMARC "reject" policy.
o Calendaring software - an invited member of an event modifies the o Calendaring software - an invited member of an event modifies the
event causing calendaring software to emit an update that appears event causing calendaring software to emit an update that claims
to come from the creator of the event. to come from the creator of the event.
3.1.2. Message Transfer Agents 3.1.2. Message Transfer Agents
MTAs relay a message until the message reaches a destination MDA. MTAs relay a message until the message reaches a destination MDA.
3.1.2.1. Message Encoding 3.1.2.1. Message Encoding
An MTA may modify the message encoding, for instance by converting An MTA may modify the message encoding, for instance by converting
8-bit MIME sections to quoted-printable 7-bit sections. This 8-bit MIME sections to quoted-printable 7-bit sections. This
modification is outside the scope of DKIM canonicalization and will modification is outside the scope of DKIM canonicalization and will
invalidate DKIM signatures that include message content. invalidate DKIM signatures that include message content.
An MTA may also re-encode the message without changing the encoding
type, receiving a MIME-encoded message and producing a semantically
and syntactically 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 3.1.2.2. Header Standardization
An MTA may standardize headers, usually in order to make non-RFC An MTA may rewrite headers to bring headers into compliance with
compliant headers properly compliant. For instance, some common MTAs existing RFCs. For example, some common MTAs will correct
will correct comprehensible but non-compliant date formats to comprehensible but non-compliant date formats to compliant ones.
compliant ones. This correction is outside the scope of DKIM
canonicalization and will invalidate DKIM signatures. This Header rewriting is outside the scope of DKIM canonicalization and
correction is also outside the scope of this document in providing will invalidate DKIM signatures. All downstream DMARC processing
solutions for non RFC compliant emails. with be unable to utilize DKIM to yield Authenticated Identifiers due
to header rewriting.
Providing solutions for issues relating to non RFC-compliant emails
is outside the scope of this document.
3.1.2.3. Content Validation
An MTA may also implement security-motivated changes to the content
of email messages, dropping or altering sections of messages, causing
breakage of DKIM signatures
3.1.3. Message Delivery Agents 3.1.3. Message Delivery Agents
The MDA transfers a message from the MHS to a mailbox. Like the MSA, The MDA transfers a message from the MHS to a mailbox. Like the MSA,
the MDA consists of two sub-components: the MDA consists of two sub-components:
o MHS-focused MDA functions (hMDA) o MHS-focused MDA functions (hMDA)
o Recipient-focused MDA functions (rMDA) o Recipient-focused MDA functions (rMDA)
Both the hMDA and the rMDA can redirect a message to an alternative Both the hMDA and the rMDA can redirect a message to an alternative
address. DMARC interoperability issues related to redirecting of address. DMARC interoperability issues related to redirecting of
messages are described in Section 3.2. messages are described in Section 3.2.
SIEVE [RFC5228] functionality often lives in the rMDA sub-component SIEVE [RFC5228] functionality often lives in the rMDA sub-component
and can cause DMARC interoperability issues. The SIEVE 'addheader' and can cause DMARC interoperability issues. The SIEVE 'addheader'
and 'deleteheader' filtering actions can modify messages and and 'deleteheader' filtering actions can modify messages and
invalidate DKIM signatures, removing DKIM-supplied Authenticated invalidate DKIM signatures, removing DKIM-supplied Authenticated
Identifiers as inputs to the DMARC mechanism. There are also SIEVE Identifiers as inputs to the DMARC mechanism. There are also SIEVE
extensions that modify the body. SIEVE may only become an issue when extensions that modify the body. SIEVE alterations may only become
the email is reintroduced in the transport infrastructure. an issue when the email is reintroduced into the transport
infrastructure.
3.2. Mediators 3.2. Mediators
See [RFC5598] for a complete definition of Mediators. See [RFC5598] for a complete definition of Mediators.
Mediators forward messages through a re-posting process. Mediators Mediators forward messages through a re-posting process. Mediators
share some functionality with basic MTA relaying, but have greater share some functionality with basic MTA relaying, but have greater
flexibility in both addressing and content modifications. flexibility in both addressing and content modifications.
DMARC interoperability issues are prevalent within the context of DMARC interoperability issues are common within the context of
Mediators, which are often used precisely for their ability to modify Mediators, which are often used precisely for their ability to modify
messages. messages.
3.2.1. Alias 3.2.1. Alias
An Alias is a simple re-addressing facility that provides one or more An Alias is a simple re-addressing facility that provides one or more
new Internet Mail addresses, rather than a single, internal one. A new Internet Mail addresses, rather than a single, internal one. A
message continues through the transfer service for delivery to one or message continues through the transfer service for delivery to one or
more alternative addresses. 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 "dot-forwarding") or SIEVE-level forwarding (through the SIEVE
'redirect' action) or other methods. When an Alias preserves message 'redirect' action) or other methods. When an Alias preserves message
content and does not make significant header changes, DKIM signatures content and does not make significant header changes, DKIM signatures
may remain valid. However, Aliases often extend the delivery path may remain valid. However, Aliases often extend the delivery path
beyond SPF's ability to grant authorization. outside of the scope covered by the originating ADMD's SPF record(s).
Examples of Aliasing include: Examples of Aliasing include:
o Forwarding email between freemail providers to try different o Forwarding email between freemail providers to try different
interfaces while maintaining an original email address. interfaces while maintaining an original email address.
o Consolidating many email addresses into a single acccount to o Consolidating many email addresses into a single account to
centralize processing. centralize processing.
o Services that provides "activity based", "role based" , "vanity" o Services that provide "activity based", "role based" , "vanity" or
or "temporary" email addresses such as universities and "temporary" email addresses such as universities and professional
professional associations. For instance professional or alumni associations. For instance professional or alumni institutions
institutions may offer to their members an alias for the duration may offer their members an alias for the duration of their
of their membership but may not want to deal with the long term membership but may not want to deal with the long term storage of
storage of emails. emails.
In most cases, the aMSA providing Alias services has no In most cases, the aMSA providing Alias services has no
administrative relationship to the ADMD of the final recipient, so administrative relationship to the ADMD of the originator or the
solutions to Alias-related DMARC failure should not assume such a final recipient, so solutions to Alias-related DMARC failure should
relationship. not assume such a relationship.
3.2.2. ReSenders 3.2.2. ReSenders
ReSenders "splice" a message's addressing information to connect the ReSenders "splice" a message's addressing information to connect the
Author of the original message with the Recipient(s) of the new Author of the original message with the Recipient(s) of the new
message. The new Recipient sees the message as being from the message. The new Recipient sees the message as being from the
original Author, even if the Mediator adds commentary. original Author, even if the Mediator adds commentary.
ReSenders introduce DMARC interoperability issues as content ReSenders introduce DMARC interoperability issues as content
modification invalidates DKIM signatures. SPF's ability to grant modification invalidates DKIM signatures. SPF's ability to grant
authorization via alignment is removed as the new Recipient receives authorization via alignment is removed as the new Recipient receives
the message from the Mediator. the message from the Mediator rather than the initial organization.
Without an ability to produce Authenticated Identifiers relevant to Without Authenticated Identifiers aligned with the Author's
the Author's RFC5322.From header field domain using either DKIM or RFC5322.From header field domain, the new Recipient has no way to
SPF, the new Recipient has almost no chance of successfully applying achieve a passing DMARC evaluation.
the DMARC mechanism.
Examples of ReSenders include MUA-level forwarding by resending a Examples of ReSenders include MUA-level forwarding by resending a
message to a new recipient or by forwarding a message "inline" to 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 new recipient (this does not include forwarding a message "as an
attachment"). An additional example comes in the form of calendaring attachment"). An additional example comes in the form of calendaring
software that allows a meeting attendee (not the meeting organizer) software that allows a meeting attendee (not the meeting organizer)
to modify the content of an invite causing the invitations to appear to modify the content of an invite generating new invitations that
to be reissued from the meeting organizer. claim to be reissued from the meeting organizer.
3.2.3. Mailing Lists 3.2.3. Mailing Lists
A Mailing List receives messages as an explicit addressee and then A Mailing List receives messages as an explicit addressee and then
re-posts them to a list of subscribed members. The Mailing List reposts them to a list of subscribed members. The Mailing List
performs a task that can be viewed as an elaboration of the ReSender. performs a task that can be viewed as an elaboration of the ReSender
actions.
Mailing Lists share the same DMARC interoperability issues as Mailing Lists share the same DMARC interoperability issues as
ReSenders (Section 3.2.2), and very commonly modify headers or ReSenders (Section 3.2.2), and very commonly modify headers or
message content in ways that will cause DKIM to fail, including: message content in ways that will cause DKIM to fail, including:
o prepending the RFC5322.Subject header field with a tag, to allow o prepending the RFC5322.Subject header field with a tag, to allow
the receiver to identify visually the mailing list. the recipient to easily identify the mailing list within a subject
line listing.
o adding a footer to the email body to contain administrative o adding a footer to the email body to contain administrative
instructions. instructions.
o removing some MIME-parts from the email or converting the message o removing some MIME-parts from the email or converting the message
to text only. to text only.
o PGP-encrypting or S/MIME encrypting the body to the receiver's o PGP-encrypting or S/MIME encrypting the body with the receiver's
key. key.
o enforcing community standards by rewriting banned words. o enforcing community standards by rewriting banned words.
o allowing moderators to add arbitrary commentary to messages. o allowing moderators to add arbitrary commentary to messages.
Any such modifications would invalidate a DKIM signature. Any such modifications would invalidate a DKIM signature.
Header and content modifications are common for many mailing lists
and are often central to present mailing list functionality and
usage. Furthermore, MUAs have come to rely on mailing list message
modifications to present messages to end users in expected ways.
3.2.3.1. Mailing List Operational Effects
Mailing Lists may also have the following DMARC interoperability Mailing Lists may also have the following DMARC interoperability
issues: issues:
o Subscribed members may not receive email from members that post o Subscribed members may not receive email from members that post
using domains that publish a DMARC "p=reject" policy. using domains that publish a DMARC "p=reject" policy.
o Mailing Lists may interpret DMARC-related email rejection as an o Mailing Lists may interpret DMARC-related email rejections as an
inability to deliver email to the recipients that are checking and inability to deliver email to the recipients that are checking and
enforcing DMARC policy. This processing may cause subscribed enforcing DMARC policy. This processing may cause subscribers
members to be suspended or removed from the Mailing List. that are checking and enforcing DMARC policy to be inadvertently
suspended or removed from the Mailing List.
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
3.2.4. Gateways 3.2.4. Gateways
A Gateway performs the basic routing and transfer work of message A Gateway performs the basic routing and transfer work of message
relaying, but it also is permitted to modify content, structure, relaying, but it also is permitted to modify content, structure,
address, or attributes as needed to send the message into a messaging addressing, and/or other attributes as needed to send the message
environment that operates under different standards or potentially into a messaging environment that operates under different standards
incompatible policies. or potentially incompatible policies.
Gateways share the same DMARC interoperability issues as ReSenders Gateways share the same DMARC interoperability issues as ReSenders
(Section 3.2.2). (Section 3.2.2).
Gateways may share also the same DMARC interoperability issues as Gateways may share also the same DMARC interoperability issues as
MTAs (Section 3.1.2). 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 Gateway-level forwarding can introduce DMARC interoperability issues
if the Gateway is configured to rewrite the message to map between if the Gateway is configured to rewrite the message into alternate
recipient domains. For example, an acquisition may lead the recipient domains. For example, an acquisition may lead an acquiring
acquiring company to decide to decommission the acquired company's company to decide to decommission the acquired company's domains by
domains by rewriting messages to use the domain of the acquiring rewriting messages to use the domain of the acquiring company. Since
company. Since the RFC5322.To header field is usually DKIM-signed, the RFC5322.To header field is usually DKIM-signed, this kind of
this kind of rewriting will also cause DKIM signatures to fail. rewriting will invalidate such DKIM signatures.
3.2.5. Boundary Filters 3.2.5. Boundary Filters
To enforce security boundaries, organizations can subject messages to To enforce security boundaries, organizations can subject messages to
analysis for conformance with their safety policies. A filter might analysis for conformance with their safety policies. A filter might
alter the content to render it safe, such as by removing content alter the content to render it safe, such as by removing or otherwise
deemed unacceptable. altering content deemed unacceptable.
Boundary Filters share the same DMARC interoperability issues as Boundary Filters share the same DMARC interoperability issues as
ReSenders. ReSenders.
Issues may arise if SPF and DKIM is evaluated after the filter Issues may arise with SPF and DKIM evaluation if performed after
modifications. filter modifications.
Examples of Boundary Filters include: Examples of Boundary Filters include:
o Anti-spam: To keep its reputation, an MTA that transfers a message o Malware scanning: To protect readers and its reputation, an MTA
may remove harmful content from messages that are likely to be that transfers a message may remove content believed to be harmful
unwanted by the next MTA and/or add text in the body to indicate from messages, reformulate content to canonical formats in order
the message has been scanned. Any such modifications would to make them more trustworthy or easier to scan, and/or add text
invalidate a DKIM signature. in the body to indicate the message has been scanned. Any such
modifications would invalidate a DKIM signature.
o Any service that reformulates the RFC5322.body for any other o Spam filtering: To protect reputation and assist other MTAs, an
reason, for instance adding an organizational disclaimer. MTA may modify a message to indicate its decision that the message
is likely to be unwanted, and/or add text in the body to indicate
that such filtering has been done.
o Secondary MX services. In this case, however, it is inappropriate o Other text additions: An MTA may add an organizational disclaimer
for a primary MX server to perform an SPF check against its own or advertisement, for instance.
secondaries. Rather, the secondary MX should perform this
function. 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)
to the primary MX server.
3.3. Combinations 3.3. Combinations
The causes of indirect email flows can be combined. For example, a Indirect email flows can be combined. For example, a university
university student may subscribe to a mailing list (using his student may subscribe to a mailing list (using his university email
university email address) while this university email address is address) while this university email address is configured to forward
configured to forward all emails to a freemail provider where a more all emails to a freemail or a post-education corporate account
permanent email address for this student exists. provider where a more permanent email address for this student
exists.
Within an organization the message may pass through various MTAs Within an organization the message may pass through various MTAs
(Section 3.1.2), each of which performs a different function (Section 3.1.2), each of which performs a different function
(authentication, filtering, distribution, etc.) (authentication, filtering, distribution, etc.)
4. Possible Mitigations of Interoperability Issues 4. Possible Mitigations of Interoperability Issues
Solutions to interoperability issues between DMARC and indirect email Solutions to interoperability issues between DMARC and indirect email
flows vary widely in their scope and implications. They range from flows vary widely in their scope and implications. They range from
improvements to underlying processors, such as proper handling of improvements to underlying processors, such as proper handling of
multiple DKIM signatures, to more radical approaches to the messaging multiple DKIM signatures, to more radical changes to the messaging
architecture. This section describes possible ways to address architecture. This section describes possible ways to address
interoperability issues. interoperability issues. Note that these particular mechanisms may
not be considered "best practices" and may, in some cases, violate
various conventions or expectations.
Mail systems are diverse and widely deployed and are expected to Receivers sometimes need to deliver email messages that do not
continue to work with old systems. For instance, Qmail is still used conform to any standard or protocol, but are otherwise desired by end
and the base code has not been updated since 1998. Ezmlm, a once users. Mitigating the impact of DMARC on indirect email flows is
popular mailing list manager, is still deployed and has not been especially important to receivers that operate services where ease of
updated since 1997, although a new version, Ezmlm-idx exists. In use and compatibility with existing email flows is a priority.
this constrained environment, some solutions may be time-consuming
and/or disruptive to implement.
DMARC provides for receivers to make decisions about identity DMARC provides a mechanism (local policy) for receivers to make
alignment acceptability based on information outside DMARC and decisions about identity alignment acceptability based on information
communicate those decisions as "overrides" to the sender. This outside DMARC and communicate those decisions as "overrides" to the
facility can be used to ease some interoperability issues, although sender. This facility can be used to ease some interoperability
care is needed to ensure that this does not create loopholes that issues, although care is needed to ensure that this does not create
abusers can use arbitrarily. 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).
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 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. 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 disruptive to
implement.
4.1. Mitigations in Current Use 4.1. Mitigations in Current Use
At many places where DMARC is already deployed, mitigations are in Because DMARC is already widely deployed, many operators already have
use. These mitigations vary in their effectiveness and side effects, mitigations in use. These mitigations vary in their effectiveness
but have the advantage that they are currently available. and side effects, but have the advantage that they are currently
available.
4.1.1. Mitigations for Senders 4.1.1. Mitigations for Senders
4.1.1.1. Identifier Alignment 4.1.1.1. Identifier Alignment
o MTAs handling multiple domains may choose to change o MTAs handling multiple domains may choose to change
RFC5321.MailFrom to align with RFC5322.From to improve SPF RFC5321.MailFrom to align with RFC5322.From to improve SPF
usability for DMARC. usability for DMARC.
o MTAs handling multiple domains may also choose to align o MTAs handling multiple domains may also choose to align
RFC5321.HELO/EHLO to RFC5322.From, particularly when sending RFC5321.HELO/EHLO to RFC5322.From, particularly when sending
bounce messages. Adjusting dynamically the RFC5321.HELO based on bounce messages. Dynamically adjusting the RFC5321.HELO based on
the RFC5322.From may not be possible for some MTA software. the RFC5322.From may not be possible for some MTA software.
o MTAs may choose to DKIM sign bounces with an aligned domain to o MTAs may choose to DKIM sign bounces with an aligned domain to
allow DKIM-based DMARC pass. allow DKIM-based DMARC pass.
o MTAs handling multiple domains may require DMARC-using senders to o MTAs sending email on behalf of multiple domains may require
provide DKIM keys and use DKIM to avoid SPF alignment issues. Domain Owners to provide DKIM keys to use DKIM to avoid SPF
Handling DKIM keys with a third party has its security challenges. alignment issues. Managing DKIM keys with a third party has
security risks which should be carefully managed.
o Senders who are sending on behalf of users in other Administrative o Senders who are sending on behalf of users in other Administrative
Domains may choose to use an RFC5322.From under the sender's Domains may choose to use an RFC5322.From under the sender's
control. The new From can be either a forwarding address in a control. The new From can be either a forwarding address in a
domain controlled by the Sender, or a placeholder address, with 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 a RFC5322.Reply-to header field.
However this may affect what the recipient expects in its MUA. However, performing this modification may cause the recipient's
MUA to deviate from customary behavior.
o Senders can use different domains with different DMARC policies o Senders can use domains with distinct DMARC policies for email
for email sent directly and email known to use indirect mail flow. sent directly and email known to use indirect mail flows.
However for known brands, all active domains are likely to be However, for known brands, all active domains are likely to be
targeted equally by abusers. targeted equally by abusers.
4.1.1.2. Message Modification 4.1.1.2. Message Modification
o Senders can maximize survivability of DKIM signatures by limiting o Senders can maximize survivability of DKIM signatures by limiting
the header fields they sign, using relaxed canonicalization and by the header fields they sign and using relaxed canonicalization.
using length to allow appended signatures. Using the DKIM length tag to allow appended signatures is
discouraged due to the security risk created by allowing arbitrary
content to be appended to legitimate email.
o Senders can also maximize survivability by starting with RFC- o Senders can also maximize survivability by starting with RFC-
compliant headers and common body formats. compliant headers and common body formats.
o In order to minimize the chances of transport conversions, Senders o In order to minimize transport-based conversions, Senders can
can convert the message to a suitable MIME content-transfer convert messages to a lowest denominator MIME content-transfer
encoding such as quoted-printable or base64 before signing encoding such as quoted-printable or base64 before signing
([RFC6376] Section 5.3). ([RFC6376] Section 5.3).
4.1.2. Mitigations for Receivers 4.1.2. Mitigations for Receivers
4.1.2.1. Identifier Alignment 4.1.2.1. Identifier Alignment
o Receivers should update DKIM handling libraries to ensure that o Receivers should update DKIM handling libraries to ensure that
they process all valid DKIM signatures and check them for they process all valid DKIM signatures and check each signature
alignment. for alignment.
4.1.2.2. Policy Override 4.1.2.2. Policy Override
o Receivers can amalgamate data from their user base to identify o Receivers can amalgamate data from their user base to create lists
forwarders and use such list for a DMARC local policy override. of forwarders and use such lists to inform DMARC local policy
This process may be easier for large receivers, where there is overrides. This process may be easier for large receivers where
data and resources to create such lists, than for small receivers. data and resources to create such lists are more readily available
than at smaller sites where the recipient footprint and other
resources may be scarce.
4.1.3. Mitigations for ReSenders 4.1.3. Mitigations for ReSenders
4.1.3.1. Changes to the RFC5322.From 4.1.3.1. Changes to the RFC5322.From
Many ReSender issues can be avoided by using an RFC5322.From header Many ReSender issues can be avoided by using an RFC5322.From header
field under the ReSender's control, instead of the initial field under the ReSender's control, instead of the initial
RFC5322.From. This will correct identifier alignment issues and RFC5322.From. This will correct identifier alignment issues and
allow arbitrary message modification, for instance. When ReSenders allow arbitrary message modification as long as the ReSender signs
change the RFC5322.From, it is desirable to preserve the information the message with an aligned domain signature. When ReSenders change
about the original initiator of the message. 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- A first option is to use the Original-From [RFC5703] (or X-Original-
From) header field for this purpose in various contexts (X- header From) header field for this purpose in various contexts (X- header
fields name are discouraged by [RFC6648]). However, handling of fields name are discouraged by [RFC6648]). However, handling of
Original-From (or X-Original-From) is not defined anywhere. It is Original-From (or X-Original-From) is not defined anywhere. It is
not currently used consistently or displayed to the user, but in any not currently used consistently or displayed to the user, and in any
situation where it is used, it is a new unauthenticated identifier situation where it is used, it is a new unauthenticated identifier
available for exploitation. 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 Another option for ReSenders is to rewrite the RFC5322.From header
field address to a valid forwarding address to the original sender, field address to a locally controlled address which will be forwarded
in a domain that the ReSender controls. back to the original sender (subject to its own ReSender forwarding
mitigations!).
4.1.3.2. Avoiding Message Modification 4.1.3.2. Avoiding Message Modification
o Forwarders can choose to add email header fields instead of o Forwarders can choose to add email header fields instead of
modifying existing headers or bodies, for instance to indicate a modifying existing headers or bodies, for instance to indicate a
message may be spam. message may be spam.
o Forwarders can minimize the circumstances in which they choose to o Forwarders can minimize the circumstances in which they choose to
fix messages, preferring to preserve non-compliant headers to fix messages, preferring to preserve non-compliant headers to
creating DKIM failures. creating DKIM failures.
o Forwarders can choose to reject messages with suspect or harmful o Forwarders can choose to reject messages with suspect or harmful
content instead of modifying them. content instead of modifying them.
4.1.3.3. Mailing Lists 4.1.3.3. Mailing Lists
[RFC6377] provides some guidance on using DKIM with Mailing lists. [RFC6377] provides some guidance on using DKIM with Mailing lists.
Here are some remediation techniques on using DMARC with Mailing The following mitigation techniques can be used to ease
lists: interoperability issues with DMARC and Mailing lists:
o One mitigation policy, which is now present on several Mailing o Configuring the Mailing List Manager (MLM) to alter the
List software, is to configure the Mailing List Manager (MLM) to RFC5322.From header field to use the domain of the MLM is a
alter the RFC5322.From header field to use the domain of the MLM. mitigation policy which is now present in several different
Since most list subscribers prefer to know the identity of the Mailing List software distributions. Since most list subscribers
author of the original message, typically this information may be prefer to know the identity of the author of the original message,
provided in the display name part of the RFC5322.From header typically this information may be provided in the display name
field. This display name needs to be carefully crafted as to not part of the RFC5322.From header field. This display name needs to
collide with the original display name of the author, nor contain be carefully crafted as to not collide with the original display
something that looks like an email address or domain name. These name of the author, nor contain something that looks like an email
modifications may to some extent defeat the purpose of DMARC address or domain name. These modifications may to some extent
itself. It may make it difficult to ensure that users of all defeat the purpose of DMARC itself. It may make it difficult to
email clients can easily reply to the author, the list, or all ensure that users of all email clients can easily reply to the
using the email client features provided for that purpose. Use of author, the list, or all using the email client features provided
RFC5322.Reply-To header field can alleviate this problem depending for that purpose. Use of RFC5322.Reply-To header field can
on whether the mailing list is configured to reply-to-list, reply- alleviate this problem depending on whether the mailing list is
to-author or reply-to-fixed-address, however it is important to configured to reply-to-list, reply-to-author or reply-to-fixed-
note that this header field can take multiple email addresses. address, however it is important to note that this header field
When altering the RFC5322.From there are two possibilities, to can take multiple email addresses. When altering the RFC5322.From
change it to put the mailing list email address, or to change it there are three possibilities:
to add a suffix like ".invalid" to the domain of the email address
present there. The later modification may create issues because 1. change it to put the mailing list email address,
it is an invalid domain name, and some MTAs may take particular
attention to the validity of email addresses in RFC5322.From and 2. change it to a locally-defined address which will be forwarded
the reputation of the domains present there. back to the original sender, or
3. "break" the address by modifying the domain to a non-existent
domain (such as by adding a suffix like ".invalid".)
The later modification may create issues because it is an invalid
domain name, and some MTAs may pay particular attention to the
validity of email addresses in RFC5322.From and the reputation of
the domains present there.
o Another mitigation policy is to configure the MLM to "wrap" the o Another mitigation policy is to configure the MLM to "wrap" the
message in a MIME message/rfc822 part and to send as the Mailing message in a MIME message/rfc822 part and to send as the Mailing
List email address. Many email clients (as of August 2014) have List email address. Many email clients (as of August 2015),
difficulty reading such messages. especially mobile clients, have difficulty reading such messages
and this is not expected to change soon.
o Another mitigation policy, is to configure the MLM to not modify o Another mitigation policy, is to configure the MLM to not modify
the message so that the DKIM signature remains valid. Some the message so that the DKIM signature remains valid. Some
Mailing Lists are mainly setup this way and require little Mailing Lists are set up this way and require few additional
modifications to ensure the DKIM signature is preserved. However changes to ensure the DKIM signature is preserved. Moving lists
moving to this policy a list that do extensive modification to the that currently modify mail to a policy like this, may be too much
email, may be too much of a change for the members of such list. of a change for the members of such lists.
o Another mitigation policy, is to reject posts from domains with a o Another mitigation policy, is to reject posts or membership
DMARC policy other than p=none. However members of such Mailing requests from domains with a DMARC policy other than p=none.
Lists may complain of unfair exclusion. 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 o To alleviate unsubscribes to the Mailing List due to the messages
bouncing because of DMARC, the MLM needs to not act on bounces due bouncing because of DMARC, the MLM needs to not act on bounces due
to Message Authentication issues. [RFC3463] specifies Enhanced to Message Authentication issues. [RFC3463] specifies Enhanced
Mail System Status Codes which help differentiate between various Mail System Status Codes which help differentiate between various
bounces. Correctly interpreting Extended SMTP error messages is bounces. Correctly interpreting Extended SMTP error messages is
useful in this case in particular codes defined in [RFC7372] and useful in this case. In particular, extended status codes are
in DMARC. defined in [RFC7372] and in DMARC [RFC7489].
All these techniques may provide some specific challenges in MUAs and All these techniques may provide some specific challenges to MUAs and
different operational usages for end users (like rewriting filters to different operational usages for end users (like rewriting filters to
sort emails in folders). There will be some time before all sort emails in folders). There will be some time before all
implications are understood and alleviated. implications are understood and adjusted to.
4.2. Proposed and In-Progress Mitigations 4.2. Proposed and In-Progress Mitigations
The following mitigations are based on Internet Drafts which have not The following mitigations are based on Internet Drafts which have not
yet received broad consensus. They are described here to offer yet received broad consensus. They are described here to offer
exploratory path for solutions. These solutions should not be used exploratory path for solutions. These solutions should not be used
in a production environment. in a production environment.
o Third party authorization, [RFC6541], [I-D.otis-tpa-label] and o Third party authorization, [RFC6541], [I-D.otis-tpa-label] and
[I-D.kucherawy-dkim-delegate] provide ways to extend identifier [I-D.kucherawy-dkim-delegate] provide ways to extend identifier
skipping to change at page 18, line 16 skipping to change at page 20, line 27
8.1. Normative References 8.1. Normative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
3463, January 2003. 3463, January 2003.
[RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
for Authorizing Use of Domains in E-Mail, Version 1", RFC
4408, April 2006.
[RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering
Language", RFC 5228, January 2008. Language", RFC 5228, January 2008.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. October 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008. October 2008.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July
skipping to change at page 20, line 14 skipping to change at page 22, line 28
Eliot Lear (editor) Eliot Lear (editor)
Cisco Systems GmbH Cisco Systems GmbH
Richtistrasse 7 Richtistrasse 7
Wallisellen, ZH CH-8304 Wallisellen, ZH CH-8304
Switzerland Switzerland
Phone: +41 44 878 9200 Phone: +41 44 878 9200
Email: lear@cisco.com Email: lear@cisco.com
Tim Draegen (editor) Tim Draegen (editor)
Eudaemonic Development LLC dmarcian, inc.
PO Box 19443 PO Box 1007
Asheville, NC 28815 Brevard, NC 28712
USA USA
Email: tim@eudev.net Email: tim@dmarcian.com
Elizabeth Zwicky (editor) Elizabeth Zwicky (editor)
Yahoo Yahoo
Sunnyvale, CA Sunnyvale, CA
USA USA
Email: zwicky@yahoo-inc.com Email: zwicky@yahoo-inc.com
Kurt Andersen (editor)
LinkedIn
2029 Stierlin Court
Mt. View, CA 94043
USA
Email: kandersen@linkedin.com
 End of changes. 94 change blocks. 
297 lines changed or deleted 401 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/