draft-dmarc-base-12.txt		draft-dmarc-base.txt
	Network Working Group M. Kucherawy, Ed.		Network Working Group M. Kucherawy, Ed.
	Internet-Draft		Internet-Draft
	Intended status: Informational E. Zwicky, Ed.		Intended status: Informational E. Zwicky, Ed.
	Expires: July 17, 2015 Yahoo!		Expires: October 1, 2015 Yahoo!
	January 13, 2015		March 30, 2015
	Domain-based Message Authentication, Reporting and Conformance (DMARC)		Domain-based Message Authentication, Reporting and Conformance (DMARC)
	draft-kucherawy-dmarc-base-12		draft-kucherawy-dmarc-base-13
	Abstract		Abstract
	Domain-based Message Authentication, Reporting and Conformance		Domain-based Message Authentication, Reporting and Conformance
	(DMARC) is a scalable mechanism by which a mail-originating		(DMARC) is a scalable mechanism by which a mail-originating
	organization can express domain-level policies and preferences for		organization can express domain-level policies and preferences for
	message validation, disposition, and reporting, that a mail receiving		message validation, disposition, and reporting, that a mail receiving
	organization can use to improve mail handling.		organization can use to improve mail handling.
	Originators of Internet Mail need to be able to associate reliable		Originators of Internet Mail need to be able to associate reliable
	skipping to change at page 2, line 4		skipping to change at page 2, line 4
	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 July 17, 2015.		This Internet-Draft will expire on October 1, 2015.
	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 16		skipping to change at page 3, line 16
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.1. High-Level Goals . . . . . . . . . . . . . . . . . . . . . 7		2.1. High-Level Goals . . . . . . . . . . . . . . . . . . . . . 7
	2.2. Out Of Scope . . . . . . . . . . . . . . . . . . . . . . . 7		2.2. Out Of Scope . . . . . . . . . . . . . . . . . . . . . . . 7
	2.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7		2.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 7
	2.4. Anti-Phishing . . . . . . . . . . . . . . . . . . . . . . 8		2.4. Anti-Phishing . . . . . . . . . . . . . . . . . . . . . . 8
	3. Terminology and Definitions . . . . . . . . . . . . . . . . . 8		3. Terminology and Definitions . . . . . . . . . . . . . . . . . 8
	3.1. Identifier Alignment . . . . . . . . . . . . . . . . . . . 9		3.1. Identifier Alignment . . . . . . . . . . . . . . . . . . . 9
	3.2. Organizational Domain . . . . . . . . . . . . . . . . . . 12		3.2. Organizational Domain . . . . . . . . . . . . . . . . . . 12
	4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 12		4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	4.1. Authentication Mechanisms . . . . . . . . . . . . . . . . 13		4.1. Authentication Mechanisms . . . . . . . . . . . . . . . . 13
	4.2. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . 13		4.2. Key Concepts . . . . . . . . . . . . . . . . . . . . . . . 13
	4.3. Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . 14		4.3. Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . 14
	5. Use of RFC5322.From . . . . . . . . . . . . . . . . . . . . . 15		5. Use of RFC5322.From . . . . . . . . . . . . . . . . . . . . . 16
	6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16		6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	6.1. DMARC Policy Record . . . . . . . . . . . . . . . . . . . 17		6.1. DMARC Policy Record . . . . . . . . . . . . . . . . . . . 17
	6.2. DMARC URIs . . . . . . . . . . . . . . . . . . . . . . . . 17		6.2. DMARC URIs . . . . . . . . . . . . . . . . . . . . . . . . 17
	6.3. General Record Format . . . . . . . . . . . . . . . . . . 18		6.3. General Record Format . . . . . . . . . . . . . . . . . . 18
	6.4. Formal Definition . . . . . . . . . . . . . . . . . . . . 21		6.4. Formal Definition . . . . . . . . . . . . . . . . . . . . 22
	6.5. Domain Owner Actions . . . . . . . . . . . . . . . . . . . 23		6.5. Domain Owner Actions . . . . . . . . . . . . . . . . . . . 23
	6.6. Mail Receiver Actions . . . . . . . . . . . . . . . . . . 23		6.6. Mail Receiver Actions . . . . . . . . . . . . . . . . . . 23
	6.7. Policy Enforcement Considerations . . . . . . . . . . . . 27		6.7. Policy Enforcement Considerations . . . . . . . . . . . . 27
	7. DMARC Feedback . . . . . . . . . . . . . . . . . . . . . . . . 28		7. DMARC Feedback . . . . . . . . . . . . . . . . . . . . . . . . 28
	7.1. Verifying External Destinations . . . . . . . . . . . . . 28		7.1. Verifying External Destinations . . . . . . . . . . . . . 28
	7.2. Aggregate Reports . . . . . . . . . . . . . . . . . . . . 30		7.2. Aggregate Reports . . . . . . . . . . . . . . . . . . . . 30
	7.3. Failure Reports . . . . . . . . . . . . . . . . . . . . . 35		7.3. Failure Reports . . . . . . . . . . . . . . . . . . . . . 36
	8. Minimum Implementations . . . . . . . . . . . . . . . . . . . 37		8. Minimum Implementations . . . . . . . . . . . . . . . . . . . 38
	9. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 38		9. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 38
	9.1. Data Exposure Considerations . . . . . . . . . . . . . . . 38		9.1. Data Exposure Considerations . . . . . . . . . . . . . . . 38
	9.2. Report Recipients . . . . . . . . . . . . . . . . . . . . 39		9.2. Report Recipients . . . . . . . . . . . . . . . . . . . . 39
	10. Other Topics . . . . . . . . . . . . . . . . . . . . . . . . . 39		10. Other Topics . . . . . . . . . . . . . . . . . . . . . . . . . 40
	10.1. Issues Specific to SPF . . . . . . . . . . . . . . . . . . 39		10.1. Issues Specific to SPF . . . . . . . . . . . . . . . . . . 40
	10.2. DNS Load and Caching . . . . . . . . . . . . . . . . . . . 39		10.2. DNS Load and Caching . . . . . . . . . . . . . . . . . . . 40
	10.3. Rejecting Messages . . . . . . . . . . . . . . . . . . . . 40		10.3. Rejecting Messages . . . . . . . . . . . . . . . . . . . . 41
	10.4. Identifier Alignment Considerations . . . . . . . . . . . 41		10.4. Identifier Alignment Considerations . . . . . . . . . . . 42
	10.5. Interoperability Issues . . . . . . . . . . . . . . . . . 41		10.5. Interoperability Issues . . . . . . . . . . . . . . . . . 42
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
	11.1. Authentication-Results Method Registry Update . . . . . . 42		11.1. Authentication-Results Method Registry Update . . . . . . 42
	11.2. Authentication-Results Result Registry Update . . . . . . 42		11.2. Authentication-Results Result Registry Update . . . . . . 43
	11.3. Feedback Report Header Fields Registry Update . . . . . . 44		11.3. Feedback Report Header Fields Registry Update . . . . . . 44
	11.4. DMARC Tag Registry . . . . . . . . . . . . . . . . . . . . 44		11.4. DMARC Tag Registry . . . . . . . . . . . . . . . . . . . . 45
	11.5. DMARC Report Format Registry . . . . . . . . . . . . . . . 45		11.5. DMARC Report Format Registry . . . . . . . . . . . . . . . 46
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 46		12. Security Considerations . . . . . . . . . . . . . . . . . . . 47
	12.1. Authentication Methods . . . . . . . . . . . . . . . . . . 46		12.1. Authentication Methods . . . . . . . . . . . . . . . . . . 47
	12.2. Attacks on Reporting URIs . . . . . . . . . . . . . . . . 46		12.2. Attacks on Reporting URIs . . . . . . . . . . . . . . . . 47
	12.3. DNS Security . . . . . . . . . . . . . . . . . . . . . . . 47		12.3. DNS Security . . . . . . . . . . . . . . . . . . . . . . . 47
	12.4. Display Name Attacks . . . . . . . . . . . . . . . . . . . 47		12.4. Display Name Attacks . . . . . . . . . . . . . . . . . . . 48
	12.5. External Reporting Addresses . . . . . . . . . . . . . . . 48		12.5. External Reporting Addresses . . . . . . . . . . . . . . . 49
	12.6. Secure Protocols . . . . . . . . . . . . . . . . . . . . . 48		12.6. Secure Protocols . . . . . . . . . . . . . . . . . . . . . 49
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 49		13.1. Normative References . . . . . . . . . . . . . . . . . . . 50
	13.2. Informative References . . . . . . . . . . . . . . . . . . 50		13.2. Informative References . . . . . . . . . . . . . . . . . . 51
	Appendix A. Technology Considerations . . . . . . . . . . . . . . 51		Appendix A. Technology Considerations . . . . . . . . . . . . . . 52
	A.1. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . 51		A.1. S/MIME . . . . . . . . . . . . . . . . . . . . . . . . . . 52
	A.2. Method Exclusion . . . . . . . . . . . . . . . . . . . . . 52		A.2. Method Exclusion . . . . . . . . . . . . . . . . . . . . . 53
	A.3. Sender Header Field . . . . . . . . . . . . . . . . . . . 52		A.3. Sender Header Field . . . . . . . . . . . . . . . . . . . 53
	A.4. Domain Existence Test . . . . . . . . . . . . . . . . . . 53		A.4. Domain Existence Test . . . . . . . . . . . . . . . . . . 54
	A.5. Issues With ADSP In Operation . . . . . . . . . . . . . . 53		A.5. Issues With ADSP In Operation . . . . . . . . . . . . . . 54
	A.6. Organizational Domain Discovery Issues . . . . . . . . . . 54		A.6. Organizational Domain Discovery Issues . . . . . . . . . . 55
	Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 55		Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 56
	B.1. Identifier Alignment examples . . . . . . . . . . . . . . 55		B.1. Identifier Alignment examples . . . . . . . . . . . . . . 56
	B.2. Domain Owner example . . . . . . . . . . . . . . . . . . . 57		B.2. Domain Owner example . . . . . . . . . . . . . . . . . . . 58
	B.3. Mail Receiver Example . . . . . . . . . . . . . . . . . . 62		B.3. Mail Receiver Example . . . . . . . . . . . . . . . . . . 63
	B.4. Utilization of Aggregate Feedback example . . . . . . . . 64		B.4. Utilization of Aggregate Feedback example . . . . . . . . 65
	B.5. mailto Transport example . . . . . . . . . . . . . . . . . 64		B.5. mailto Transport example . . . . . . . . . . . . . . . . . 65
	Appendix C. DMARC XML Schema . . . . . . . . . . . . . . . . . . 65		Appendix C. DMARC XML Schema . . . . . . . . . . . . . . . . . . 66
	Appendix D. Public Discussion . . . . . . . . . . . . . . . . . . 72		Appendix D. Public Discussion . . . . . . . . . . . . . . . . . . 73
	Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 72		Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 73
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 72		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73
	1. Introduction		1. Introduction
	The Sender Policy Framework ([SPF]) and DomainKeys Identified Mail		The Sender Policy Framework ([SPF]) and DomainKeys Identified Mail
	([DKIM]) provide domain-level authentication. They enable		([DKIM]) provide domain-level authentication. They enable
	cooperating email receivers to detect mail authorized to use the		cooperating email receivers to detect mail authorized to use the
	domain name, which can permit differential handling. (A detailed		domain name, which can permit differential handling. (A detailed
	discussion of the threats these systems attempt to address can be		discussion of the threats these systems attempt to address can be
	found in [DKIM-THREATS].) However, there has been no single widely		found in [DKIM-THREATS].) However, there has been no single widely
	accepted or publicly available mechanism to communication of domain-		accepted or publicly available mechanism to communication of domain-
	skipping to change at page 5, line 30		skipping to change at page 5, line 30
	Over time, one-on-one relationships were established between select		Over time, one-on-one relationships were established between select
	senders and receivers with privately communicated means to assert		senders and receivers with privately communicated means to assert
	policy and receive message traffic and authentication disposition		policy and receive message traffic and authentication disposition
	reporting. Although these ad hoc practices have been generally		reporting. Although these ad hoc practices have been generally
	successful, they require significant manual coordination between		successful, they require significant manual coordination between
	parties, and this model does not scale for general use on the		parties, and this model does not scale for general use on the
	Internet.		Internet.
	This document defines Domain-based Message Authentication, Reporting		This document defines Domain-based Message Authentication, Reporting
	and Compliance (DMARC), a mechanism by which email operators leverage		and Conformance (DMARC), a mechanism by which email operators
	existing authentication and policy advertisement technologies to		leverage existing authentication and policy advertisement
	enable both message-stream feedback and enforcement of policies		technologies to enable both message-stream feedback and enforcement
	against unauthenticated email.		of policies against unauthenticated email.
	DMARC allows domain owners and receivers to collaborate by:		DMARC allows domain owners and receivers to collaborate by:
	1. Providing receivers with assertions about domain owners' policies		1. Providing receivers with assertions about domain owners' policies
	2. Providing feedback to senders so they can monitor authentication		2. Providing feedback to senders so they can monitor authentication
	and judge threats		and judge threats
	The basic outline of DMARC is:		The basic outline of DMARC is:
	skipping to change at page 10, line 4		skipping to change at page 10, line 4
	own messages, or reports about messages related to another		own messages, or reports about messages related to another
	operator. This term applies collectively to the system components		operator. This term applies collectively to the system components
	that receive and process these reports and the organizations that		that receive and process these reports and the organizations that
	operate them.		operate them.
	3.1. Identifier Alignment		3.1. Identifier Alignment
	Email authentication technologies authenticate various (and		Email authentication technologies authenticate various (and
	disparate) aspects of an individual message. For example, [DKIM]		disparate) aspects of an individual message. For example, [DKIM]
	authenticates the domain that affixed a signature to the message,		authenticates the domain that affixed a signature to the message,
	while [SPF] authenticates either the domain that appears in the		while [SPF] can authenticate either the domain that appears in the
	RFC5321.MailFrom portion of [SMTP] or the RFC5321.EHLO/HELO domain if		RFC5321.MailFrom portion of [SMTP] or the RFC5321.EHLO/HELO domain,
	the RFC5321.MailFrom is null (in the case of Delivery Status		or both. These may be different domains, and they are typically not
	Notifications). These may be different domains, and they are		visible to the end user.
	typically not visible to the end user.
	DMARC uses the RFC5322 [MAIL].From domain to evaluate the		DMARC authenticates use of the RFC5322 [MAIL].From domain by
	applicability of Authenticated Identifiers. The RFC5322 [MAIL].From		requiring that it matches (is aligned with) an Authenticated
	domain was selected as the central identity of the DMARC mechanism		Identifier. The RFC5322 [MAIL].From domain was selected as the
	because it is a required message header field and therefore		central identity of the DMARC mechanism because it is a required
	guaranteed to be present in compliant messages, and most MUAs		message header field and therefore guaranteed to be present in
	represent the RFC5322 [MAIL].From field as the originator of the		compliant messages, and most MUAs represent the RFC5322 [MAIL].From
	message and render some or all of this header field's content to end		field as the originator of the message and render some or all of this
	users.		header field's content to end users.
	Thus, this field is the one used by end users to identify the source		Thus, this field is the one used by end users to identify the source
	of the message, and therefore is a prime target for abuse. Many		of the message, and therefore is a prime target for abuse. Many
	high-profile email sources, such as email service providers, require		high-profile email sources, such as email service providers, require
	that the sending agent have authenticated before email can be		that the sending agent have authenticated before email can be
	generated. Thus, for these mailboxes, the mechanism described in		generated. Thus, for these mailboxes, the mechanism described in
	this document provides recipient end users with strong evidence that		this document provides recipient end users with strong evidence that
	the message was indeed originated by the agent they associate with		the message was indeed originated by the agent they associate with
	that mailbox, if the end user knows that these various protections		that mailbox, if the end user knows that these various protections
	have been provided.		have been provided.
	skipping to change at page 11, line 7		skipping to change at page 11, line 7
	succeed. From the perspective of DMARC, each can be operated in a		succeed. From the perspective of DMARC, each can be operated in a
	"strict" mode or a "relaxed" mode. A Domain Owner would normally		"strict" mode or a "relaxed" mode. A Domain Owner would normally
	select "strict" mode if it wanted Mail Receivers to apply DMARC		select "strict" mode if it wanted Mail Receivers to apply DMARC
	processing only to messages bearing an RFC5322.From domain exactly		processing only to messages bearing an RFC5322.From domain exactly
	matching the domains those mechanisms will verify. Using "relaxed"		matching the domains those mechanisms will verify. Using "relaxed"
	mode can be used when the operator also wishes to affect message		mode can be used when the operator also wishes to affect message
	flows bearing subdomains of the verified domains.		flows bearing subdomains of the verified domains.
	3.1.1. DKIM-authenticated Identifiers		3.1.1. DKIM-authenticated Identifiers
	DMARC provides the option of applying DKIM in a strict or relaxed		DMARC permits identifier alignment, based on the result of a DKIM
	identifier alignment mode. (Note that these are not related to		authentication, to be strict or relaxed. (Note that these are not
	DKIM's "simple" and "relaxed" canonicalization modes.)		related to DKIM's "simple" and "relaxed" canonicalization modes.)
	In relaxed mode, the Organizational Domains of both the [DKIM]-		In relaxed mode, the Organizational Domains of both the [DKIM]-
	authenticated signing domain (taken from the value of the "d=" tag in		authenticated signing domain (taken from the value of the "d=" tag in
	the signature) and that of the RFC5322.From domain must be equal if		the signature) and that of the RFC5322.From domain must be equal if
	the identifiers are to be considered aligned. In strict mode, only		the identifiers are to be considered aligned. In strict mode, only
	an exact match between both of the Fully Qualified Domain Names		an exact match between both of the Fully Qualified Domain Names
	(FQDN) is considered to produce identifier alignment.		(FQDN) is considered to produce identifier alignment.
	To illustrate, in relaxed mode, if a validated DKIM signature		To illustrate, in relaxed mode, if a validated DKIM signature
	successfully verifies with a "d=" domain of "example.com", and the		successfully verifies with a "d=" domain of "example.com", and the
	skipping to change at page 11, line 41		skipping to change at page 11, line 41
	signature from any domain, including domains used by a mailing list		signature from any domain, including domains used by a mailing list
	or even a bad actor. Therefore, merely bearing a valid signature is		or even a bad actor. Therefore, merely bearing a valid signature is
	not enough to infer authenticity of the Author Domain.		not enough to infer authenticity of the Author Domain.
	Note that a single email can contain multiple DKIM signatures, and it		Note that a single email can contain multiple DKIM signatures, and it
	is considered to be a DMARC "pass" if any DKIM signature is aligned		is considered to be a DMARC "pass" if any DKIM signature is aligned
	and verifies.		and verifies.
	3.1.2. SPF-authenticated Identifiers		3.1.2. SPF-authenticated Identifiers
	DMARC provides the option of applying SPF in a strict or relaxed		DMARC permits identifier alignment, based on the result of an SPF
	identifier alignment mode.		authentication, to be strict or relaxed.
	In relaxed mode, the [SPF]-authenticated domain and RFC5322.From		In relaxed mode, the [SPF]-authenticated domain and RFC5322.From
	domain must have the same Organizational Domain. In strict mode,		domain must have the same Organizational Domain. In strict mode,
	only an exact DNS domain match is considered to produce identifier		only an exact DNS domain match is considered to produce identifier
	alignment.		alignment.
			Note that the RFC5321.HELO identity is not typically used in the
			context of DMARC (except when required to "fake" an otherwise null
			reverse-path), even though a "pure SPF" implementation according to
			[SPF] would check that identifier.
	For example, if a message passes an SPF check with an		For example, if a message passes an SPF check with an
	RFC5321.MailFrom domain of "cbg.bounces.example.com", and the address		RFC5321.MailFrom domain of "cbg.bounces.example.com", and the address
	portion of the RFC5322.From field contains "payments@example.com",		portion of the RFC5322.From field contains "payments@example.com",
	the Authenticated RFC5321.MailFrom domain identifier and the		the Authenticated RFC5321.MailFrom domain identifier and the
	RFC5322.From domain are considered to be "in alignment" in relaxed		RFC5322.From domain are considered to be "in alignment" in relaxed
	mode, but not in strict mode.		mode, but not in strict mode.
	3.1.3. Alignment and Extension Technologies		3.1.3. Alignment and Extension Technologies
	If in the future DMARC is extended to include the use of other		If in the future DMARC is extended to include the use of other
	skipping to change at page 13, line 13		skipping to change at page 13, line 18
	of the DMARC environment.		of the DMARC environment.
	4.1. Authentication Mechanisms		4.1. Authentication Mechanisms
	The following mechanisms for determining Authenticated Identifiers		The following mechanisms for determining Authenticated Identifiers
	are supported in this version of DMARC:		are supported in this version of DMARC:
	o [DKIM], which provides a domain-level identifier in the content of		o [DKIM], which provides a domain-level identifier in the content of
	the "d=" tag of a validated DKIM-Signature header field.		the "d=" tag of a validated DKIM-Signature header field.
	o [SPF], which authenticates the domain found in an [SMTP] MAIL		o [SPF], which can authenticate both the domain found in an [SMTP]
	command when it is the authorized domain.		HELO/EHLO command (the HELO identity) and the domain found in an
			SMTP MAIL command (the MAIL FROM identity). DMARC uses the result
			of SPF authentication of the MAIL FROM identity. Section 2.4 of
			[SPF] describes MAIL FROM processing for cases in which the MAIL
			command has a null path.
	4.2. Key Concepts		4.2. Key Concepts
	DMARC policies are published by the Domain Owner, and retrieved by		DMARC policies are published by the Domain Owner, and retrieved by
	the Mail Receiver during the SMTP session, via the DNS.		the Mail Receiver during the SMTP session, via the DNS.
	DMARC's filtering function is based on whether SPF or DKIM can		DMARC's filtering function is based on whether the RFC5322.From field
	provide an authenticated, aligned identifier for the message under		domain is aligned with (matches) an authenticated domain name from
	consideration. Messages that purport to be from a Domain Owner's		SPF or DKIM. When a DMARC policy is published for the domain name
	domain and arrive from servers that are not authorized by that		found in the RFC5322.From field, and that domain name is not
	domain's SPF record and do not contain an appropriate DKIM signature		validated through SPF or DKIM, the disposition of that message can be
	can be affected by DMARC policies.		affected by that DMARC policy when delivered to a participating
			receiver.
	It is important to note that the authentication mechanisms employed		It is important to note that the authentication mechanisms employed
	by DMARC authenticate only a DNS domain, and do not authenticate the		by DMARC authenticate only a DNS domain, and do not authenticate the
	local-part of any email address identifier found in a message, nor		local-part of any email address identifier found in a message, nor
	does it validate the legitimacy of message content.		does it validate the legitimacy of message content.
	DMARC's feedback component involves the collection of information		DMARC's feedback component involves the collection of information
	about received messages claiming to be from the Organizational Domain		about received messages claiming to be from the Organizational Domain
	for periodic aggregate reports to the Domain Owner. The parameters		for periodic aggregate reports to the Domain Owner. The parameters
	and format for such reports are discussed in later sections of this		and format for such reports are discussed in later sections of this
	skipping to change at page 72, line 29		skipping to change at page 73, line 29
	Fidelity Investments, Google, JPMorgan Chase & Company, LinkedIn,		Fidelity Investments, Google, JPMorgan Chase & Company, LinkedIn,
	Microsoft, Netease, PayPal, ReturnPath, The Trusted Domain Project,		Microsoft, Netease, PayPal, ReturnPath, The Trusted Domain Project,
	and Yahoo!. Although the number of contributors and supporters are		and Yahoo!. Although the number of contributors and supporters are
	too numerous to mention, notable individual contributions were made		too numerous to mention, notable individual contributions were made
	by J. Trent Adams, Michael Adkins, Monica Chew, Dave Crocker, Tim		by J. Trent Adams, Michael Adkins, Monica Chew, Dave Crocker, Tim
	Draegen, Steve Jones, Franck Martin, Brett McDowell, and Paul Midgen.		Draegen, Steve Jones, Franck Martin, Brett McDowell, and Paul Midgen.
	The contributors would also like to recognize the invaluable input		The contributors would also like to recognize the invaluable input
	and guidance that was provided early on by J.D. Falk.		and guidance that was provided early on by J.D. Falk.
	Additional contributions within the IETF context were made by Kurt		Additional contributions within the IETF context were made by Kurt
	Anderson, Les Barstow, Jim Fenton, J. Gomez, Mike Jones, Scott		Anderson, Michael Jack Assels, Les Barstow, Anne Bennett, Jim Fenton,
	Kitterman, Eliot Lear, John Levine, S. Moonesamy, Rolf Sonneveld,		J. Gomez, Mike Jones, Scott Kitterman, Eliot Lear, John Levine, S.
	Henry Timmes, and Stephen J. Turnbull.		Moonesamy, Rolf Sonneveld, Henry Timmes, and Stephen J. Turnbull.
	Authors' Addresses		Authors' Addresses
	Murray S. Kucherawy (editor)		Murray S. Kucherawy (editor)
	Email: superuser@gmail.com		Email: superuser@gmail.com
	Elizabeth Zwicky (editor)		Elizabeth Zwicky (editor)
	Yahoo!		Yahoo!
End of changes. 20 change blocks.
	77 lines changed or deleted		86 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/