draft-ietf-dmarc-interoperability-09.txt   draft-ietf-dmarc-interoperability-10.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: May 8, 2016 Cisco Systems GmbH Expires: May 12, 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 5, 2015 November 9, 2015
Interoperability Issues Between DMARC and Indirect Email Flows Interoperability Issues Between DMARC and Indirect Email Flows
draft-ietf-dmarc-interoperability-09 draft-ietf-dmarc-interoperability-10
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 May 8, 2016. This Internet-Draft will expire on May 12, 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 3, line 10 skipping to change at page 3, line 10
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 . . . . . . . . . . . . . . . . . . . . . 20 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
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 . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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 18, line 42 skipping to change at page 18, line 42
useful in this case. In particular, extended status codes are useful in this case. In particular, extended status codes are
defined in [RFC7372] and in DMARC [RFC7489]. defined in [RFC7372] and in DMARC [RFC7489].
All these techniques may provide some specific challenges to MUAs and All these techniques may provide some specific challenges to MUAs and
different operational usages for end users (like rewriting filters to different operational usages for end users (like rewriting filters to
sort emails in folders). There will be some time before all sort emails in folders). There will be some time before all
implications are understood and accommodated. implications are understood and accommodated.
4.2. Proposed and In-Progress Mitigations 4.2. Proposed and In-Progress Mitigations
The following mitigations are based on Internet Drafts which have not The following mitigations are based on Internet Drafts (I-Ds) which
yet received broad consensus. They are described here to offer have not yet received broad consensus. They are described here to
exploratory path for solutions. These solutions should not be used offer exploratory path for solutions. These solutions should not be
in a production environment. used in a production environment. Because of the transient nature of
I-Ds, specific citations are not included because a number of them
o Third party authorization, [RFC6541], [I-D.otis-tpa-label] and will inevitably become obsolete and those which gain concensus in the
[I-D.kucherawy-dkim-delegate] provide ways to extend identifier community will become RFCs and should be discovered as such.
alignment under the control of the domain owner.
o DKIM with constrained transformations, o Third party authorization schemes provide ways to extend
[I-D.kucherawy-dkim-list-canon] is proposed to record a canonical identifier alignment under control of the domain owner.
list posting format for signing, so that typical MLM changes do
not invalidate signatures.
o DKIM with recorded transformations, [I-D.kucherawy-dkim-transform] o Ways to canonicalize messages that transit mailing lists so that
is proposed to indicate what limited transformations were done to their alterations can be isolated from the original signed
the message so that a receiver could reverse them and confirm the content.
validity of the orignal DKIM signature.
o [I-D.kucherawy-original-authres] is intended as a way to pass o Mechanisms to record message transformations applied at each hop
along Original Authentication Results to "downstream" receivers. so they can be reversed and the original signed content recovered.
It is not widely implemented and relies on a trust relationship
between the forwarder and the other receivers.
o [I-D.levine-dkim-conditional] could be used to have the sender add o "Conditional" DKIM signatures, whereby the author domain indicates
a limited DKIM signature, that signs only a very limited set of its signature is only good if accompanied by a signature from an
header fields and not the body of the message. If accompanied by expected downstream relay.
suitable other DKIM signature(s) it may be possible to achieve
DMARC alignment while limiting the possibilities of replay attack.
o [I-D.andersen-arc] (and the accompanying usage recommendations o Mechanisms to extend Authentication-Results [RFC7601] to multiple
[I-D.jones-arc-usage]) proposes a mechanism to provide an hops, creating a provable chain of custody as well as a view of
authenticated channel for the initial received authentication message authentication results at each handling step.
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
skipping to change at page 21, line 31 skipping to change at page 21, line 14
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76, "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011, RFC 6376, DOI 10.17487/RFC6376, September 2011,
<http://www.rfc-editor.org/info/rfc6376>. <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, DOI 10.17487/RFC6377, Mailing Lists", BCP 167, RFC 6377, DOI 10.17487/RFC6377,
September 2011, <http://www.rfc-editor.org/info/rfc6377>. September 2011, <http://www.rfc-editor.org/info/rfc6377>.
[RFC6541] Kucherawy, M., "DomainKeys Identified Mail (DKIM)
Authorized Third-Party Signatures", RFC 6541, DOI
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, DOI 10.17487/ Application Protocols", BCP 178, RFC 6648, DOI 10.17487/
RFC6648, June 2012, RFC6648, June 2012,
<http://www.rfc-editor.org/info/rfc6648>. <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,
DOI 10.17487/RFC7208, April 2014, DOI 10.17487/RFC7208, April 2014,
<http://www.rfc-editor.org/info/rfc7208>. <http://www.rfc-editor.org/info/rfc7208>.
[RFC7372] Kucherawy, M., "Email Authentication Status Codes", RFC [RFC7372] Kucherawy, M., "Email Authentication Status Codes", RFC
7372, DOI 10.17487/RFC7372, September 2014, 7372, DOI 10.17487/RFC7372, September 2014,
<http://www.rfc-editor.org/info/rfc7372>. <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]
Kucherawy, M. and D. Crocker, "Delegating DKIM Signing
Authority", draft-kucherawy-dkim-delegate-01 (work in
progress), June 2014.
[I-D.kucherawy-dkim-list-canon]
Kucherawy, M., "A List-safe Canonicalization for
DomainKeys Identified Mail (DKIM)", draft-kucherawy-dkim-
list-canon-00 (work in progress), June 2014.
[I-D.kucherawy-dkim-transform]
Kucherawy, M., "Recognized Transformations of Messages
Bearing DomainKeys Identified Mail (DKIM) Signatures",
draft-kucherawy-dkim-transform-00 (work in progress),
April 2015.
[I-D.kucherawy-original-authres]
Chew, M. and M. Kucherawy, "Original-Authentication-
Results Header Field", draft-kucherawy-original-authres-00
(work in progress), February 2012.
[I-D.levine-dkim-conditional]
Levine, J., "DKIM Conditional Signatures", draft-levine-
dkim-conditional-00 (work in progress), June 2014.
[I-D.otis-tpa-label]
Otis, D. and D. Black, "Third-Party Authorization Label",
draft-otis-tpa-label-00 (work in progress), May 2014.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<http://www.rfc-editor.org/info/rfc7489>. <http://www.rfc-editor.org/info/rfc7489>.
[RFC7601] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 7601, DOI 10.17487/
RFC7601, August 2015,
<http://www.rfc-editor.org/info/rfc7601>.
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
Eliot Lear (editor) Eliot Lear (editor)
Cisco Systems GmbH Cisco Systems GmbH
Richtistrasse 7 Richtistrasse 7
Wallisellen, ZH CH-8304 Wallisellen, ZH CH-8304
Switzerland Switzerland
Phone: +41 44 878 9200 Phone: +41 44 878 9200
Email: lear@cisco.com Email: lear@cisco.com
Tim Draegen (editor) Tim Draegen (editor)
 End of changes. 16 change blocks. 
86 lines changed or deleted 33 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/