< draft-ietf-dmarc-dmarcbis-06.txt		draft-ietf-dmarc-dmarcbis-07.txt >
	DMARC T. Herr (ed)		DMARC T. Herr (ed)
	Internet-Draft Valimail		Internet-Draft Valimail
	Obsoletes: 7489 (if approved) J. Levine (ed)		Obsoletes: 7489 (if approved) J. Levine (ed)
	Intended status: Standards Track Standcore LLC		Intended status: Standards Track Standcore LLC
	Expires: 22 September 2022 21 March 2022		Expires: 8 October 2022 6 April 2022
	Domain-based Message Authentication, Reporting, and Conformance (DMARC)		Domain-based Message Authentication, Reporting, and Conformance (DMARC)
	draft-ietf-dmarc-dmarcbis-06		draft-ietf-dmarc-dmarcbis-07
	Abstract		Abstract
	This document describes the Domain-based Message Authentication,		This document describes the Domain-based Message Authentication,
	Reporting, and Conformance (DMARC) protocol.		Reporting, and Conformance (DMARC) protocol.
	DMARC permits the owner of an email author's domain name to enable		DMARC permits the owner of an email author's domain name to enable
	verification of the domain's use, to indicate the Domain Owner's or		verification of the domain's use, to indicate the Domain Owner's or
	Public Suffix Operator's message handling preference regarding failed		Public Suffix Operator's message handling preference regarding failed
	verification, and to request reports about use of the domain name.		verification, and to request reports about use of the domain name.
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 22 September 2022.		This Internet-Draft will expire on 8 October 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 51 ¶		skipping to change at page 2, line 51 ¶
	4.4.1. DKIM-Authenticated Identifiers . . . . . . . . . . . 13		4.4.1. DKIM-Authenticated Identifiers . . . . . . . . . . . 13
	4.4.2. SPF-Authenticated Identifiers . . . . . . . . . . . . 14		4.4.2. SPF-Authenticated Identifiers . . . . . . . . . . . . 14
	4.4.3. Alignment and Extension Technologies . . . . . . . . 14		4.4.3. Alignment and Extension Technologies . . . . . . . . 14
	4.5. Flow Diagram . . . . . . . . . . . . . . . . . . . . . . 14		4.5. Flow Diagram . . . . . . . . . . . . . . . . . . . . . . 14
	4.6. DNS Tree Walk . . . . . . . . . . . . . . . . . . . . . . 16		4.6. DNS Tree Walk . . . . . . . . . . . . . . . . . . . . . . 16
	4.7. DMARC Policy Discovery . . . . . . . . . . . . . . . . . 17		4.7. DMARC Policy Discovery . . . . . . . . . . . . . . . . . 17
	4.8. Organizational Domain Discovery . . . . . . . . . . . . . 18		4.8. Organizational Domain Discovery . . . . . . . . . . . . . 18
	5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 20		5. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	5.1. DMARC Policy Record . . . . . . . . . . . . . . . . . . . 21		5.1. DMARC Policy Record . . . . . . . . . . . . . . . . . . . 21
	5.2. DMARC URIs . . . . . . . . . . . . . . . . . . . . . . . 21		5.2. DMARC URIs . . . . . . . . . . . . . . . . . . . . . . . 21
	5.3. General Record Format . . . . . . . . . . . . . . . . . . 21		5.3. General Record Format . . . . . . . . . . . . . . . . . . 22
	5.4. Formal Definition . . . . . . . . . . . . . . . . . . . . 25		5.4. Formal Definition . . . . . . . . . . . . . . . . . . . . 25
	5.5. Domain Owner Actions . . . . . . . . . . . . . . . . . . 27		5.5. Domain Owner Actions . . . . . . . . . . . . . . . . . . 27
	5.5.1. Publish an SPF Policy for an Aligned Domain . . . . . 27		5.5.1. Publish an SPF Policy for an Aligned Domain . . . . . 27
	5.5.2. Configure Sending System for DKIM Signing Using an		5.5.2. Configure Sending System for DKIM Signing Using an
	Aligned Domain . . . . . . . . . . . . . . . . . . . 27		Aligned Domain . . . . . . . . . . . . . . . . . . . 27
	5.5.3. Setup a Mailbox to Receive Aggregate Reports . . . . 27		5.5.3. Setup a Mailbox to Receive Aggregate Reports . . . . 27
	5.5.4. Publish a DMARC Policy for the Author Domain . . . . 28		5.5.4. Publish a DMARC Policy for the Author Domain and
			Organizational Domain . . . . . . . . . . . . . . . . 28
	5.5.5. Collect and Analyze Reports . . . . . . . . . . . . . 28		5.5.5. Collect and Analyze Reports . . . . . . . . . . . . . 28
	5.5.6. Decide If and When to Update DMARC Policy . . . . . . 28		5.5.6. Decide If and When to Update DMARC Policy . . . . . . 28
	5.6. PSO Actions . . . . . . . . . . . . . . . . . . . . . . . 28		5.6. PSO Actions . . . . . . . . . . . . . . . . . . . . . . . 28
	5.7. Mail Receiver Actions . . . . . . . . . . . . . . . . . . 28		5.7. Mail Receiver Actions . . . . . . . . . . . . . . . . . . 29
	5.7.1. Extract Author Domain . . . . . . . . . . . . . . . . 28		5.7.1. Extract Author Domain . . . . . . . . . . . . . . . . 29
	5.7.2. Determine Handling Policy . . . . . . . . . . . . . . 29		5.7.2. Determine Handling Policy . . . . . . . . . . . . . . 29
	5.7.3. Store Results of DMARC Processing . . . . . . . . . . 30		5.7.3. Store Results of DMARC Processing . . . . . . . . . . 30
	5.7.4. Send Aggregate Reports . . . . . . . . . . . . . . . 30		5.7.4. Send Aggregate Reports . . . . . . . . . . . . . . . 31
	5.8. Policy Enforcement Considerations . . . . . . . . . . . . 31		5.8. Policy Enforcement Considerations . . . . . . . . . . . . 31
	6. DMARC Feedback . . . . . . . . . . . . . . . . . . . . . . . 32		6. DMARC Feedback . . . . . . . . . . . . . . . . . . . . . . . 32
	7. Other Topics . . . . . . . . . . . . . . . . . . . . . . . . 32		7. Other Topics . . . . . . . . . . . . . . . . . . . . . . . . 32
	7.1. Issues Specific to SPF . . . . . . . . . . . . . . . . . 32		7.1. Issues Specific to SPF . . . . . . . . . . . . . . . . . 33
	7.2. DNS Load and Caching . . . . . . . . . . . . . . . . . . 33		7.2. DNS Load and Caching . . . . . . . . . . . . . . . . . . 33
	7.3. Rejecting Messages . . . . . . . . . . . . . . . . . . . 33		7.3. Rejecting Messages . . . . . . . . . . . . . . . . . . . 33
	7.4. Identifier Alignment Considerations . . . . . . . . . . . 34		7.4. Identifier Alignment Considerations . . . . . . . . . . . 34
	7.5. Interoperability Issues . . . . . . . . . . . . . . . . . 34		7.5. Interoperability Issues . . . . . . . . . . . . . . . . . 35
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
	8.1. Authentication-Results Method Registry Update . . . . . . 35		8.1. Authentication-Results Method Registry Update . . . . . . 35
	8.2. Authentication-Results Result Registry Update . . . . . . 36		8.2. Authentication-Results Result Registry Update . . . . . . 36
	8.3. Feedback Report Header Fields Registry Update . . . . . . 37		8.3. Feedback Report Header Fields Registry Update . . . . . . 37
	8.4. DMARC Tag Registry . . . . . . . . . . . . . . . . . . . 37		8.4. DMARC Tag Registry . . . . . . . . . . . . . . . . . . . 38
	8.5. DMARC Report Format Registry . . . . . . . . . . . . . . 39		8.5. DMARC Report Format Registry . . . . . . . . . . . . . . 39
	8.6. Underscored and Globally Scoped DNS Node Names		8.6. Underscored and Globally Scoped DNS Node Names
	Registry . . . . . . . . . . . . . . . . . . . . . . . . 40		Registry . . . . . . . . . . . . . . . . . . . . . . . . 40
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 40		9. Security Considerations . . . . . . . . . . . . . . . . . . . 40
	9.1. Authentication Methods . . . . . . . . . . . . . . . . . 40		9.1. Authentication Methods . . . . . . . . . . . . . . . . . 40
	9.2. Attacks on Reporting URIs . . . . . . . . . . . . . . . . 41		9.2. Attacks on Reporting URIs . . . . . . . . . . . . . . . . 41
	9.3. DNS Security . . . . . . . . . . . . . . . . . . . . . . 41		9.3. DNS Security . . . . . . . . . . . . . . . . . . . . . . 41
	9.4. Display Name Attacks . . . . . . . . . . . . . . . . . . 42		9.4. Display Name Attacks . . . . . . . . . . . . . . . . . . 42
	9.5. External Reporting Addresses . . . . . . . . . . . . . . 42		9.5. External Reporting Addresses . . . . . . . . . . . . . . 42
	9.6. Secure Protocols . . . . . . . . . . . . . . . . . . . . 43		9.6. Secure Protocols . . . . . . . . . . . . . . . . . . . . 43
	skipping to change at page 16, line 40 ¶		skipping to change at page 16, line 40 ¶
	The generic steps for a DNS Tree Walk are as follows:		The generic steps for a DNS Tree Walk are as follows:
	1. Query the DNS for a DMARC TXT record at the DNS domain matching		1. Query the DNS for a DMARC TXT record at the DNS domain matching
	the one found in the domain(s) described above. A possibly empty		the one found in the domain(s) described above. A possibly empty
	set of records is returned.		set of records is returned.
	2. Records that do not start with a "v=" tag that identifies the		2. Records that do not start with a "v=" tag that identifies the
	current version of DMARC are discarded. If multiple DMARC		current version of DMARC are discarded. If multiple DMARC
	records are returned, they are all discarded.		records are returned, they are all discarded.
	3. If the set is now empty, then determine the target for additional		3. Determine the target for additional queries (if needed; see the
	queries, using steps 4 through 8 below.		note in Section 4.8), using steps 4 through 8 below.
	4. Break the subject DNS domain name into a set of "n" ordered		4. Break the subject DNS domain name into a set of "n" ordered
	labels. Number these labels from right to left; e.g., for		labels. Number these labels from right to left; e.g., for
	"a.mail.example.com", "com" would be label 1, "example" would be		"a.mail.example.com", "com" would be label 1, "example" would be
	label 2, "mail.example.com" would be label 3, and so forth.		label 2, "mail.example.com" would be label 3, and so forth.
	5. Count the number of labels found in the subject DNS domain. Let		5. Count the number of labels found in the subject DNS domain. Let
	that number be "x". If x < 5, remove the left-most (highest-		that number be "x". If x < 5, remove the left-most (highest-
	numbered) label from the subject domain. If x >= 5, remove the		numbered) label from the subject domain. If x >= 5, remove the
	left-most (highest-numbered) labels from the subject domain until		left-most (highest-numbered) labels from the subject domain until
	4 labels remain. The resulting DNS domain name is the new target		4 labels remain. The resulting DNS domain name is the new target
	for subsequent lookups.		for subsequent lookups.
	6. Query the DNS for a DMARC TXT record at the DNS domain matching		6. Query the DNS for a DMARC TXT record at the DNS domain matching
	this new target in place of the RFC5322.From domain in the		this new target in place of the RFC5322.From domain in the
	message. A possibly empty set of records is returned.		message. A possibly empty set of records is returned.
	7. Records that do not start with a "v=" tag that identifies the		7. Records that do not start with a "v=" tag that identifies the
	current version of DMARC are discarded. If multiple DMARC		current version of DMARC are discarded. If multiple DMARC
	records are returned, they are all discarded.		records are returned for a single target, they are all discarded.
	8. If the set is now empty, determine the target for additional		8. Determine the target for additional queries by removing a single
	queries by removing a single label from the target domain as		label from the target domain as described in step 5 and repeating
	described in step 5 and repeating steps 6 and 7 until there are		steps 6 and 7 until there are no more labels remaining.
	no more labels remaining.
	To illustrate, for a message with the arbitrary RFC5322.From domain		To illustrate, for a message with the arbitrary RFC5322.From domain
	of "a.b.c.d.e.mail.example.com", a full DNS Tree Walk would require		of "a.b.c.d.e.mail.example.com", a full DNS Tree Walk would require
	the following five queries, in order to locate the policy or		the following five queries, in order to locate the policy or
	Organizational Domain:		Organizational Domain:
	* _dmarc.a.b.c.d.e.mail.example.com		* _dmarc.a.b.c.d.e.mail.example.com
	* _dmarc.e.mail.example.com		* _dmarc.e.mail.example.com
	skipping to change at page 18, line 4 ¶		skipping to change at page 18, line 4 ¶
	hierarchy that matches the domain in the RFC5322.From header of the		hierarchy that matches the domain in the RFC5322.From header of the
	message. The DMARC policy to be applied to the message will be the		message. The DMARC policy to be applied to the message will be the
	record found at one of these three locations:		record found at one of these three locations:
	* The RFC5322.From domain		* The RFC5322.From domain
	* The Organizational Domain (as determined by a separate DNS Tree		* The Organizational Domain (as determined by a separate DNS Tree
	Walk) of the RFC5322.From domain		Walk) of the RFC5322.From domain
	* The Public Suffix Domain of the RFC5322.From domain		* The Public Suffix Domain of the RFC5322.From domain
			If the DMARC policy to be applied is that of the RFC5322.From domain,
			then the DMARC policy is taken from the p= tag of the record. If the
			DMARC policy is taken from either the Organizational Domain or the
			Public Suffix Domain and that domain is different than the
			RFC5322.From domain, then the DMARC policy is taken from the sp= tag
			(if any) if the RFC5322.From domain exists and the np= tag (if any)
			if the RFC5322.From domain does not exist. In the absence of
			applicable sp= or np= tags, the p= tag policy is used for subdomains.
	If a retrieved policy record does not contain a valid "p" tag, or		If a retrieved policy record does not contain a valid "p" tag, or
	contains an "sp" tag that is not valid, then:		contains an "sp" tag that is not valid, then:
	* If a "rua" tag is present and contains at least one syntactically		* If a "rua" tag is present and contains at least one syntactically
	valid reporting URI, the Mail Receiver SHOULD act as if a record		valid reporting URI, the Mail Receiver SHOULD act as if a record
	containing a valid "v" tag and "p=none" was retrieved, and		containing a valid "v" tag and "p=none" was retrieved, and
	continue processing;		continue processing;
	* Otherwise, the Mail Receiver applies no DMARC processing to this		* Otherwise, the Mail Receiver applies no DMARC processing to this
	message.		message.
	skipping to change at page 19, line 5 ¶		skipping to change at page 19, line 14 ¶
	* The RFC5321.MailFrom domain if there is an SPF pass result for the		* The RFC5321.MailFrom domain if there is an SPF pass result for the
	message.		message.
	* Any DKIM d= domain if there is a DKIM pass result for the message		* Any DKIM d= domain if there is a DKIM pass result for the message
	for that domain.		for that domain.
	Note: There is no need to perform Tree Walk searches for		Note: There is no need to perform Tree Walk searches for
	Organizational Domains under any of the following conditions:		Organizational Domains under any of the following conditions:
			* The RFC5322.From domain and the RFC5321.MailFrom domain (if SPF
			authenticated), and/or the DKIM d= domain (if present and
			authenticated) are all the same and that domain has a DMARC
			record. In this case, this common domain is treated as the
			Organizational Domain.
	* No applicable DMARC policy is discovered for the RFC5322.From		* No applicable DMARC policy is discovered for the RFC5322.From
	domain during the first tree walk. In this case, the DMARC		domain during the first tree walk. In this case, the DMARC
	mechanism does not apply to the message in question.		mechanism does not apply to the message in question.
	* There is no SPF pass result and no DKIM pass result for the		* There is no SPF pass result and no DKIM pass result for the
	message. In this case, there can be no DMARC pass result, and so		message. In this case, there can be no DMARC pass result, and so
	the Organizational Domain of any domain is not required to be		the Organizational Domain of any domain is not required to be
	discoverd.		discovered.
	* The record for the RFC5322.From domain indicates strict alignment.		* The record for the RFC5322.From domain indicates strict alignment.
	In this case, a simple string compare between the RFC5322.From		In this case, a simple string compare between the RFC5322.From
	domain and the RFC5321.MailFrom domain (if SPF authenticated),		domain and the RFC5321.MailFrom domain (if SPF authenticated),
	and/or the DKIM d= domain (if present and authenticated) is all		and/or the DKIM d= domain (if present and authenticated) is all
	that is required.		that is required.
	To discover the Organizational Domain for a domain, perform the DNS		To discover the Organizational Domain for a domain, perform the DNS
	Tree Walk described in Section 4.6 as needed for any of the domains		Tree Walk described in Section 4.6 as needed for any of the domains
	in question.		in question.
	Select the Organizational Domain from the domains for which valid		Select the Organizational Domain from the domains for which valid
	DMARC records were retrieved in the following sequence:		DMARC records were retrieved from the longest to the shortest:
	1. If a valid DMARC record explicitly contains the psd= tag set to		1. If a valid DMARC record contains the psd= tag set to 'n' (psd=n),
	'n' (psd=n), this is the Organizational Domain and the selection		this is the Organizational Domain and the selection process is
	process is complete.		complete.
	2. From the DMARC records that contain the psd= tag set to 'y'		2. If a valid DMARC record contains the psd= tag set to 'y' (psd=y),
	(psd=y), select the record for the domain with the largest number		the Organizational Domain is the domain one label below this one
	of labels that is also not the starting point for this Tree Walk,		in the DNS hierarchy, and the selection process is complete.
	if such domain exists. The Organizational Domain is the domain
	one label below this one in the DNS hierarchy, and the selection
	process is complete.
	3. From the DMARC records that do not contain the psd= tag set to		3. If the selection process completes and all records contain
	'y' (psd=y), select the record for the domain with the smallest		(either explicitly or implicitly, since this is the default) the
	number of labels. This is the Organizational Domain and the		psd= tag set to 'u' (psd=u), select the record for the domain
	selection process is complete.		with the fewest number of labels. This is the Organizational
			Domain and the selection process is complete.
	If this process does not determine the Organizational Domain, then		If this process does not determine the Organizational Domain, then
	the initial target domain is the Organizational Domain.		the initial target domain is the Organizational Domain.
	For example, given the starting domain "a.mail.example.com", a search		For example, given the starting domain "a.mail.example.com", a search
	for the Organizational Domain would require a series of DNS queries		for the Organizational Domain would require a series of DNS queries
	for DMARC records starting with "_dmarc.a.mail.example.com" and		for DMARC records starting with "_dmarc.a.mail.example.com" and
	finishing with "_dmarc.com". If there are DMARC records for		finishing with "_dmarc.com". If there are DMARC records for
	"_dmarc.mail.example.com" and "_dmarc.example.com", but not for		"_dmarc.mail.example.com" and "_dmarc.example.com", but not for
	"_dmarc.a.mail.example.com" or "_dmarc.com", then the Organizational		"_dmarc.a.mail.example.com" or "_dmarc.com", then the Organizational
	Domain for this domain would be "example.com".		Domain for this domain would be "example.com".
	As another example, given the starting domain "a.mail.example.com",		As another example, given the starting domain "a.mail.example.com",
	if a search for the Organizational Domain only yields a DMARC record		if a search for the Organizational Domain only yields a DMARC record
	at "_dmarc.com" and that record contains the tag psd=y, then the		at "_dmarc.com" and that record contains the tag psd=y, then the
	Organizational Domain for this domain would be "example.com".		Organizational Domain for this domain would be "example.com".
	Note: Since 'n' is the default value for the psd tag, it might be
	argued that all DMARC policy records that do not contain psd=y then
	necessarily contain psd=n. To be clear, step 1 from the above three-
	step sequence of determining the Organizational Domain refers only to
	those DMARC policy records that actually contain the tag-value pair
	'psd=n', to cover the very unusual case of a parent PSD publishing a
	DMARC record without the requisite 'psd=y' tag.
	5. Policy		5. Policy
	A Domain Owner or PSO advertises DMARC participation of one or more		A Domain Owner or PSO advertises DMARC participation of one or more
	of its domains by adding a DNS TXT record (described in Section 5.1)		of its domains by adding a DNS TXT record (described in Section 5.1)
	to those domains. In doing so, Domain Owners and PSOs indicate their		to those domains. In doing so, Domain Owners and PSOs indicate their
	handling preference regarding failed authentication for email		handling preference regarding failed authentication for email
	messages making use of their domain in the RFC5322.From header field		messages making use of their domain in the RFC5322.From header field
	as well as their desire for feedback about those messages. Mail		as well as their desire for feedback about those messages. Mail
	Receivers in turn can take into account the Domain Owner's stated		Receivers in turn can take into account the Domain Owner's stated
	preference when making handling decisions about email messages that		preference when making handling decisions about email messages that
	skipping to change at page 23, line 41 ¶		skipping to change at page 23, line 49 ¶
	quarantine: The Domain Owner considers such mail to be		quarantine: The Domain Owner considers such mail to be
	suspicious. It is possible the mail is valid, although the		suspicious. It is possible the mail is valid, although the
	failure creates a significant concern.		failure creates a significant concern.
	reject: The Domain Owner considers all such failures to be a		reject: The Domain Owner considers all such failures to be a
	clear indication that the use of the domain name is not valid.		clear indication that the use of the domain name is not valid.
	See Section 7.3 for some discussion of SMTP rejection methods		See Section 7.3 for some discussion of SMTP rejection methods
	and their implications.		and their implications.
	psd: A flag indicating whether the domain is a PSD. (plain-text;		psd: A flag indicating whether the domain is a PSD. (plain-text;
	OPTIONAL; default is 'n'). Possible values are:		OPTIONAL; default is 'u'). Possible values are:
	y: Domains on the PSL that publish DMARC policy records SHOULD		y: PSOs MUSTinclude this tag with a value of 'y' to indicate that
	include this tag with a value of 'y' to indicate that the		the domain is a PSD. If a record containing this tag with a
	domain is a PSD. If a record containing this tag with a value		value of 'y' is found during policy discovery, this information
	of 'y' is found during policy discovery, this information will		will be used to determine the Organizational Domain and policy
	be used to determine the Organizational Domain applicable to		domain applicable to the message in question.
	the message in question.
	n: The default, indicating that the DMARC policy record is		n: The DMARC policy record is published for a PSD, but it is the
	published for a domain that is not a PSD. There is no need to		Organizational Domain for itself and its subdomain. There is
	put psd=n in a DMARC record, except in the very unusual case of		no need to put psd=n in a DMARC record, except in the very
	a parent PSD publishing a DMARC record without the requisite		unusual case of a parent PSD publishing a DMARC record without
	psd=y tag.		the requisite psd=y tag.
			u: The default, indicating that the DMARC policy record is
			published for a domain that is not a PSD. Use the mechanism
			described in Section 4.8 for determining the Organizational
			Domain. There is no need to explicitly publish psd=u in a
			DMARC record.
	rua: Addresses to which aggregate feedback is to be sent (comma-		rua: Addresses to which aggregate feedback is to be sent (comma-
	separated plain-text list of DMARC URIs; OPTIONAL).		separated plain-text list of DMARC URIs; OPTIONAL).
	[DMARC-Aggregate-Reporting] discusses considerations that apply		[DMARC-Aggregate-Reporting] discusses considerations that apply
	when the domain name of a URI differs from that of the domain		when the domain name of a URI differs from that of the domain
	advertising the policy. See Section 9.5 for additional		advertising the policy. See Section 9.5 for additional
	considerations. Any valid URI can be specified. A Mail Receiver		considerations. Any valid URI can be specified. A Mail Receiver
	MUST implement support for a "mailto:" URI, i.e., the ability to		MUST implement support for a "mailto:" URI, i.e., the ability to
	send a DMARC report via electronic mail. If the tag is not		send a DMARC report via electronic mail. If the tag is not
	provided, Mail Receivers MUST NOT generate aggregate feedback		provided, Mail Receivers MUST NOT generate aggregate feedback
	skipping to change at page 28, line 5 ¶		skipping to change at page 28, line 14 ¶
	Because the aggregate reports are XML documents, it is recommended		Because the aggregate reports are XML documents, it is recommended
	that they be machine-parsed, so setting up a mailbox involves more		that they be machine-parsed, so setting up a mailbox involves more
	than just the physical creation of that mailbox. Many third-party		than just the physical creation of that mailbox. Many third-party
	services exist that will process DMARC aggregate reports, or the		services exist that will process DMARC aggregate reports, or the
	Domain Owner can create its own set of tools. No matter which method		Domain Owner can create its own set of tools. No matter which method
	is chosen, the ability to parse these reports and consume the data		is chosen, the ability to parse these reports and consume the data
	contained in them will go a long way to ensuring a successful		contained in them will go a long way to ensuring a successful
	deployment.		deployment.
	5.5.4. Publish a DMARC Policy for the Author Domain		5.5.4. Publish a DMARC Policy for the Author Domain and Organizational
			Domain
	Once SPF, DKIM, and the aggregate reports mailbox are all in place,		Once SPF, DKIM, and the aggregate reports mailbox are all in place,
	it's time to publish a DMARC record. For best results, Domain Owners		it's time to publish a DMARC record. For best results, Domain Owners
	SHOULD start with "p=none", with the rua tag containg a URI that		SHOULD start with "p=none", with the rua tag containg a URI that
	references the mailbox created in the previous step.		references the mailbox created in the previous step. If the
			Organizational Domain is different than the Author Domain, a record
			also needs to be published for the Organizational Domain.
	5.5.5. Collect and Analyze Reports		5.5.5. Collect and Analyze Reports
	The reason for starting at "p=none" is to ensure that nothing's been		The reason for starting at "p=none" is to ensure that nothing's been
	missed in the initial SPF and DKIM deployments. In all but the most		missed in the initial SPF and DKIM deployments. In all but the most
	trivial setups, it is possible for a Domain Owner to overlook a		trivial setups, it is possible for a Domain Owner to overlook a
	server here or be unaware of a third party sending agreeement there.		server here or be unaware of a third party sending agreeement there.
	Starting at "p=none", therefore, takes advantage of DMARC's aggregate		Starting at "p=none", therefore, takes advantage of DMARC's aggregate
	reporting function, with the Domain Owner using the reports to audit		reporting function, with the Domain Owner using the reports to audit
	its own mail streams' authentication configurations.		its own mail streams' authentication configurations.
End of changes. 26 change blocks.
	55 lines changed or deleted		68 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/