draft-ietf-dmarc-interoperability-07.txt   draft-ietf-dmarc-interoperability-08.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: March 31, 2016 Cisco Systems GmbH Expires: April 21, 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
September 28, 2015 October 19, 2015
Interoperability Issues Between DMARC and Indirect Email Flows Interoperability Issues Between DMARC and Indirect Email Flows
draft-ietf-dmarc-interoperability-07 draft-ietf-dmarc-interoperability-08
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 March 31, 2016. This Internet-Draft will expire on April 21, 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 46 skipping to change at page 2, line 46
3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 10 3.2.2. ReSenders . . . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . 11
3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 12 3.2.4. Gateways . . . . . . . . . . . . . . . . . . . . . . 12
3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 12 3.2.5. Boundary Filters . . . . . . . . . . . . . . . . . . 12
3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 13 3.3. Combinations . . . . . . . . . . . . . . . . . . . . . . 13
4. Possible Mitigations of Interoperability Issues . . . . . . . 13 4. Possible Mitigations of Interoperability Issues . . . . . . . 13
4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 14 4.1. Mitigations in Current Use . . . . . . . . . . . . . . . 14
4.1.1. Mitigations for Senders . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . 16
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 . . . . . . . . . . 18
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 . . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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 an Informational RFC and has seen specification is published as Informational RFC7489 [RFC7489] and has
significant deployment within the email community. 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 13, line 20 skipping to change at page 13, line 20
modifications would invalidate a DKIM signature. modifications would invalidate a DKIM signature.
o Spam filtering: To protect reputation and assist other MTAs, an o Spam filtering: To protect reputation and assist other MTAs, an
MTA may modify a message to indicate its decision that the message 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 is likely to be unwanted, and/or add text in the body to indicate
that such filtering has been done. that such filtering has been done.
o Other text additions: An MTA may add an organizational disclaimer o Other text additions: An MTA may add an organizational disclaimer
or advertisement, for instance. or advertisement, for instance.
o URL alteration: Some systems will rewrite or alter embedded URLs
as a way to control the potential threat form 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.
skipping to change at page 19, line 29 skipping to change at page 19, line 29
o [I-D.levine-dkim-conditional] could be used to have the sender add o [I-D.levine-dkim-conditional] could be used to have the sender add
a limited DKIM signature, that signs only a very limited set of a limited DKIM signature, that signs only a very limited set of
header fields and not the body of the message. This DKIM header fields and not the body of the message. This DKIM
signature would come with the condition that a subsequent known signature would come with the condition that a subsequent known
domain fully DKIM sign the message. For instance a Mailing List domain fully DKIM sign the message. For instance a Mailing List
could transform the message, add its DKIM signature and there could transform the message, add its DKIM signature and there
would be a valid DKIM signature aligned with the RFC5322.From that would be a valid DKIM signature aligned with the RFC5322.From that
would satisfy DMARC while limiting the possibilities of replay would satisfy DMARC while limiting the possibilities of replay
attack. attack.
o [I-D.andersen-arc] (and the accompanying usage recommendations
[I-D.jones-arc-usage]) provides a proposed mechanism to provide an
authenticated channel for the initial received authentication
results to be conveyed through multiple ReSenders
("intermediaries" in the terminology used in the draft) to the
ultimate receiving system. This information is proposed as the
basis for improved local policy decisions by the receiver.
4.2.1. Getting More Radical: Requiring New Communication Paths Between 4.2.1. Getting More Radical: Requiring New Communication Paths Between
MUAs MUAs
In practice a number of operators are using strict alignment mode in In practice a number of operators are using strict alignment mode in
DMARC in order to avoid receiving new and innovative forms of DMARC in order to avoid receiving new and innovative forms of
unwanted and unauthentic email through systems purporting to be unwanted and unauthentic email through systems purporting to be
mailing list handlers. The receiving ADMD has no knowledge of which mailing list handlers. The receiving ADMD has no knowledge of which
lists the user has subscribed to and which they have not. One avenue lists the user has subscribed to and which they have not. One avenue
of exploration would be for the user to authorize mailing lists as of exploration would be for the user to authorize mailing lists as
proxies for authentication, at which point the receiving ADMD would proxies for authentication, at which point the receiving ADMD would
skipping to change at page 20, line 36 skipping to change at page 20, line 41
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
[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, DOI 10.17487/RFC2045, November 1996,
<http://www.rfc-editor.org/info/rfc2045>.
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
3463, January 2003. 3463, DOI 10.17487/RFC3463, January 2003,
<http://www.rfc-editor.org/info/rfc3463>.
[RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering [RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
Language", RFC 5228, January 2008. Filtering Language", RFC 5228, DOI 10.17487/RFC5228,
January 2008, <http://www.rfc-editor.org/info/rfc5228>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. DOI 10.17487/RFC5321, October 2008,
<http://www.rfc-editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI
October 2008. 10.17487/RFC5322, October 2008,
<http://www.rfc-editor.org/info/rfc5322>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI
2009. 10.17487/RFC5598, July 2009,
<http://www.rfc-editor.org/info/rfc5598>.
[RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part [RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part
Tests, Iteration, Extraction, Replacement, and Enclosure", Tests, Iteration, Extraction, Replacement, and Enclosure",
RFC 5703, October 2009. RFC 5703, DOI 10.17487/RFC5703, October 2009,
<http://www.rfc-editor.org/info/rfc5703>.
[RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
Identified Mail (DKIM) Signatures", STD 76, RFC 6376, "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
September 2011. RFC 6376, DOI 10.17487/RFC6376, September 2011,
<http://www.rfc-editor.org/info/rfc6376>.
[RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and
Mailing Lists", BCP 167, RFC 6377, September 2011. Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
September 2011, <http://www.rfc-editor.org/info/rfc6377>.
[RFC6541] Kucherawy, M., "DomainKeys Identified Mail (DKIM) [RFC6541] Kucherawy, M., "DomainKeys Identified Mail (DKIM)
Authorized Third-Party Signatures", RFC 6541, February Authorized Third-Party Signatures", RFC 6541, DOI
2012. 10.17487/RFC6541, February 2012,
<http://www.rfc-editor.org/info/rfc6541>.
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham,
"Deprecating the "X-" Prefix and Similar Constructs in "Deprecating the "X-" Prefix and Similar Constructs in
Application Protocols", BCP 178, RFC 6648, June 2012. Application Protocols", BCP 178, RFC 6648, DOI 10.17487/
RFC6648, June 2012,
<http://www.rfc-editor.org/info/rfc6648>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208, Authorizing Use of Domains in Email, Version 1", RFC 7208,
April 2014. DOI 10.17487/RFC7208, April 2014,
<http://www.rfc-editor.org/info/rfc7208>.
[RFC7372] Kucherawy, M., "Email Authentication Status Codes", RFC [RFC7372] Kucherawy, M., "Email Authentication Status Codes", RFC
7372, September 2014. 7372, DOI 10.17487/RFC7372, September 2014,
<http://www.rfc-editor.org/info/rfc7372>.
8.2. Informative References 8.2. Informative References
[I-D.andersen-arc]
None, N., Andersen, K., JohnRG, J., Long, B., Adams, J.,
and S. Jones, "Authenticated Received Chain (ARC)", draft-
andersen-arc-00 (work in progress), October 2015.
[I-D.jones-arc-usage]
None, N., Jones, S., JohnRG, J., Adams, J., and K.
Andersen, "Recommended Usage of the Authenticated Received
Chain (ARC)", draft-jones-arc-usage-00 (work in progress),
October 2015.
[I-D.kucherawy-dkim-delegate] [I-D.kucherawy-dkim-delegate]
Kucherawy, M. and D. Crocker, "Delegating DKIM Signing Kucherawy, M. and D. Crocker, "Delegating DKIM Signing
Authority", draft-kucherawy-dkim-delegate-01 (work in Authority", draft-kucherawy-dkim-delegate-01 (work in
progress), June 2014. progress), June 2014.
[I-D.kucherawy-dkim-list-canon] [I-D.kucherawy-dkim-list-canon]
Kucherawy, M., "A List-safe Canonicalization for Kucherawy, M., "A List-safe Canonicalization for
DomainKeys Identified Mail (DKIM)", draft-kucherawy-dkim- DomainKeys Identified Mail (DKIM)", draft-kucherawy-dkim-
list-canon-00 (work in progress), June 2014. list-canon-00 (work in progress), June 2014.
skipping to change at page 22, line 13 skipping to change at page 22, line 47
(work in progress), February 2012. (work in progress), February 2012.
[I-D.levine-dkim-conditional] [I-D.levine-dkim-conditional]
Levine, J., "DKIM Conditional Signatures", draft-levine- Levine, J., "DKIM Conditional Signatures", draft-levine-
dkim-conditional-00 (work in progress), June 2014. dkim-conditional-00 (work in progress), June 2014.
[I-D.otis-tpa-label] [I-D.otis-tpa-label]
Otis, D. and D. Black, "Third-Party Authorization Label", Otis, D. and D. Black, "Third-Party Authorization Label",
draft-otis-tpa-label-00 (work in progress), May 2014. draft-otis-tpa-label-00 (work in progress), May 2014.
[RFC7489] Kucherawy, M. and E. Zwicky, "Domain-based Message [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Authentication, Reporting, and Conformance (DMARC)", RFC Message Authentication, Reporting, and Conformance
7489, March 2015. (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<http://www.rfc-editor.org/info/rfc7489>.
Authors' Addresses Authors' Addresses
Franck Martin (editor) Franck Martin (editor)
LinkedIn LinkedIn
Mountain View, CA Mountain View, CA
USA USA
Email: fmartin@linkedin.com Email: fmartin@linkedin.com
 End of changes. 25 change blocks. 
32 lines changed or deleted 69 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/