draft-ietf-dmarc-interoperability-16.txt   draft-ietf-dmarc-interoperability-17.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: December 10, 2016 Cisco Systems GmbH Expires: December 23, 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
June 8, 2016 June 21, 2016
Interoperability Issues Between DMARC and Indirect Email Flows Interoperability Issues Between DMARC and Indirect Email Flows
draft-ietf-dmarc-interoperability-16 draft-ietf-dmarc-interoperability-17
Abstract Abstract
DMARC introduces a mechanism for expressing domain-level policies and DMARC (Domain-based Message Authentication, Reporting, and
preferences for email message validation, disposition, and reporting. Conformance) introduces a mechanism for expressing domain-level
The DMARC mechanism can encounter interoperability issues when policies and preferences for email message validation, disposition,
messages do not flow directly from the author's administrative domain and reporting. The use of restrictive policies through the DMARC
to the final recipients. Collectively these email flows are referred framework can cause interoperability issues when messages do not flow
to as indirect email flows. This document describes interoperability directly from the author's administrative domain to the final
recipients. Collectively these email flows are referred to as
indirect email flows. This document describes interoperability
issues between DMARC and indirect email flows. Possible methods for issues between DMARC and indirect email flows. Possible methods for
addressing interoperability issues are presented. addressing interoperability issues are presented.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 10, 2016. This Internet-Draft will expire on December 23, 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 32 skipping to change at page 2, line 32
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.1. DKIM Identifier(s) . . . . . . . . . . . . . . . . . 5
2.1.2. SPF Identifier(s) . . . . . . . . . . . . . . . . . . 5 2.1.2. SPF Identifier(s) . . . . . . . . . . . . . . . . . . 5
2.1.3. Multiple RFC5322.From Addresses . . . . . . . . . . . 6 2.1.3. Multiple RFC5322.From Addresses . . . . . . . . . . . 6
2.2. Message Forwarding . . . . . . . . . . . . . . . . . . . 6 2.2. Message Forwarding . . . . . . . . . . . . . . . . . . . 6
2.3. Message Modification . . . . . . . . . . . . . . . . . . 7 2.3. Message Modification . . . . . . . . . . . . . . . . . . 7
3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 7 3. Internet Mail Architecture, DMARC, and Indirect Email Flows . 7
3.1. Message Handling System . . . . . . . . . . . . . . . . . 7 3.1. Message Handling System . . . . . . . . . . . . . . . . . 8
3.1.1. Message Submission Agents . . . . . . . . . . . . . . 8 3.1.1. Message Submission Agents . . . . . . . . . . . . . . 8
3.1.2. Message Transfer Agents . . . . . . . . . . . . . . . 9 3.1.2. Message Transfer Agents . . . . . . . . . . . . . . . 9
3.1.2.1. Message Encoding . . . . . . . . . . . . . . . . 9 3.1.2.1. Message Encoding . . . . . . . . . . . . . . . . 9
3.1.2.2. Header Standardization . . . . . . . . . . . . . 9 3.1.2.2. Header Standardization . . . . . . . . . . . . . 10
3.1.2.3. Content Validation . . . . . . . . . . . . . . . 10 3.1.2.3. Content Validation . . . . . . . . . . . . . . . 10
3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 10 3.1.3. Message Delivery Agents . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . 13
3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 13 3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 13
3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 13 3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 14
3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 14 3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 15
4. Possible Mitigations of Interoperability Issues . . . . . . . 14 4. Possible Mitigations of Interoperability Issues . . . . . . . 15
4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 15 4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 16
4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 15 4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . 18
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 . . . . . . . . . . 20
4.2.1. Getting More Radical: Requiring New Communication 4.2.1. Getting More Radical: Requiring New Communication
Paths Between MUAs . . . . . . . . . . . . . . . . . 20 Paths Between MUAs . . . . . . . . . . . . . . . . . 20
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Appendix A - Example SPF Bounce . . . . . . . . . . 22 Appendix A. Appendix A - Example SPF Bounce . . . . . . . . . . 23
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, especially when employed with
of interoperability issues due to third-party message sourcing, restrictive policies, encounters several different types of
message transformation, or rerouting. interoperability issues due to third-party message sourcing, 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 RFC 7489 [RFC7489] and specification is published as Informational RFC 7489 [RFC7489] and
has 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
skipping to change at page 9, line 25 skipping to change at page 9, line 31
o Email service providers - ESPs that service customers who are o Email service providers - ESPs that service customers who are
using domains that publish a DMARC "reject" policy. using domains that 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 claims 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. As MTAs relay a message until the message reaches a destination MDA.
such, they are in a position to introduce interoperability problems. Some common message handling strategies break the integrity of DKIM
signatures. A restrictive DMARC policy along with a broken DKIM
signature causes latent interoperability problems to become overt
problems.
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
skipping to change at page 16, line 42 skipping to change at page 17, line 12
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 most well-known brands, all active domains are likely
targeted equally by abusers. to be 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 and using relaxed canonicalization. the header fields they sign and using relaxed canonicalization.
Using the DKIM length tag to allow appended signatures is Using the DKIM length tag to allow appended signatures is
discouraged due to the security risk created by allowing arbitrary discouraged due to the security risk created by allowing arbitrary
content to be appended to legitimate email. 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-
skipping to change at page 21, line 10 skipping to change at page 21, line 28
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 to
and changing the domain name should not be done with any domain. create an artificial 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
 End of changes. 19 change blocks. 
35 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/