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/