draft-ietf-dmarc-interoperability-15.txt   draft-ietf-dmarc-interoperability-16.txt 
DMARC 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: November 14, 2016 Cisco Systems GmbH Expires: December 10, 2016 Cisco Systems GmbH
T. Draegen, Ed. T. Draegen, Ed.
dmarcian, inc. dmarcian, inc.
E. Zwicky, Ed. E. Zwicky, Ed.
Yahoo Yahoo
K. Andersen, Ed. K. Andersen, Ed.
LinkedIn LinkedIn
May 13, 2016 June 8, 2016
Interoperability Issues Between DMARC and Indirect Email Flows Interoperability Issues Between DMARC and Indirect Email Flows
draft-ietf-dmarc-interoperability-15 draft-ietf-dmarc-interoperability-16
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 44 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 November 14, 2016. This Internet-Draft will expire on December 10, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 49 skipping to change at page 2, line 49
3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 11 3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 11
3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 12 3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 12
3.2.3.1. Mailing List Operational Effects . . . . . . . . 12 3.2.3.1. Mailing List Operational Effects . . . . . . . . 12
3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 13 3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 13
3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 13 3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 13
3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 14 3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 14
4. Possible Mitigations of Interoperability Issues . . . . . . . 14 4. Possible Mitigations of Interoperability Issues . . . . . . . 14
4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 15 4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 15
4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 16 4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 15
4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 16 4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 16
4.1.1.2. Message Modification . . . . . . . . . . . . . . 16 4.1.1.2. Message Modification . . . . . . . . . . . . . . 16
4.1.2. Mitigations for Receivers . . . . . . . . . . . . . . 17 4.1.2. Mitigations for Receivers . . . . . . . . . . . . . . 17
4.1.2.1. Identifier Alignment . . . . . . . . . . . . . . 17 4.1.2.1. Identifier Alignment . . . . . . . . . . . . . . 17
4.1.2.2. Policy Override . . . . . . . . . . . . . . . . . 17 4.1.2.2. Policy Override . . . . . . . . . . . . . . . . . 17
4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 17 4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 17
4.1.3.1. Changes to the RFC5322.From . . . . . . . . . . . 17 4.1.3.1. Changes to the RFC5322.From . . . . . . . . . . . 17
4.1.3.2. Avoiding Message Modification . . . . . . . . . . 18 4.1.3.2. Avoiding Message Modification . . . . . . . . . . 18
4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 18 4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 18
4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 19 4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 19
skipping to change at page 3, line 30 skipping to change at page 3, line 30
A.1. Initial Message . . . . . . . . . . . . . . . . . . . . . 23 A.1. Initial Message . . . . . . . . . . . . . . . . . . . . . 23
A.2. Notification message . . . . . . . . . . . . . . . . . . 23 A.2. Notification message . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
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.
At the time of the writing of this document, the DMARC base At the time of the writing of this document, the DMARC base
specification is published as Informational RFC7489 [RFC7489] and has specification is published as Informational RFC 7489 [RFC7489] and
seen significant deployment within the email community. has seen 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 recipient's domain(s) are collectively administrative domain to the recipient's domain(s) are collectively
referred to in this document as indirect email flows. Due to referred to in this document as indirect email flows. Due to
existing and increasing adoption of DMARC, the impact of DMARC-based existing and increasing adoption of DMARC, the impact of DMARC-based
email rejection policies on indirect email flows can be significant email rejection policies on indirect email flows can be significant
for a select subset of general email traffic. for a 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
skipping to change at page 4, line 12 skipping to change at page 4, line 12
comprehensive in its review, it should not be treated as complete. comprehensive in its review, it should not be treated as complete.
Note that some practices which are in use at the time of this Note that some practices which are in use at the time of this
document may or may not be "best practices", especially as future document may or may not be "best practices", especially as future
standards evolve. standards evolve.
1.1. Document Conventions 1.1. Document Conventions
The notation used in this document for structured fields is taken The notation used in this document for structured fields is taken
from [RFC5598] section 1.3. from [RFC5598] section 1.3.
The term "notification message" [RFC5321] secton 4.5.5 is used to The term "notification message" [RFC5321] section 4.5.5 is used to
refer to a message with a null RFC5321.MailFrom. refer to a message with a null RFC5321.MailFrom.
The terms "Organizational Domain" and "Authenticated Identifiers" are The terms "Organizational Domain" and "Authenticated Identifiers" are
specified in DMARC [RFC7489] section 3. specified in DMARC [RFC7489] section 3.
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 a receiving when conformance to the DMARC specification leads a receiving
implementation to apply DMARC based policy restrictions to messages implementation to apply DMARC-based policy restrictions to messages
that are both compliant with the architecture as specified in that are both compliant with the architecture as specified in
[RFC5598] and viewed as legitimate by the intended recipient. [RFC5598] and viewed as legitimate by the intended recipient.
Note that domains which assert a "p=none" policy and email which Note that domains which assert a "p=none" policy and email which
passes standard DMARC validation do not have any interoperability passes standard DMARC validation do not have any interoperability
issues. issues.
Email messages that do not conform to IETF email specifications but Email messages that do not conform to IETF email specifications but
are considered legitimate by the intended recipients are not are considered legitimate by the intended recipients are not
discussed in this document. discussed in this document.
skipping to change at page 6, line 14 skipping to change at page 6, line 14
(as in the case of notification messages) in which case, the second (as in the case of notification messages) in which case, the second
(RFC5321.HELO/.EHLO) identifier value is used. This "fallback" (RFC5321.HELO/.EHLO) identifier value is used. This "fallback"
definition has occasionally been misunderstood by operators of MTA definition has occasionally been misunderstood by operators of MTA
systems since notification messages are often an "automatic" feature systems since notification messages are often an "automatic" feature
of MTA software. Some MTA software does not provide the ability to of MTA software. Some MTA software does not provide the ability to
apply a DKIM signature to such notification messages. apply a DKIM signature to such notification messages.
See Appendix A for an example treatment of this scenario. See Appendix A for an example treatment of this scenario.
For the purposes of DMARC validation/alignment, the hybrid For the purposes of DMARC validation/alignment, the hybrid
RFC7208.MAILFROM [RFC7208] identifier's domain is used if, and only RFC7208.MAILFROM [RFC7208] identifier's domain is used if and only if
if, it is aligned with the RFC5322.From [RFC5322] domain. The it is aligned with the RFC5322.From [RFC5322] domain. The alignment
alignment of the validated domain is determined based on the DMARC of the validated domain is determined based on the DMARC record's
record's "strict" or "relaxed" designation as described above for the "strict" or "relaxed" designation as described above for the DKIM
DKIM identifiers and in [RFC7489]. identifiers and in [RFC7489].
2.1.3. Multiple RFC5322.From Addresses 2.1.3. Multiple RFC5322.From Addresses
[RFC5322] permits only one From header field, but it may contain [RFC5322] permits only one From header field, but it may contain
multiple mailboxes. Since this is an extremely rare usage, DMARC multiple mailboxes. Since this is an extremely rare usage, DMARC
specifies that the handling of this situation is implementation specifies that the handling of this situation is implementation
dependent. dependent.
Because the presence of multiple domains can be used by an attacker Because the presence of multiple domains can be used by an attacker
(an attacker could add their domain to the RFC5322.From field, (an attacker could add their domain to the RFC5322.From field,
skipping to change at page 7, line 7 skipping to change at page 7, line 7
o If the RFC5321.MailFrom is present and the forwarder maintains the o If the RFC5321.MailFrom is present and the forwarder maintains the
original RFC5321.MailFrom, SPF validation will fail unless the original RFC5321.MailFrom, SPF validation will fail unless the
forwarder is an authorized part of the originator's email sending forwarder is an authorized part of the originator's email sending
infrastructure. If the forwarder replaces the RFC5321.MailFrom infrastructure. If the forwarder replaces the RFC5321.MailFrom
with its own domain, SPF might pass but Identifier Alignment with with its own domain, SPF might pass but Identifier Alignment with
the RFC5322.From header field will fail. the RFC5322.From header field will fail.
o If the RFC5321.MailFrom is empty (as in the case of Delivery o If the RFC5321.MailFrom is empty (as in the case of Delivery
Status Notifications), the RFC5321.HELO/.EHLO domain of the Status Notifications), the RFC5321.HELO/.EHLO domain of the
forwarder will likely be in different organizational domain than forwarder will likely be in a different organizational domain than
the orignal RFC5322.From header field's domain. SPF may pass but the original RFC5322.From header field's domain. SPF may pass but
Identifier Alignment with the RFC5322.From header field will fail. Identifier Alignment with the RFC5322.From header field will fail.
In both cases, SPF cannot yield relevant Authenticated Identifiers, In both cases, SPF cannot yield relevant Authenticated Identifiers,
and DKIM must be relied upon to produce results that are relevant to and DKIM must be relied upon to produce results that are relevant to
DMARC. DMARC.
2.3. 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
skipping to change at page 7, line 33 skipping to change at page 7, line 33
without invalidating the signature, in practice, particularly with without invalidating the signature, in practice, particularly with
MIME-encoded [RFC2045] messages, a mailing list processor will do MIME-encoded [RFC2045] messages, a mailing list processor will do
more than simply append content (see Section 5.3 of [RFC5598] for more than simply append content (see Section 5.3 of [RFC5598] for
details). Furthermore, the length flag is seldom used due to details). Furthermore, the length flag is seldom used due to
security issues (see Section 8.2 of [RFC6376] for additional security security issues (see Section 8.2 of [RFC6376] for additional security
considerations), therefore, this method is only here mentioned for considerations), therefore, this method is only here mentioned for
completeness. completeness.
DKIM describes two canonicalizations for use when preparing header DKIM describes two canonicalizations for use when preparing header
and body for DKIM processing: simple and relaxed. The latter is and body for DKIM processing: simple and relaxed. The latter is
designed to accomodate trivial modifications to whitespace and designed to accommodate trivial modifications to whitespace and
folding which, at least in the header case, generally have no folding which, at least in the header case, generally have no
semantic significance. However, the relaxed canonicalization is more semantic significance. However, the relaxed canonicalization is more
computationally intensive and may not have been preferred in the computationally intensive and may not have been preferred in the
early deployment of DKIM, leaving some deployments using the less early deployment of DKIM, leaving some deployments using the less
forgiving "simple" canonicalization. While the prevalence is forgiving "simple" canonicalization. While the prevalence is
unknown, there are some DKIM verifiers which have problems evaluating unknown, there are some DKIM verifiers which have problems evaluating
relaxed canonicalization correctly. relaxed canonicalization correctly.
3. Internet Mail Architecture, DMARC, and Indirect Email Flows 3. Internet Mail Architecture, DMARC, and Indirect Email Flows
skipping to change at page 9, line 37 skipping to change at page 9, line 37
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 could also re-encode the message without changing the encoding An MTA could also re-encode the message without changing the encoding
type, receiving a MIME-encoded message and producing a semantically type, receiving a MIME-encoded message and producing a semantically
and semiotically equivalent MIME body that is not identical to the and semiotically-equivalent MIME body that is not identical to the
original. This is characteristic of systems that use some other original. This is characteristic of systems that use some other
message representation internally. message representation internally.
3.1.2.2. Header Standardization 3.1.2.2. Header Standardization
An MTA may rewrite headers to bring them into compliance with An MTA may rewrite headers to bring them into compliance with
existing RFCs. For example, some common MTAs will correct existing RFCs. For example, some common MTAs will correct
comprehensible but non-compliant date formats to compliant ones. comprehensible but non-compliant date formats to compliant ones.
Header rewriting is outside the scope of DKIM canonicalization and Header rewriting is outside the scope of DKIM canonicalization and
skipping to change at page 11, line 12 skipping to change at page 11, line 12
mail when the new Recipient receives the message from the Mediator mail when the new Recipient receives the message from the Mediator
rather than the initial organization. rather than the initial organization.
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
outside of the scope covered by the originating ADMD's SPF record(s). 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 free email (freemail) providers to try o Forwarding email between free email (freemail) providers to try
different interfaces while maintaining an original email address; different interfaces while maintaining an original email address;
o Consolidating many email addresses into a single account to o Consolidating many email addresses into a single account to
centralize processing; centralize processing;
o Services that provide "activity based", "role based" , "vanity" or o Services that provide "activity-based", "role-based" , "vanity" or
"temporary" email addresses such as universities and professional "temporary" email addresses such as universities and professional
associations. For instance professional or alumni institutions associations. For instance professional or alumni institutions
may offer their members an alias for the duration of their may offer their members an alias for the duration of their
membership but may not want to deal with the long term storage of membership but may not want to deal with the long term 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 originator or the administrative relationship to the ADMD of the originator or the
final recipient, so solutions to Alias-related DMARC failure should final recipient, so solutions to Alias-related DMARC failure should
not assume such a relationship. not assume such a relationship.
skipping to change at page 13, line 22 skipping to change at page 13, line 22
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,
addressing, and/or other attributes as needed to send the message addressing, and/or other attributes as needed to send the message
into a messaging environment that operates under different standards into a messaging environment that operates under different standards
or potentially 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 also share 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 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 unable to evaluate DKIM and SPF. If a message passes through a
second protocol gateway back into the SMTP domain, the second protocol gateway back into the SMTP domain, the
transformations commonly break the original DKIM signature(s). 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 into alternate if the Gateway is configured to rewrite the message into alternate
recipient domains. For example, an acquisition may lead an acquiring recipient domains. For example, an acquisition may lead an acquiring
skipping to change at page 14, line 31 skipping to change at page 14, line 31
as a way to control the potential threat from malware. as a way to control the potential threat from malware.
o Secondary MX services: The secondary MX for an organization may be o Secondary MX services: The secondary MX for an organization may be
external to the normal mail processing for the organization, and external to the normal mail processing for the organization, and
queue and forward to the primary when it becomes available. This queue and forward to the primary when it becomes available. This
will not invalidate DKIM but will prevent the primary from will not invalidate DKIM but will prevent the primary from
validating SPF normally. In this case, however, it is validating SPF normally. In this case, however, it is
inappropriate for a primary MX server to perform an SPF check inappropriate for a primary MX server to perform an SPF check
against its own secondaries. Rather, the secondary MX should against its own secondaries. Rather, the secondary MX should
perform this function and employ some trusted mechanism to perform this function and employ some trusted mechanism to
communicate the results of the SPF, DKIM and DMARC evaluation(s) communicate the results of the SPF, DKIM, and DMARC evaluation(s)
to the primary MX server. to the primary MX server.
3.3. Combinations 3.3. Combinations
Indirect email flows can be combined. For example, a university Indirect email flows can be combined. For example, a university
student may subscribe to a mailing list (using his university email student may subscribe to a mailing list (using his university email
address) while this university email address is configured to forward address) while this university email address is configured to forward
all emails to a freemail or a post-education corporate account all emails to a freemail or a post-education corporate account
provider where a more permanent email address for this student provider where a more permanent email address for this student
exists. 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 processing, such as proper handling of
multiple DKIM signatures, to more radical changes 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. Note that these particular mechanisms may interoperability issues. Note that these particular mechanisms may
not be considered "best practices" and may, in some cases, violate not be considered "best practices" and may, in some cases, violate
various conventions or expectations. various conventions or expectations.
Receivers sometimes need to deliver email messages that do not Receivers sometimes need to deliver email messages that do not
conform to any standard or protocol, but are otherwise desired by end conform to any standard or protocol, but are otherwise desired by end
users. Mitigating the impact of DMARC on indirect email flows is users. Mitigating the impact of DMARC on indirect email flows is
especially important to receivers that operate services where ease of especially important to receivers that operate services where ease of
skipping to change at page 15, line 27 skipping to change at page 15, line 27
outside DMARC and communicate those decisions as "overrides" to the outside DMARC and communicate those decisions as "overrides" to the
sender. This facility can be used to ease some interoperability sender. This facility can be used to ease some interoperability
issues, although care is needed to ensure that this does not create issues, although care is needed to ensure that this does not create
loopholes for abuse. loopholes for abuse.
To further complicate the usage of mitigations, mitigation may not be To further complicate the usage of mitigations, mitigation may not be
desired if the email in question is of a certain category of high desired if the email in question is of a certain category of high
value or high risk (security-related) transactional messages (dealing value or high risk (security-related) transactional messages (dealing
with financial transactions or medical records, for example). In with financial transactions or medical records, for example). In
these cases, mitigating the impact of DMARC due to indirect email these cases, mitigating the impact of DMARC due to indirect email
flows may not be desirable (counter-productive, or allowing for flows may not be desirable (counterproductive or allowing for abuse).
abuse).
As a final note, mail systems are diverse and widely deployed. As a final note, mail systems are diverse and widely deployed.
Systems of various ages and capabilities are expected to preserve Systems of various ages and capabilities are expected to preserve
interoperability with the rest of the SMTP ecosystem. For instance, interoperability with the rest of the SMTP ecosystem. For instance,
Qmail is still used, although the base code has not been updated Qmail is still used, although the base code has not been updated
since 1998. ezmlm, a once popular mailing list manager, is still since 1998. ezmlm, a once popular mailing list manager, is still
deployed but has not been updated since 1997, although a new version, deployed but has not been updated since 1997, although a new version,
ezmlm-idx exists. Old versions of other open and closed source MTAs ezmlm-idx exists. Old versions of other open and closed source MTAs
are still commonly in operation. When dealing with aging or are still commonly in operation. When dealing with aging or
unsupported systems, some solutions may be time-consuming and/or unsupported systems, some solutions may be time-consuming and/or
skipping to change at page 16, line 19 skipping to change at page 16, line 16
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
notification messages. Dynamically adjusting the notification messages. Dynamically adjusting the
RFC5321.HELO/.EHLO based on the RFC5322.From may not be possible RFC5321.HELO/.EHLO based on the RFC5322.From may not be possible
for some MTA software. for some MTA software.
o MTAs may choose to DKIM sign notification messages with an aligned o MTAs may choose to DKIM-sign notification messages with an aligned
domain to allow DKIM-based DMARC pass. domain to allow a DKIM-based DMARC pass.
o MTAs sending email on behalf of multiple domains may require o MTAs sending email on behalf of multiple domains may require
Domain Owners to provide DKIM keys to use DKIM to avoid SPF Domain Owners to provide DKIM keys to use DKIM to avoid SPF
validation issues, given the requirement for DMARC alignment with validation issues, given the requirement for DMARC alignment with
the RFC5322.From header field. Managing DKIM keys with a third the RFC5322.From header field. Managing DKIM keys with a third
party has security risks that should be carefully managed (see party has security risks that should be carefully managed (see
also [RFC6376] section 8). Methods involving CNAMEs and/or also [RFC6376] section 8). Methods involving CNAMEs and/or
subdomains may alleviate some risks. subdomains may alleviate some risks.
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 an RFC5322.Reply-to header field.
However, performing this modification may cause the recipient's However, performing this modification may cause the recipient's
MUA to deviate from customary behavior. MUA to deviate from customary behavior.
o When implementing "forward-to-friend" functionality one approach o When implementing "forward-to-friend" functionality, one approach
to avoid DMARC failures is to pass a well formed message to the to avoid DMARC failures is to pass a well-formed message to the
user's MUA so that it may fill in an appropriate identity and user's MUA so that it may fill in an appropriate identity and
submit through its own MSA. submit through its own MSA.
o Senders can use domains with distinct DMARC policies for email o Senders can use domains with distinct DMARC policies for email
sent directly and email known to use indirect mail flows. 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
skipping to change at page 17, line 46 skipping to change at page 17, line 44
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 as long as the ReSender signs allow arbitrary message modification as long as the ReSender signs
the message with an aligned domain signature. When ReSenders change the message with an aligned domain signature. When ReSenders change
the RFC5322.From, it is desirable to preserve the information about the RFC5322.From, it is desirable to preserve the information about
the original initiator of the message. 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 field names 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, and 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 unless included within the scope of the available for exploitation unless included within the scope of the
new DKIM signature(s). 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 locally controlled address which will be forwarded field address to a locally controlled address which will be forwarded
back to the original sender (subject to its own ReSender forwarding back to the original sender (subject to its own ReSender forwarding
mitigations!). mitigations!).
skipping to change at page 19, line 23 skipping to change at page 19, line 23
o Configuring the MLM to "wrap" the message in a MIME message/rfc822 o Configuring the MLM to "wrap" the message in a MIME message/rfc822
part and to send as the Mailing List email address. Many email part and to send as the Mailing List email address. Many email
clients (as of the publication of this document), especially clients (as of the publication of this document), especially
mobile clients, have difficulty reading such messages and this is mobile clients, have difficulty reading such messages and this is
not expected to change soon. not expected to change soon.
o Configuring the MLM to not modify the message so that the DKIM o Configuring the MLM to not modify the message so that the DKIM
signature remains valid. Some Mailing Lists are set up this way signature remains valid. Some Mailing Lists are set up this way
and require few additional changes to ensure the DKIM signature is and require few additional changes to ensure the DKIM signature is
preserved. Moving lists that currently modify mail to a policy preserved. Moving lists that currently modify mail to a policy
like this, may be too much of a change for the members of such like this may be too much of a change for the members of such
lists. lists.
o Rejecting posts or membership requests from domains with a DMARC o Rejecting posts or membership requests from domains with a DMARC
policy other than "p=none". However members or potential members policy other than "p=none". However members or potential members
of such Mailing Lists may complain of unfair exclusion. 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 bouncing because of DMARC, the MLM needs to not act on
notification messages due to Message Authentication issues. notification messages due to Message Authentication issues.
[RFC3463] specifies Enhanced Mail System Status Codes which help [RFC3463] specifies Enhanced Mail System Status Codes which help
skipping to change at page 20, line 7 skipping to change at page 20, line 7
4.2. Proposed and In-Progress Mitigations 4.2. Proposed and In-Progress Mitigations
The following mitigations are based on Internet Drafts (I-Ds) which The following mitigations are based on Internet Drafts (I-Ds) which
are still in process. They are described here to offer exploratory are still in process. They are described here to offer exploratory
path for solutions. These solutions should not be used in a path for solutions. These solutions should not be used in a
production environment. Because of the transient nature of I-Ds, production environment. Because of the transient nature of I-Ds,
specific citations are not included because a number of them will specific citations are not included because a number of them will
inevitably become obsolete and those which gain consensus in the inevitably become obsolete and those which gain consensus in the
community will become RFCs and should be discovered as such. community will become RFCs and should be discovered as such.
o Third party authorization schemes provide ways to extend o Third-party authorization schemes provide ways to extend
identifier alignment under control of the domain owner. identifier alignment under control of the domain owner.
o Ways to canonicalize messages that transit mailing lists so that o Ways to canonicalize messages that transit mailing lists so that
their alterations can be isolated from the original signed their alterations can be isolated from the original signed
content. content.
o Mechanisms to record message transformations applied at each hop o Mechanisms to record message transformations applied at each hop
so they can be reversed and the original signed content recovered. so they can be reversed and the original signed content recovered.
o "Conditional" DKIM signatures, whereby the author domain indicates o "Conditional" DKIM signatures, whereby the author domain indicates
skipping to change at page 21, line 8 skipping to change at page 21, line 8
delete this section prior to publication.] delete this section prior to publication.]
6. Security Considerations 6. Security Considerations
This document is an analysis of DMARC's impact on indirect email This document is an analysis of DMARC's impact on indirect email
flows. It describes the possibility of accidental denial-of-service flows. It describes the possibility of accidental denial-of-service
that can be created by rejections of messages by DMARC-aware Mail that can be created by rejections of messages by DMARC-aware Mail
Receivers. Receivers.
Section 4.1.1.1 discusses the importance of appropriate DKIM key Section 4.1.1.1 discusses the importance of appropriate DKIM key
management vis a vis third party email senders. management vis-a-vis third-party email senders.
Section 4.1.3.3 warns that rewriting the RFC5322.From header field Section 4.1.3.3 warns that rewriting the RFC5322.From header field
and changing the domain name should not be done with any domain. and changing the domain name should not be done with any domain.
7. Acknowledgments 7. Acknowledgments
Miles Fidelman, John Levine, David Crocker, Stephen J. Turnbull, Miles Fidelman, John Levine, David Crocker, Stephen J. Turnbull,
Rolf E. Sonneveld, Tim Draegen and Franck Martin contributed to the Rolf E. Sonneveld, Tim Draegen, and Franck Martin contributed to the
IETF DMARC Working Group's wiki page listing all known IETF DMARC Working Group's wiki page listing all known
interoperability issues with DMARC and indirect email flows. interoperability issues with DMARC and indirect email flows.
Tim Draegen created the first draft of this document from these Tim Draegen created the first draft of this document from these
contributions and by hamfistedly mapping contributions into the contributions and by hamfistedly mapping contributions into the
language of [RFC5598]. language of [RFC5598].
8. References 8. References
8.1. Normative References 8.1. Normative References
skipping to change at page 23, line 42 skipping to change at page 23, line 42
A.2. Notification message A.2. Notification message
When dmarc.org rejects the message without a DKIM signature, it When dmarc.org rejects the message without a DKIM signature, it
specifies the RFC5321.HELO/.EHLO domain as dmarc.org.local which has specifies the RFC5321.HELO/.EHLO domain as dmarc.org.local which has
no SPF record. dmarc.org has a reject policy in place for such non- no SPF record. dmarc.org has a reject policy in place for such non-
passing cases. Since there is no DKIM signature on the notification passing cases. Since there is no DKIM signature on the notification
message, the failed SPF lookup results in a dmarc=fail and d1.example message, the failed SPF lookup results in a dmarc=fail and d1.example
could be expected to discard the notification message itself: could be expected to discard the notification message itself:
Return-Path: <> Return-Path: <>
Received: from dmarc.org.local (mail.dmarc.org. [10.255.0.1]) Received: from dmarc.org.local (mail.dmarc.org. [192.0.2.1])
by mx.d1.example with ESMTPS id Lkm25302jJR5 by mx.d1.example with ESMTPS id Lkm25302jJR5
for <jqd@d1.example> for <jqd@d1.example>
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 14 Jan 2015 15:00:24 -0800 (PST) Thu, 14 Jan 2015 15:00:24 -0800 (PST)
Authentication-Results: mx.d1.example; Authentication-Results: mx.d1.example;
spf=none (d1.example: dmarc.org.local does not designate spf=none (d1.example: dmarc.org.local does not designate
permitted sender hosts) smtp.mail=; permitted sender hosts) smtp.mail=;
dmarc=fail (p=REJECT dis=NONE) header.from=dmarc.org dmarc=fail (p=REJECT dis=NONE) header.from=dmarc.org
MIME-Version: 1.0 MIME-Version: 1.0
Received: from segv.d1.example (segv.d1.example [10.15.20.25]) Received: from segv.d1.example (segv.d1.example [198.51.100.1])
by 10.10.10.131 with SMTP id u67mr102828634qge33; Thu, by 192.0.2.2 with SMTP id u67mr102828634qge33; Thu,
14 Jan 2015 15:00:24 -0800 (PST) 14 Jan 2015 15:00:24 -0800 (PST)
From: Mail Delivery Subsystem <mailer-daemon@dmarc.org> From: Mail Delivery Subsystem <mailer-daemon@dmarc.org>
To: jqd@d1.example To: jqd@d1.example
Subject: Delivery Status Notification (Failure) Subject: Delivery Status Notification (Failure)
Message-ID: <001a11c16e6a9ead220528df294a@dmarc.org> Message-ID: <001a11c16e6a9ead220528df294a@dmarc.org>
Date: Thu, 14 Jan 2016 23:00:24 +0000 Date: Thu, 14 Jan 2016 23:00:24 +0000
Content-Type: text/plain; charset=UTF-8 Content-Type: text/plain; charset=UTF-8
This is an automatically generated Delivery Status Notification This is an automatically generated Delivery Status Notification
Delivery to the following recipient failed permanently: Delivery to the following recipient failed permanently:
no-recipient@dmarc.org no-recipient@dmarc.org
Technical details of permanent failure: Technical details of permanent failure:
Your message was rejected by the server for the recipient domain Your message was rejected by the server for the recipient domain
dmarc.org by mail.dmarc.org [10.255.0.1]. dmarc.org by mail.dmarc.org [192.0.2.1].
The error that the other server returned was: The error that the other server returned was:
550 5.1.1 <no-recipient@dmarc.org>... User unknown 550 5.1.1 <no-recipient@dmarc.org>... User unknown
----- Original message ----- ----- Original message -----
Return-Path: <jqd@d1.example> Return-Path: <jqd@d1.example>
Received: from [10.10.10.131] (131-10-10-10.dsl.static.example.com Received: from [203.252.0.131] (131-0-252-203-dsl.static.example.com
[10.10.10.131]) (authenticated bits=0) [203.252.0.131]) (authenticated bits=0)
by segv.d1.example with ESMTP id t0FN4a8O084569; by segv.d1.example with ESMTP id t0FN4a8O084569;
Thu, 14 Jan 2015 15:00:01 -0800 (PST) Thu, 14 Jan 2015 15:00:01 -0800 (PST)
(envelope-from jqd@d1.example) (envelope-from jqd@d1.example)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=d1.example;
s=20130426; t=1421363082; s=20130426; t=1421363082;
bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=; bh=EoJqaaRvhrngQxmQ3VnRIIMRBgecuKf1pdkxtfGyWaU=;
h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type: h=Message-ID:Date:From:MIME-Version:To:CC:Subject:Content-Type:
Content-Transfer-Encoding; Content-Transfer-Encoding;
b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw b=HxsvPubDE+R96v9dM9Y7V3dJUXvajd6rvF5ec5BPe/vpVBRJnD4I2weEIyYijrvQw
bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl bv9uUA1t94kMN0Q+haFo6hiQPnkuDxku5+oxyZWOqtNH7CTMgcBWWTp4QD4Gd3TRJl
 End of changes. 31 change blocks. 
42 lines changed or deleted 41 lines changed or added

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