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/