rfc9989v2.txt		rfc9989.txt
	skipping to change at line 551 ¶		skipping to change at line 551 ¶
	3.2.16. Public Suffix Operator (PSO)		3.2.16. Public Suffix Operator (PSO)
	A PSO is an organization that manages operations within a PSD,		A PSO is an organization that manages operations within a PSD,
	particularly the DNS records published for names at and under that		particularly the DNS records published for names at and under that
	domain name.		domain name.
	3.2.17. PSO-Controlled Domain Names		3.2.17. PSO-Controlled Domain Names
	PSO-Controlled Domain Names are names in the DNS that are managed by		PSO-Controlled Domain Names are names in the DNS that are managed by
	a PSO. PSO-Controlled Domain Names may have one label (e.g., ".com")		a PSO. PSO-Controlled Domain Names may have one label (e.g., ".com")
	or more (e.g., ".co.uk"), depending on the PSD's policy.		or more (e.g., ".co.uk"), depending on the PSO's policy.
	3.2.18. Report Consumer		3.2.18. Report Consumer
	A Report Consumer is an operator that receives reports from another		A Report Consumer is an operator that receives reports from another
	operator implementing the reporting mechanisms described in [RFC9990]		operator implementing the reporting mechanisms described in [RFC9990]
	and [RFC9991]. This term applies collectively to the system		and [RFC9991]. This term applies collectively to the system
	components that receive and process these reports and the		components that receive and process these reports and the
	organizations that operate those components.		organizations that operate those components.
	Report Consumers can receive reports concerning domains for which the		Report Consumers can receive reports concerning domains for which the
	skipping to change at line 2713 ¶		skipping to change at line 2713 ¶
	[RFC8601] Kucherawy, M., "Message Header Field for Indicating		[RFC8601] Kucherawy, M., "Message Header Field for Indicating
	Message Authentication Status", RFC 8601,		Message Authentication Status", RFC 8601,
	DOI 10.17487/RFC8601, May 2019,		DOI 10.17487/RFC8601, May 2019,
	<https://www.rfc-editor.org/info/rfc8601>.		<https://www.rfc-editor.org/info/rfc8601>.
	[RFC9990] Brotman, A., Ed., "Domain-Based Message Authentication,		[RFC9990] Brotman, A., Ed., "Domain-Based Message Authentication,
	Reporting, and Conformance (DMARC) Aggregate Reporting",		Reporting, and Conformance (DMARC) Aggregate Reporting",
	RFC 9990, DOI 10.17487/RFC9990, May 2026,		RFC 9990, DOI 10.17487/RFC9990, May 2026,
	<https://www.rfc-editor.org/info/rfc9990>.		<https://www.rfc-editor.org/info/rfc9990>.
	[RFC9991] Jones, S. M., Ed. and A. Vesely, Ed., "Domain-Based		[RFC9991] Jones, S., Ed. and A. Vesely, Ed., "Domain-Based Message
	Message Authentication, Reporting, and Conformance (DMARC)		Authentication, Reporting, and Conformance (DMARC) Failure
	Failure Reporting", RFC 9991, DOI 10.17487/RFC9991, May		Reporting", RFC 9991, DOI 10.17487/RFC9991, May 2026,
	2026, <https://www.rfc-editor.org/info/rfc9991>.		<https://www.rfc-editor.org/info/rfc9991>.
	12.2. Informative References		12.2. Informative References
	[M3AUTH] Messaging Malware Mobile Anti-Abuse Working Group		[M3AUTH] Messaging Malware Mobile Anti-Abuse Working Group
	(M3AAWG), "M3AAWG Email Authentication Recommended Best		(M3AAWG), "M3AAWG Email Authentication Recommended Best
	Practices",		Practices",
	<https://www.m3aawg.org/sites/default/files/doc_files/		<https://www.m3aawg.org/sites/default/files/doc_files/
	m3aawg-email-authentication-recommended-best-practices-		m3aawg-email-authentication-recommended-best-practices-
	09-2020.pdf>.		09-2020.pdf>.
	skipping to change at line 3157 ¶		skipping to change at line 3157 ¶
	The Domain Owner from the previous example has used the aggregate		The Domain Owner from the previous example has used the aggregate
	reporting to discover some messaging systems that had not yet		reporting to discover some messaging systems that had not yet
	implemented DKIM correctly, but they are still seeing periodic		implemented DKIM correctly, but they are still seeing periodic
	authentication failures. To diagnose these intermittent problems,		authentication failures. To diagnose these intermittent problems,
	they wish to request per-message failure reports when authentication		they wish to request per-message failure reports when authentication
	failures occur.		failures occur.
	Not all Mail Receivers will honor such a request, but the Domain		Not all Mail Receivers will honor such a request, but the Domain
	Owner feels that any reports it does receive will be helpful enough		Owner feels that any reports it does receive will be helpful enough
	to justify publishing this record. The default per-message failure		to justify publishing this record. The default per-message failure
	report format [RFC6591] meets the Domain Owner's needs in this		report format [RFC9991] meets the Domain Owner's needs in this
	scenario.		scenario.
	The Domain Owner accomplishes this by adding the following to its		The Domain Owner accomplishes this by adding the following to its
	DMARC Policy Record from Appendix B.2.1:		DMARC Policy Record from Appendix B.2.1:
	* Per-message failure reports are sent via email to the address		* Per-message failure reports are sent via email to the address
	"auth-reports@example.com" ("ruf=mailto:auth-reports@example.com")		"auth-reports@example.com" ("ruf=mailto:auth-reports@example.com")
	To publish such a record, the DNS administrator for the Domain Owner		To publish such a record, the DNS administrator for the Domain Owner
	might create an entry like the following in the appropriate zone file		might create an entry like the following in the appropriate zone file
End of changes. 3 change blocks.
	6 lines changed or deleted		6 lines changed or added
This html diff was produced by rfcdiff 1.48.