draft-ietf-dmarc-interoperability-12.txt   draft-ietf-dmarc-interoperability-13.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: June 2, 2016 Cisco Systems GmbH Expires: June 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
November 30, 2015 December 8, 2015
Interoperability Issues Between DMARC and Indirect Email Flows Interoperability Issues Between DMARC and Indirect Email Flows
draft-ietf-dmarc-interoperability-12 draft-ietf-dmarc-interoperability-13
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 June 2, 2016. This Internet-Draft will expire on June 10, 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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 . . . . . . . . . . . . . . . . . . 4 1.1. Document Conventions . . . . . . . . . . . . . . . . . . 4
2. Causes of Interoperability Issues . . . . . . . . . . . . . . 4 2. Causes of Interoperability Issues . . . . . . . . . . . . . . 4
2.1. Identifier Alignment . . . . . . . . . . . . . . . . . . 4 2.1. Identifier Alignment . . . . . . . . . . . . . . . . . . 4
2.1.1. DKIM Identifier(s) . . . . . . . . . . . . . . . . . 5
2.1.2. SPF Identifier(s) . . . . . . . . . . . . . . . . . . 5
2.2. Message Forwarding . . . . . . . . . . . . . . . . . . . 5 2.2. Message Forwarding . . . . . . . . . . . . . . . . . . . 5
2.3. Message Modification . . . . . . . . . . . . . . . . . . 6 2.3. Message Modification . . . . . . . . . . . . . . . . . . 6
3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 6 3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 7
3.1. Message Handling System . . . . . . . . . . . . . . . . . 6 3.1. Message Handling System . . . . . . . . . . . . . . . . . 7
3.1.1. Message Submission Agents . . . . . . . . . . . . . . 7 3.1.1. Message Submission Agents . . . . . . . . . . . . . . 7
3.1.2. Message Transfer Agents . . . . . . . . . . . . . . . 8 3.1.2. Message Transfer Agents . . . . . . . . . . . . . . . 8
3.1.2.1. Message Encoding . . . . . . . . . . . . . . . . 8 3.1.2.1. Message Encoding . . . . . . . . . . . . . . . . 8
3.1.2.2. Header Standardization . . . . . . . . . . . . . 8 3.1.2.2. Header Standardization . . . . . . . . . . . . . 9
3.1.2.3. Content Validation . . . . . . . . . . . . . . . 9 3.1.2.3. Content Validation . . . . . . . . . . . . . . . 9
3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 9 3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 9
3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 10 3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 11
3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 11 3.2.3. Mailing Lists . . . . . . . . . . . . . . . . . . . . 11
3.2.3.1. Mailing List Operational Effects . . . . . . . . 11 3.2.3.1. Mailing List Operational Effects . . . . . . . . 12
3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 12 3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 12
3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 12 3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 13
3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 13 3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 14
4. Possible Mitigations of Interoperability Issues . . . . . . . 13 4. Possible Mitigations of Interoperability Issues . . . . . . . 14
4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 14 4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 15
4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 15 4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 15
4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 15 4.1.1.1. Identifier Alignment . . . . . . . . . . . . . . 15
4.1.1.2. Message Modification . . . . . . . . . . . . . . 15 4.1.1.2. Message Modification . . . . . . . . . . . . . . 16
4.1.2. Mitigations for Receivers . . . . . . . . . . . . . . 16 4.1.2. Mitigations for Receivers . . . . . . . . . . . . . . 16
4.1.2.1. Identifier Alignment . . . . . . . . . . . . . . 16 4.1.2.1. Identifier Alignment . . . . . . . . . . . . . . 16
4.1.2.2. Policy Override . . . . . . . . . . . . . . . . . 16 4.1.2.2. Policy Override . . . . . . . . . . . . . . . . . 16
4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 16 4.1.3. Mitigations for ReSenders . . . . . . . . . . . . . . 16
4.1.3.1. Changes to the RFC5322.from . . . . . . . . . . . 16 4.1.3.1. Changes to the RFC5322.from . . . . . . . . . . . 17
4.1.3.2. Avoiding Message Modification . . . . . . . . . . 17 4.1.3.2. Avoiding Message Modification . . . . . . . . . . 17
4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 17 4.1.3.3. Mailing Lists . . . . . . . . . . . . . . . . . . 17
4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 18 4.2. Proposed and In-Progress Mitigations . . . . . . . . . . 19
4.2.1. Getting More Radical: Requiring New Communication 4.2.1. Getting More Radical: Requiring New Communication
Paths Between MUAs . . . . . . . . . . . . . . . . . 19 Paths Between MUAs . . . . . . . . . . . . . . . . . 19
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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
skipping to change at page 4, line 50 skipping to change at page 5, line 5
modes: strict and relaxed. Strict mode requires an exact match of modes: strict and relaxed. Strict mode requires an exact match of
either of the Authenticated Identifiers to the message's RFC5322.from either of the Authenticated Identifiers to the message's RFC5322.from
header field [RFC5322]. Relaxed mode allows for Identifier Alignment header field [RFC5322]. Relaxed mode allows for Identifier Alignment
if Authenticated Identifiers and the message's RFC5322.from header if Authenticated Identifiers and the message's RFC5322.from header
field [RFC5322] share the same Organizational Domain. In general, field [RFC5322] share the same Organizational Domain. In general,
interoperability issues between strict and relaxed modes are the interoperability issues between strict and relaxed modes are the
same, with strict mode constraining the application of possible same, with strict mode constraining the application of possible
solutions. The mitigations described in this document generally solutions. The mitigations described in this document generally
require a relaxed mode of Identifier Alignment. require a relaxed mode of Identifier Alignment.
DKIM provides a cryptographic means for a domain identifier to be 2.1.1. DKIM Identifier(s)
associated with a particular message. As a standalone technology
DKIM identifiers are not required to be relevant to the content of a DKIM provides a cryptographic means for one or more domain identifier
message. However, for a DKIM identifier to align in DMARC, the to be associated with a particular message. As a standalone
signing domain of a valid signature must be part of the same technology DKIM identifiers are not required to be relevant to the
Organizational Domain as the domain in the RFC5322.from header field content of a message. However, for a DKIM identifier to align in
[RFC5322]. DMARC, the signing domain of a valid signature must be part of the
same Organizational Domain as the domain in the RFC5322.from header
field [RFC5322].
In addition, DKIM allows for the possibility of multiple valid 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 incorrectly flag messages as "failing DMARC" and erroneously may incorrectly flag messages as "failing DMARC" and erroneously
apply DMARC based policy to otherwise conforming messages. apply DMARC based policy to otherwise conforming messages.
SPF can provide two Authenticated Identifiers. The DMARC relevant 2.1.2. SPF Identifier(s)
Authenticated Identifiers that SPF provides is the RFC7208.MAILFROM
[RFC7208] based on the RFC5321.mailfrom [RFC5321] domain, or, if the The SPF specification [RFC7208] defines two Authenticated Identifiers
RFC5321.mailfrom address is absent (as in the case of "bounce" for each message. These identifiers derive from:
messages), on the RFC5321.HELO/EHLO SMTP domain. The SPF validated
domain in RFC7208.MAILFROM must be part of the same Organizational a. the RFC5321.mailfrom [RFC5321] domain, and
Domain as the domain in the RFC5322.from header field to be aligned.
It is important to note that even when an SPF record exists for the b. the RFC5321.HELO/EHLO SMTP domain.
domain in RFC5322.from [RFC5322], SPF will not authenticate it unless
it is also the domain checked by SPF. Also note that the In the SPF specification, the RFC7208.MAILFROM [RFC7208] value is
RFC7208.MAILFROM definition is different from the RFC5321.mailfrom defined to be based on RFC5321.mailfrom unless that value is absent
[RFC5321] definition. (as in the case of "bounce" messages) in which case, the second
(RFC5321.HELO/EHLO) identifier value is used. This "fallback"
definition has occasionally been misunderstood by senders since
"bounce" messages are often an "automatic" feature of MTA software.
For the purposes of DMARC validation/alignment, the hybrid
RFC7208.MAILFROM [RFC7208] identifier's domain is used if, and only
if, it is aligned with the RFC5322.from [RFC5322] domain. The
alignment of the validated domain is determined based on the DMARC
record's "strict" or "relaxed" designation as described above for the
DKIM identifiers and in [RFC7489].
2.2. Message Forwarding 2.2. Message Forwarding
Section 3 describes forwarding behavior as it relates to the Section 3 describes forwarding behavior as it relates to the
components of the Internet Mail Architecture. components of the Internet Mail Architecture.
All forwarding behavior involves the retransmission of email. As All forwarding behavior involves the retransmission of email. As
discussed above, in order for SPF to yield an Authenticated discussed above, in order for SPF to yield an Authenticated
Identifier that is pertinent to DMARC, the domain of the Identifier that is pertinent to DMARC, the domain of the
RFC7208.MAILFROM must be in alignment with the RFC5322.from header RFC7208.MAILFROM must be in alignment with the RFC5322.from header
 End of changes. 18 change blocks. 
40 lines changed or deleted 54 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/