Diff: rfc9991.original.xml

	rfc9991.original.xml	rfc9991.xml

	<?xml version="1.0" encoding="utf-8"?>	<?xml version="1.0" encoding="UTF-8"?>
	<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Process
	or - mmark.miek.nl" -->
	<rfc version="3" ipr="trust200902" docName="draft-ietf-dmarc-failure-reporting-2
	5" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.or
	g/2001/XInclude" updates="6591" obsoletes="7489" indexInclude="true" consensus="
	true">


	<front>	<!DOCTYPE rfc [
	<title abbrev="DMARC Failure Reporting">Domain-based Message Authentication, Rep	<!ENTITY nbsp " ">
	orting, and Conformance (DMARC) Failure Reporting</title><seriesInfo value="draf	<!ENTITY zwsp "">
	t-ietf-dmarc-failure-reporting-25" stream="IETF" status="standard" name="Interne	<!ENTITY nbhy "‑">
	t-Draft"></seriesInfo>	<!ENTITY wj "⁠">
	<author initials="S." surname="Jones (ed)" fullname="Steven M Jones"><organizati	]>
	on>DMARC.org</organization><address><postal><street></street>
	</postal><email>smj@dmarc.org</email>	<rfc version="3" ipr="trust200902" docName="draft-ietf-dmarc-failure-reporting-2
	</address></author><author initials="A." surname="Vesely (ed)" fullname="Alessan	5" number="9991" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="ht
	dro Vesely"><organization>Tana</organization><address><postal><street></street>	tp://www.w3.org/2001/XInclude" updates="6591" obsoletes="7489" tocInclude="true"
	</postal><email>vesely@tana.it</email>	consensus="true" symRefs="true" sortRefs="true">
	</address></author><date/>
	<area>Application</area>	<front>
	<workgroup>DMARC</workgroup>	<title abbrev="DMARC Failure Reporting">Domain-Based Message Authentication,
		Reporting, and Conformance (DMARC) Failure Reporting</title>
		<seriesInfo name="RFC" value="9991"/>
		<author initials="S." surname="Jones" fullname="Steven M. Jones" role="edito
		r">
		<organization>DMARC.org</organization>
		<address>
		<email>smj@dmarc.org</email>
		</address>
		</author>
		<author initials="A." surname="Vesely" fullname="Alessandro Vesely" role="ed
		itor">
		<organization>Tana</organization>
		<address>
		<email>vesely@tana.it</email>
		</address>
		</author>
		<date month="May" year="2026"/>
		<area>ART</area>
		<workgroup>dmarc</workgroup>

		<!-- [rfced] Please insert any keywords (beyond those that appear in
		the title) for use on https://www.rfc-editor.org/search. -->

		<keyword>example</keyword>

	<abstract>	<abstract>
	<t>Domain-based Message Authentication, Reporting, and Conformance	<t>Domain-based Message Authentication, Reporting, and Conformance
	(DMARC) is a mechanism by which a Domain Owner can request	(DMARC) is a mechanism by which a Domain Owner can request
	feedback about email messages using their domain in the From: address	feedback about email messages using their domain in the From: address

	field. This document describes "failure reports", or "failed mes	field. This document describes "failure reports", or "failed message
	sage	reports", which provide details about individual messages that failed
	reports", which provide details about individual messages that failed
	to authenticate according to the DMARC mechanism.</t>	to authenticate according to the DMARC mechanism.</t>
	<t>This document updates RFC 6591 and obsoletes RFC 7489.</t>	<t>This document updates RFC 6591 and obsoletes RFC 7489.</t>
	</abstract>	</abstract>

	</front>	</front>

	<middle>	<middle>

	<section anchor="introduction"><name>Introduction</name>	<section anchor="introduction"><name>Introduction</name>

	<t>RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING:
	The source for this draft is maintained in GitHub at:
	<eref target="https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reportin
	g">https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting</eref></t
	>
	<t>Domain-based Message Authentication, Reporting, and Conformance (DMARC)	<t>Domain-based Message Authentication, Reporting, and Conformance (DMARC)

	<xref target="I-D.ietf-dmarc-dmarcbis"></xref> is a mechanism by which a mail-or iginating	<xref target="RFC9989"/> is a 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 can be used by a	message validation, disposition, and reporting that can be used by a
	mail-receiving organization to improve mail handling. This document	mail-receiving organization to improve mail handling. This document
	focuses on one type of reporting that can be requested under DMARC.</t>	focuses on one type of reporting that can be requested under DMARC.</t>
	<t>Failure reports provide detailed information about the failure of a	<t>Failure reports provide detailed information about the failure of a

	single message, or a group of similar messages failing for the same	single message or a group of similar messages failing for the same
	reason. Their purpose is twofold. On the one hand they are meant to	reason. Their purpose is twofold. On the one hand, they are meant to
	aid in cases where a Domain Owner wishes to determine the cause of	aid in cases where a Domain Owner wishes to determine the cause of
	failures that were part of aggregate reports (see	failures that were part of aggregate reports (see

	<xref target="I-D.ietf-dmarc-aggregate-reporting"></xref>). On the other hand, they can	<xref target="RFC9990"/>). On the other hand, they can
	allow the Domain Owner to quickly identify and address harmful	allow the Domain Owner to quickly identify and address harmful
	messages involving direct domain abuse. It is important to note that	messages involving direct domain abuse. It is important to note that
	these reports can contain the header fields or sometimes the entire	these reports can contain the header fields or sometimes the entire
	content of a failed message, which may contain personally identifiable	content of a failed message, which may contain personally identifiable
	information (PII). The potential disclosure of PII should be considered	information (PII). The potential disclosure of PII should be considered
	when deciding whether to request failure reports as a Domain Owner, or	when deciding whether to request failure reports as a Domain Owner, or
	what information to include or redact in failure reports when creating	what information to include or redact in failure reports when creating
	them as a Mail Receiver, or whether to create failure reports at all.	them as a Mail Receiver, or whether to create failure reports at all.

	Refer to <xref target="privacy-considerations"></xref> for more discussion on pr ivacy considerations.</t>	Refer to <xref target="privacy-considerations"/> for more discussion on privacy considerations.</t>

	<section anchor="terminology"><name>Terminology</name>	<section anchor="terminology"><name>Terminology</name>
	<t>There are a number of terms defined in	<t>There are a number of terms defined in

	<xref target="I-D.ietf-dmarc-dmarcbis" sectionFormat="of" relative="#" section=" 3.2"></xref>	<xref target="RFC9989" sectionFormat="of" section="3.2"/>
	that are used within this document. Understanding those	that are used within this document. Understanding those
	definitions will aid in reading this document.</t>	definitions will aid in reading this document.</t>

	<t>The format of DMARC failure reports is derived from Authentication	<t>The format of DMARC failure reports is derived from "Authentication
	Failure Reporting Using the Abuse Reporting Format (<xref target="RFC6591"></xre	Failure Reporting Using the Abuse Reporting Format" <xref target="RFC6591"/>, an
	f>) and	d
	the terms defined there are used here.</t>	the terms defined there are used here.</t>

	<t>The key words "MUST", "MUST NOT", "REQUIRED", &	<t>
	quot;SHALL", "SHALL	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",	IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	"NOT RECOMMENDED",	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	"MAY", and "OPTIONAL" in this document are to be interpreted	RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	as	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	described in BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref	be interpreted as
	> when, and only when, they	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
	appear in all capitals, as shown here.</t>	when, and only when, they appear in all capitals, as shown here.
		</t>

	</section>	</section>

	<section anchor="document-status"><name>Document Status</name>	<section anchor="document-status"><name>Document Status</name>

	<t>This document, in part, along with DMARCbis <xref target="I-D.ietf-dmarc-dmar	<t>This document, in part, along with <xref target="RFC9989"/> and <xref target=
	cbis"></xref>	"RFC9990"/>,
	DMARCbis Aggregate Reporting <xref target="I-D.ietf-dmarc-aggregate-reporting"><	obsoletes and replaces <xref target="RFC7489"/>.</t>
	/xref>,
	obsoletes and replaces <xref target="RFC7489"></xref>.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="failure-reports"><name>DMARC Failure Reports</name>	<section anchor="failure-reports"><name>DMARC Failure Reports</name>
	<t>Besides the header fields or the entire contents of a failed message, failure	<t>Besides the header fields or the entire contents of a failed message, failure
	reports supply details about transmission and DMARC authentication,	reports supply details about transmission and DMARC authentication,
	which may aid a Domain Owner in determining the cause of an authentication failu re.</t>	which may aid a Domain Owner in determining the cause of an authentication failu re.</t>
	<t>Failure reports are normally generated and sent almost immediately	<t>Failure reports are normally generated and sent almost immediately
	after the Mail Receiver detects a DMARC failure. Rather than waiting	after the Mail Receiver detects a DMARC failure. Rather than waiting
	for an aggregate report, these reports are useful for quickly notifying	for an aggregate report, these reports are useful for quickly notifying
	the Domain Owners when there is an authentication failure. Failure	the Domain Owners when there is an authentication failure. Failure
	reports also provide more information about the failed message than is	reports also provide more information about the failed message than is
	available in an aggregate report. This allows the failure report	available in an aggregate report. This allows the failure report
	consumer to better determine whether the failure is of a message that	consumer to better determine whether the failure is of a message that

	the domain owner intended to authenticate or one for which use of its	the Domain Owner intended to authenticate or one for which use of its
	domain was not authorized.</t>	domain was not authorized.</t>
	<t>These reports should include as much of the message header fields and body as	<t>These reports should include as much of the message header fields and body as
	possible, consistent with the reporting party's privacy policies, to	possible, consistent with the reporting party's privacy policies, to
	enable the Domain Owner to diagnose the authentication failure.</t>	enable the Domain Owner to diagnose the authentication failure.</t>
	<t>When a Domain Owner requests failure reports for the purpose of	<t>When a Domain Owner requests failure reports for the purpose of
	forensic analysis, and the Mail Receiver is willing to provide such	forensic analysis, and the Mail Receiver is willing to provide such
	reports, the Mail Receiver generates and sends a message using the	reports, the Mail Receiver generates and sends a message using the

	format described in <xref target="RFC6591"></xref>; this document updates that r	format described in <xref target="RFC6591"/>; this document updates that reporti
	eporting	ng
	format, as described in <xref target="reporting-format-update"></xref>.</t>	format, as described in <xref target="reporting-format-update"/>.</t>
	<t>The destination(s) to which failure reports are sent, and options for when	<t>The destination(s) to which failure reports are sent, and options for when

	they will be sent, are defined by the "ruf" and "fo" tags as	they will be sent, are defined by the "ruf" and "fo" tags as provided
	provided	in <xref target="RFC9989" sectionFormat="of" section="4.7"/>.</t>
	in <xref target="I-D.ietf-dmarc-dmarcbis" sectionFormat="of" relative="#" sectio
	n="4.7"></xref>.</t>
	<t>When multiple URIs are provided to receive failure reports, the	<t>When multiple URIs are provided to receive failure reports, the
	report generator <bcp14>MUST</bcp14> make an attempt to deliver to each of them.	report generator <bcp14>MUST</bcp14> make an attempt to deliver to each of them.

	External destinations <bcp14>MUST</bcp14> be verified, see <xref target="verifyi	External destinations <bcp14>MUST</bcp14> be verified (see <xref target="verifyi
	ng-external-destinations"></xref>.	ng-external-destinations"/>).
	Report generators <bcp14>MUST NOT</bcp14> consider "ruf" tags in DMARC	Report generators <bcp14>MUST NOT</bcp14> consider "ruf" tags in DMARC Policy Re
	Policy Records having a "psd=y"	cords that have a "psd=y"
	tag, unless there are specific agreements between the interested parties.</t>	tag, unless there are specific agreements between the interested parties.</t>
	<t>Report generators <bcp14>MUST</bcp14> implement a rate-limit on outgoing repo rts	<t>Report generators <bcp14>MUST</bcp14> implement a rate-limit on outgoing repo rts

	so as not to flood report consumers with excessive reports, which would	so as not to flood Report Consumers with excessive reports, which would
	allow denial-of-service; see <xref target="dos-attacks"></xref>.</t>	allow denial of service (see <xref target="dos-attacks"/>).</t>
	</section>	</section>


		<!--[rfced] To improve the readability of this sentence, may we update
		the punctuation as follows?

		Original:
		A Mail Receiver generating DMARC failure reports MAY issue failure reports
		specific to the failed authentication mechanism instead of, or in
		addition to, DMARC failure reports, based on its own policy, the
		failure in question, and the content of the "fo" tag in the retrieved
		DMARC Policy Record.

		Perhaps:
		A Mail Receiver generating DMARC failure reports MAY issue failure reports
		specific to the failed authentication mechanism instead of (or in
		addition to) DMARC failure reports that are based on the Receiver's own polic
		y, the
		failure in question, and the content of the "fo" tag in the retrieved
		DMARC Policy Record.
		-->

	<section anchor="other-reports"><name>Other Failure Reports</name>	<section anchor="other-reports"><name>Other Failure Reports</name>

	<t>This document describes only DMARC failure reports. DKIM failure	<t>This document only describes DMARC failure reports. DomainKeys Identified Mai
	reports and SPF failure reports are described in <xref target="RFC6591"></xref>.	l (DKIM) failure
	A Mail	reports and Sender Policy Framework (SPF) failure reports are described in <xref
		target="RFC6591"/>. A Mail
	Receiver generating DMARC failure reports <bcp14>MAY</bcp14> issue failure repor ts	Receiver generating DMARC failure reports <bcp14>MAY</bcp14> issue failure repor ts
	specific to the failed authentication mechanism instead of, or in	specific to the failed authentication mechanism instead of, or in
	addition to, DMARC failure reports, based on its own policy, the	addition to, DMARC failure reports, based on its own policy, the

	failure in question, and the content of the "fo" tag in the retrieved	failure in question, and the content of the "fo" tag in the retrieved
	DMARC Policy Record.</t>	DMARC Policy Record.</t>
	<t>Note that DKIM failure reports and SPF failure reports can also be	<t>Note that DKIM failure reports and SPF failure reports can also be

	requested using the methods described in <xref target="RFC6651"></xref> and <xre	requested using the methods described in <xref target="RFC6651"/> and <xref targ
	f target="RFC6652"></xref>,	et="RFC6652"/>,
	respectively. Report Generators are free to follow any of the	respectively. Report generators are free to follow any of the
	specifications.</t>	specifications.</t>
	</section>	</section>

	<section anchor="reporting-format-update"><name>Reporting Format Update</name>	<section anchor="reporting-format-update"><name>Reporting Format Update</name>
	<t>Operators implementing this specification also implement an augmented	<t>Operators implementing this specification also implement an augmented

	version of <xref target="RFC6591"></xref> as follows:</t>	version of failure reporting described in <xref target="RFC6591"/> as follows:</ t>


	<ol>	<ol spacing="normal" type="1">
	<li><t>A DMARC failure report includes the following ARF header fields,	<li><t>A DMARC failure report includes the following Abuse Reporting Format (ARF
		) header fields,
	with the indicated normative requirement levels:</t>	with the indicated normative requirement levels:</t>

	<ul>	<ul>
	<li><t>Identity-Alignment (<bcp14>REQUIRED</bcp14>; defined below)</t>	<li><t>Identity-Alignment (<bcp14>REQUIRED</bcp14>; defined below)</t>
	</li>	</li>
	<li><t>Delivery-Result (<bcp14>OPTIONAL</bcp14>)</t>	<li><t>Delivery-Result (<bcp14>OPTIONAL</bcp14>)</t>
	</li>	</li>
	<li><t>DKIM-Domain, DKIM-Identity, DKIM-Selector (<bcp14>REQUIRED</bcp14> for DK IM failures of an aligned identifier)</t>	<li><t>DKIM-Domain, DKIM-Identity, DKIM-Selector (<bcp14>REQUIRED</bcp14> for DK IM failures of an aligned identifier)</t>
	</li>	</li>
	<li><t>DKIM-Canonicalized-Header, DKIM-Canonicalized-Body (<bcp14>OPTIONAL</bcp1 4> if reporting a DKIM failure)</t>	<li><t>DKIM-Canonicalized-Header, DKIM-Canonicalized-Body (<bcp14>OPTIONAL</bcp1 4> if reporting a DKIM failure)</t>
	</li>	</li>
	<li><t>SPF-DNS (<bcp14>REQUIRED</bcp14> for SPF failure of an aligned identifier )</t>	<li><t>SPF-DNS (<bcp14>REQUIRED</bcp14> for SPF failure of an aligned identifier )</t>
	</li>	</li>
	</ul></li>	</ul></li>

	<li><t>The "Identity-Alignment" field is defined to contain a	<li><t>The Identity-Alignment field is defined to contain a comma-
	comma-separated list of authentication mechanism names that failed to	separated list of authentication mechanism names that failed to authenticate an
	authenticate an aligned identity, or the keyword "none" if all of the	aligned identity or the keyword "none" if all of the attempted methods were succ
	attempted methods were successful at authenticating an aligned	essful at authenticating an aligned identity. Here is the ABNF <xref target="RF
	identity. ABNF (<xref target="RFC5234"></xref>, importing CFWS from <xref targe	C5234"/> (importing comments and/or folding white space (CFWS) from <xref target
	t="RFC5322"></xref>):</t>	="RFC5322"/>):</t>
	</li>
	</ol>


	<sourcecode type="ABNF">id-align = "Identity-Alignment:" [CFWS]	<!--[rfced] This line within the ABNF in Section 4 exceeds the 72-character
	( "none" /	limit by 3 characters. Please let us know how it can be modified.
	dmarc-method *( [CFWS] "," [CFWS] dmarc-method ) )
		Original:
		dmarc-method *( [CFWS] "," [CFWS] dmarc-method ) )
		-->

		<sourcecode type="abnf"><![CDATA[
		id-align = "Identity-Alignment:" [CFWS]
		( "none" /
		dmarc-method *( [CFWS] "," [CFWS] dmarc-method ) )
	[CFWS]	[CFWS]


	dmarc-method = ( "dkim" / "spf" )	dmarc-method = ( "dkim" / "spf" )
	; each may appear at most once in an id-align	; each may appear at most once in an id-align]]></sourcecode></
	</sourcecode>	li>


	<ol spacing="compact" start="3">	<li>Authentication Failure Type "dmarc" is defined for the Auth-Failure
	<li>Authentication Failure Type "dmarc" is defined for the Auth-Failur
	e
	field, which is to be used when a failure report is generated because	field, which is to be used when a failure report is generated because
	some or all of the authentication mechanisms failed to produce aligned	some or all of the authentication mechanisms failed to produce aligned
	identifiers. Note that a failure report generator <bcp14>MAY</bcp14> also	identifiers. Note that a failure report generator <bcp14>MAY</bcp14> also
	independently produce an ARF message for any or all of the underlying	independently produce an ARF message for any or all of the underlying
	authentication methods.</li>	authentication methods.</li>
	</ol>	</ol>
	</section>	</section>

	<section anchor="verifying-external-destinations"><name>Verifying External Desti nations</name>	<section anchor="verifying-external-destinations"><name>Verifying External Desti nations</name>
	<t>It is possible to specify destinations for failure reports that are	<t>It is possible to specify destinations for failure reports that are
	outside of the Organizational Domain of the DMARC Policy Record that	outside of the Organizational Domain of the DMARC Policy Record that
	was requesting the reports. These destinations are	was requesting the reports. These destinations are

	commonly referred to as "external destinations" and may represent a	commonly referred to as "external destinations" and may represent a
	different domain controlled by the same organization, a contracted	different domain controlled by the same organization, a contracted
	report processing service, or some other arrangement.</t>	report processing service, or some other arrangement.</t>
	<t>In case of external destinations, a Mail Receiver who	<t>In case of external destinations, a Mail Receiver who
	generates failure reports <bcp14>MUST</bcp14> use the Verifying External Destina tions	generates failure reports <bcp14>MUST</bcp14> use the Verifying External Destina tions

	procedure described in <xref target="I-D.ietf-dmarc-aggregate-reporting" section	procedure described in <xref target="RFC9990" sectionFormat="of" section="4"/>,
	Format="of" relative="#" section="4"></xref>,	substituting the "ruf" tag where the "rua" tag appears in that procedure.</t>
	substituting the "ruf" tag where the "rua" tag appears in th
	at procedure.</t>
	<t>This prevents a bad actor from publishing a DMARC Policy Record	<t>This prevents a bad actor from publishing a DMARC Policy Record

	requesting failure reports to an external destination, and	requesting failure reports to an external destination and
	then deliberately sending messages that will generate failure reports	then deliberately sending messages that will generate failure reports
	as a form of abuse. It also prevents a Domain Owner from unilaterally	as a form of abuse. It also prevents a Domain Owner from unilaterally
	publishing a DMARC Policy Record with an external destination for	publishing a DMARC Policy Record with an external destination for
	failure reports, forcing the external destination to deal with unwanted	failure reports, forcing the external destination to deal with unwanted
	messages and potential privacy issues.</t>	messages and potential privacy issues.</t>

	<section anchor="transport"><name>Transport</name>	<section anchor="transport"><name>Transport</name>
	<t>Email streams carrying DMARC failure reports <bcp14>SHOULD</bcp14> be DMARC-a ligned.</t>	<t>Email streams carrying DMARC failure reports <bcp14>SHOULD</bcp14> be DMARC-a ligned.</t>
	<t>We recommend that reporters set a reasonable rate-limit for the number	<t>We recommend that reporters set a reasonable rate-limit for the number
	of failure reports sent	of failure reports sent
	to any recipient to avoid overloading recipient systems.	to any recipient to avoid overloading recipient systems.
	Unaligned reports may in turn produce subsequent failure reports that could	Unaligned reports may in turn produce subsequent failure reports that could
	cause mail loops.</t>	cause mail loops.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="iana-considerations"><name>IANA Considerations</name>	<section anchor="iana-considerations"><name>IANA Considerations</name>

	<section anchor="feedback-report-header-fields-registry-update"><name>Feedback R eport Header Fields Registry Update</name>	<section anchor="feedback-report-header-fields-registry-update"><name>Feedback R eport Header Fields Registry Update</name>

	<t>IANA is requested to change the "Identity-Alignment" entry in the	<t>IANA has updated the reference and description for the "Identity-Alignment" e
	"Feedback Report Header Fields" registry, which is part of the	ntry in the
	"Messaging Abuse Reporting Format (MARF) Parameters" registry group, a	"Feedback Report Header Fields" registry within the
	s	"Messaging Abuse Reporting Format (MARF) Parameters" registry group, as follows:
	follows:</t>	</t>

		<dl spacing="compact">
		<dt>Field Name:</dt><dd>Identity-Alignment</dd>
		<dt>Description:</dt><dd>a list of authentication mechanism names that failed
		to authenticate an aligned identity, or "none" if all were successful</dd>
		<dt>Multiple Appearances:</dt><dd>No</dd>
		<dt>Related "Feedback-Type":</dt><dd>auth-failure</dd>
		<dt>Reference:</dt><dd>RFC 9991</dd>
		<dt>Status:</dt><dd>current</dd>
		</dl>


	<ul>
	<li><t>"Reference" should change to this document</t>
	</li>
	<li><t>"Description" should change to "a list of authentication m
	echanism
	names that failed to authenticate an aligned identity, or 'none' if all
	were successful".</t>
	</li>
	</ul>
	</section>	</section>
	</section>	</section>

	<section anchor="privacy-considerations"><name>Privacy Considerations</name>	<section anchor="privacy-considerations"><name>Privacy Considerations</name>
	<t>The generation and transmission of DMARC failure reports raise	<t>The generation and transmission of DMARC failure reports raise
	significant privacy concerns that must be carefully considered before	significant privacy concerns that must be carefully considered before
	deployment.</t>	deployment.</t>
	<t>Given these factors, many large-scale providers limit or entirely	<t>Given these factors, many large-scale providers limit or entirely
	disable the generation of failure reports, preferring to rely on	disable the generation of failure reports, preferring to rely on
	aggregate reports, which provide statistical visibility without	aggregate reports, which provide statistical visibility without
	exposing sensitive content. Operators that choose to enable failure	exposing sensitive content. Operators that choose to enable failure
	reporting are strongly encouraged to:</t>	reporting are strongly encouraged to:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li>Limit the scope and duration of use to targeted diagnostic activities.</li>	<li>Limit the scope and duration of use to targeted diagnostic activities;</li>
	<li>Ensure that reporting URIs are carefully controlled and validated.</li>	<li>Ensure that reporting URIs are carefully controlled and validated;</li>
	<li>Apply minimization techniques, such as redaction of message bodies	<li>Apply minimization techniques, such as redaction of message bodies

	and header fields, to reduce sensitive data exposure.</li>	and header fields, to reduce sensitive data exposure; </li>
	<li>Always transmit reports over secure channels.</li>	<li>Always transmit reports over secure channels.</li>
	</ul>	</ul>
	<t>In summary, while DMARC failure reports can offer diagnostic value, the	<t>In summary, while DMARC failure reports can offer diagnostic value, the
	associated privacy concerns have led many operators to restrict their	associated privacy concerns have led many operators to restrict their
	use. Aggregate reports remain the recommended mechanism for gaining	use. Aggregate reports remain the recommended mechanism for gaining
	visibility into authentication results while preserving the	visibility into authentication results while preserving the
	confidentiality of end-user communications.</t>	confidentiality of end-user communications.</t>
	<t>Particular privacy-specific issues are explored below.</t>	<t>Particular privacy-specific issues are explored below.</t>

	<section anchor="data-exposure-considerations"><name>Data Exposure Consideration s</name>	<section anchor="data-exposure-considerations"><name>Data Exposure Consideration s</name>
	<t>Failure reports may include PII and non-public information (NPI) from	<t>Failure reports may include PII and non-public information (NPI) from
	messages that fail to authenticate, since these reports may contain	messages that fail to authenticate, since these reports may contain
	message content as well as trace header fields. These reports may	message content as well as trace header fields. These reports may
	expose sender and recipient identifiers (e.g., RFC5322.From addresses),	expose sender and recipient identifiers (e.g., RFC5322.From addresses),

	and although the <xref target="RFC5965"></xref> format used for failed-message r	and although the <xref target="RFC5965"/> format used for failed-message reporti
	eporting	ng
	supports redaction (<xref target="RFC6590"></xref>), failed-message reporting is	supports redaction <xref target="RFC6590"/>, failed-message reporting is capable
	capable of	of
	exposing the entire message to the Report Consumer. They may also	exposing the entire message to the Report Consumer. They may also
	expose PII, sensitive business data, or other confidential	expose PII, sensitive business data, or other confidential
	communications to unintended recipients. Such exposure can create	communications to unintended recipients. Such exposure can create
	regulatory, legal, and operational risks for both senders and	regulatory, legal, and operational risks for both senders and
	receivers. Examples include product launches, termination notices for	receivers. Examples include product launches, termination notices for
	employees, or calendar data. Even innocuous-seeming failures (such as	employees, or calendar data. Even innocuous-seeming failures (such as

	malformed or "broken" calendar invitations) can result in the leakage	malformed or "broken" calendar invitations) can result in the leakage
	of private communications.</t>	of private communications.</t>
	<t>Domain Owners requesting reports will receive information about mail	<t>Domain Owners requesting reports will receive information about mail
	using their domain, but which they did not actually cause to be sent.	using their domain, but which they did not actually cause to be sent.
	This might provide valuable insight into content used in abusive	This might provide valuable insight into content used in abusive
	messages, but it might also expose PII or NPI from legitimate messages	messages, but it might also expose PII or NPI from legitimate messages
	mistakenly or accidentally failing authentication.</t>	mistakenly or accidentally failing authentication.</t>
	<t>Information about the final destination of mail, where it might	<t>Information about the final destination of mail, where it might
	otherwise be obscured by intermediate systems, may be exposed through a	otherwise be obscured by intermediate systems, may be exposed through a
	failure report. A commonly cited example is exposure of members of	failure report. A commonly cited example is exposure of members of
	mailing lists when one list member sends messages to the list, and	mailing lists when one list member sends messages to the list, and
	failure reports are generated when that message is delivered to other	failure reports are generated when that message is delivered to other
	list members. Those failure reports would be sent to the Domain Owner	list members. Those failure reports would be sent to the Domain Owner

	of the list member posting the message, or their delegated Report	of the list member posting the message or their delegated Report
	Consumer(s).</t>	Consumer(s).</t>
	<t>Similarly, when message forwarding arrangements exist, Domain Owners	<t>Similarly, when message forwarding arrangements exist, Domain Owners
	requesting reports may receive information about mail forwarded to	requesting reports may receive information about mail forwarded to
	domains that were not originally part of their messages' recipient	domains that were not originally part of their messages' recipient
	list. This means that destinations previously unknown to the Domain	list. This means that destinations previously unknown to the Domain
	Owner may now become visible.</t>	Owner may now become visible.</t>
	</section>	</section>

	<section anchor="report-recipients"><name>Report Recipients</name>	<section anchor="report-recipients"><name>Report Recipients</name>
	<t>A DMARC Policy Record can specify that reports should be sent to a	<t>A DMARC Policy Record can specify that reports should be sent to a
	Report Consumer operating on behalf of the Domain Owner. This might be	Report Consumer operating on behalf of the Domain Owner. This might be
	done when the Domain Owner sends reports to an entity to monitor mail	done when the Domain Owner sends reports to an entity to monitor mail
	streams for deliverability, performance issues, or abuse. Receipt of	streams for deliverability, performance issues, or abuse. Receipt of
	such data by third parties may or may not be permitted by the Mail	such data by third parties may or may not be permitted by the Mail

	Receiver's privacy policy, terms of use, et cetera. Domain Owners and	Receiver's privacy policy, terms of use, etc. Domain Owners and
	Mail Receivers should both review and understand whether their own	Mail Receivers should both review and understand whether their own
	internal policies constrain the use and transmission of DMARC	internal policies constrain the use and transmission of DMARC
	reporting.</t>	reporting.</t>
	<t>Some potential exists for Report Consumers to perform traffic analysis,	<t>Some potential exists for Report Consumers to perform traffic analysis,
	making it possible to obtain metadata about the Mail Receiver's	making it possible to obtain metadata about the Mail Receiver's
	traffic. In addition to verifying compliance with policies, Mail	traffic. In addition to verifying compliance with policies, Mail
	Receivers need to consider that before sending reports to a third	Receivers need to consider that before sending reports to a third
	party. On the other hand, a Domain Owner may publish a destination	party. On the other hand, a Domain Owner may publish a destination
	address that appears to be an Internal Report Consumer but is actually	address that appears to be an Internal Report Consumer but is actually
	a forwarding address; in this case, the final destination of a report	a forwarding address; in this case, the final destination of a report
	is not guaranteed.</t>	is not guaranteed.</t>
	</section>	</section>

	<section anchor="additional-damage"><name>Additional Damage</name>	<section anchor="additional-damage"><name>Additional Damage</name>
	<t>The risks associated with failure reports are compounded by volume and	<t>The risks associated with failure reports are compounded by volume and
	content distribution concerns. Partially or unredacted reports may	content distribution concerns. Partially or unredacted reports may
	propagate large amounts of spam, phishing, or malware content, all of	propagate large amounts of spam, phishing, or malware content, all of
	which may require special handling by Report Consumers or other	which may require special handling by Report Consumers or other
	recipients to avoid incidents. This underscores the need to avoid	recipients to avoid incidents. This underscores the need to avoid

	misconfiguration of the destinations in the "ruf" reporting URIs, and	misconfiguration of the destinations in the "ruf" reporting URIs and
	the suggestions for redaction in this document, for example using the	the suggestions for redaction in this document, for example, using the
	method described in <xref target="RFC6590"></xref>. All of these concerns are	method described in <xref target="RFC6590"/>. All of these concerns are
	heightened for high-volume domains. To mitigate such concerns, the	heightened for high-volume domains. To mitigate such concerns, the
	following steps should be considered:</t>	following steps should be considered:</t>
	<t>By report generators:</t>	<t>By report generators:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li>Help prevent accidental access to potentially-malicious URIs by substituting	<li>Help prevent accidental access to potentially malicious URIs by substituting
	hxxp for http;</li>	hxxp for http;</li>
	<li>remove attachments which could embed malicious payload.</li>	<li>Remove attachments that could embed malicious payload.</li>
	</ul>	</ul>
	<t>By report consumers:</t>	<t>By report consumers:</t>


	<ul spacing="compact">	<ul spacing="normal">
	<li>isolate report streams from other mail streams;</li>	<li>Isolate report streams from other mail streams;</li>
	<li>use sandboxes in evaluating failure reports;</li>	<li>Use sandboxes in evaluating failure reports;</li>
	<li>use network segmentation;</li>	<li>Use network segmentation;</li>
	<li>limit access to failure reports to authorized individuals with	<li>Limit access to failure reports to authorized individuals with
	appropriate security training.</li>	appropriate security training.</li>
	</ul>	</ul>
	</section>	</section>
	</section>	</section>

	<section anchor="security-considerations"><name>Security Considerations</name>	<section anchor="security-considerations"><name>Security Considerations</name>

	<t>While reviewing this document and its Security Considerations, the	<t>While reviewing this document and its security considerations, the
	reader should also review the Privacy Considerations above, as well as	reader should also review the privacy considerations above, as well as
	the Privacy Considerations and Security Considerations in sections	the privacy considerations and security considerations in Sections
	<xref target="I-D.ietf-dmarc-dmarcbis" sectionFormat="bare" relative="#" section	<xref target="RFC9989" sectionFormat="bare" section="10"/> and <xref target="RFC
	="10"></xref> and <xref target="I-D.ietf-dmarc-dmarcbis" sectionFormat="bare" re	9989" sectionFormat="bare" section="11"/> of
	lative="#" section="11"></xref> of	<xref target="RFC9989"/> and in Sections
	<xref target="I-D.ietf-dmarc-dmarcbis"></xref>; and in sections	<xref target="RFC9990" sectionFormat="bare" section="7"/> and
	<xref target="I-D.ietf-dmarc-aggregate-reporting" sectionFormat="bare" relative=	<xref target="RFC9990" sectionFormat="bare" section="8"/> of
	"#" section="7"></xref> and	<xref target="RFC9990"/>.</t>
	<xref target="I-D.ietf-dmarc-aggregate-reporting" sectionFormat="bare" relative=
	"#" section="8"></xref> of
	<xref target="I-D.ietf-dmarc-aggregate-reporting"></xref>.</t>

	<section anchor="dos-attacks"><name>Denial of Service</name>	<section anchor="dos-attacks"><name>Denial of Service</name>
	<t>Failure reports represent a possible denial-of-service attack that could be	<t>Failure reports represent a possible denial-of-service attack that could be
	perpetrated by an attacker who sends numerous messages purporting to	perpetrated by an attacker who sends numerous messages purporting to
	be from the intended victim Domain Owner but which fail both SPF and	be from the intended victim Domain Owner but which fail both SPF and
	DKIM; this would cause participating Mail Receivers to send failure	DKIM; this would cause participating Mail Receivers to send failure
	reports to the Domain Owner or its delegate(s), potentially in large	reports to the Domain Owner or its delegate(s), potentially in large
	numbers.	numbers.
	Accordingly, participating Mail Receivers are encouraged to	Accordingly, participating Mail Receivers are encouraged to
	aggregate these reports as much as is practical, using the Incidents	aggregate these reports as much as is practical, using the Incidents

	field of the Abuse Reporting Format <xref target="RFC5965"></xref>.	field of the ARF <xref target="RFC5965"/>.
	Indeed, the aim is not to count each and every failure, but rather to	Indeed, the aim is not to count each and every failure but rather to
	report different failure conditions.	report different failure conditions.
	Various pruning techniques are possible, including the following:</t>	Various pruning techniques are possible, including the following:</t>

	<ul>	<ul>

	<li><t>store reports for a period of time before sending them, allowing	<li><t>Store reports for a period of time before sending them, allowing
	detection, collection, and consolidation of like incidents;</t>	detection, collection, and consolidation of like incidents;</t>
	</li>	</li>

	<li><t>apply rate limiting, such as a maximum number of reports per	<li><t>Apply rate-limiting, such as a maximum number of reports per
	minute that will be generated (and the remainder discarded.)</t>	minute that will be generated (and the remainder discarded).</t>
	</li>	</li>
	</ul>	</ul>
	</section>	</section>
	</section>	</section>

	</middle>	</middle>

	<back>	<back>

		<references><name>References</name>
	<references><name>Normative References</name>	<references><name>Normative References</name>

	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.i
	etf-dmarc-aggregate-reporting.xml"/>	<!-- [RFCYYY1]
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml-ids/reference.I-D.i	draft-ietf-dmarc-aggregate-reporting-32
	etf-dmarc-dmarcbis.xml"/>	companion doc RFC 9990
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.	in AUTH48 as of 5/13/26
	xml"/>	-->
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.
	xml"/>	<reference anchor="RFC9990" target="https://www.rfc-editor.org/info/rfc9990">
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5322.	<front>
	xml"/>	<title>Domain-Based Message Authentication, Reporting, and Conformance (DMAR
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5965.	C) Aggregate Reporting</title>
	xml"/>	<author initials="A." surname="Brotman" fullname="Alex Brotman" role="editor
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6590.	">
	xml"/>	<organization>Comcast, Inc.</organization>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6591.	</author>
	xml"/>	<date month='May' year='2026'/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6692.	</front>
	xml"/>	<seriesInfo name="RFC" value="9990"/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.	<seriesInfo name="DOI" value="10.17487/RFC9990"/>
	xml"/>	</reference>

		<!-- [RFCYYY2]
		draft-ietf-dmarc-dmarcbis-41
		companion doc RFC 9989
		in AUTH48 as of 5/13/26
		-->
		<reference anchor="RFC9989" target="https://www.rfc-editor.org/info/rfc9989">
		<front>
		<title>Domain-Based Message Authentication, Reporting, and Conformance (DMAR
		C)</title>
		<author initials="T." surname="Herr" fullname="Todd Herr" role="editor">
		<organization>Valimail</organization>
		</author>
		<author initials="J. R." surname="Levine" fullname="John R. Levine" role="
		editor">
		<organization>Standcore LLC</organization>
		</author>
		<date month='May' year='2026'/>
		</front>
		<seriesInfo name="RFC" value="9989"/>
		<seriesInfo name="DOI" value="10.17487/RFC9989"/>
		</reference>

		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
		/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"
		/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml"
		/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5965.xml"
		/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6590.xml"
		/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6591.xml"
		/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6692.xml"
		/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
		/>
	</references>	</references>
	<references><name>Informative References</name>	<references><name>Informative References</name>

	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6651.	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6651.xml"
	xml"/>	/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6652.	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6652.xml"
	xml"/>	/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7489.	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7489.xml"
	xml"/>	/>
		</references>
	</references>	</references>

	<section anchor="report-format-example"><name>Example Failure Report</name>	<section anchor="report-format-example"><name>Example Failure Report</name>
	<t>This is the full content of a sample failure message, including the message h eader.</t>	<t>This is the full content of a sample failure message, including the message h eader.</t>


	<sourcecode type="RFC5322">Received: from gen.example (gen.example [192.0.2.1])	<sourcecode type="message/rfc822"><![CDATA[
		Received: from gen.example (gen.example [192.0.2.1])
	(TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384)	(TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384)
	by mail.consumer.example with ESMTPS	by mail.consumer.example with ESMTPS
	id 00000000005DC0DD.0000442E; Tue, 19 Jul 2022 07:57:50 +0200	id 00000000005DC0DD.0000442E; Tue, 19 Jul 2022 07:57:50 +0200
	DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;	DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
	d=gen.example; s=mail; t=1658210268;	d=gen.example; s=mail; t=1658210268;
	bh=rCrh1aFDE8d/Fltt8wbcu48bLOu4OM23QXqphUZPAIM=;	bh=rCrh1aFDE8d/Fltt8wbcu48bLOu4OM23QXqphUZPAIM=;
	h=From:To:Date:Subject:From;	h=From:To:Date:Subject:From;
	b=IND9JkuwF9/5841kzxMbPeej0VYimVzNKozR2R89M8eYO2zOlCBblx507Gz0YK7mE	b=IND9JkuwF9/5841kzxMbPeej0VYimVzNKozR2R89M8eYO2zOlCBblx507Gz0YK7mE
	/h6pslWm0ODBVFzLlwY9CXv4Vu62QsN0RBIXHPjEXOkoM2VCD5zCd+5i5dtCFX7Mxh	/h6pslWm0ODBVFzLlwY9CXv4Vu62QsN0RBIXHPjEXOkoM2VCD5zCd+5i5dtCFX7Mxh
	LThb2ZJ3efklbSB9RQRwxcmRvCPV7z6lt/Ds9sucVE1RDODYHjx+iWnAUQrlos6ZQb	LThb2ZJ3efklbSB9RQRwxcmRvCPV7z6lt/Ds9sucVE1RDODYHjx+iWnAUQrlos6ZQb
	u/YOUGjf60LPpyljfPu3EpFwo80mSHyQlP/4S5KEykgPQMgCqLPPKvJwu1aAIDj+jG	u/YOUGjf60LPpyljfPu3EpFwo80mSHyQlP/4S5KEykgPQMgCqLPPKvJwu1aAIDj+jG
	q2ylO3fmc/ERDeDWACtR67YNabEKBWtjqCRLNxKttazViJTZ5drcLfpX0853KoougX	q2ylO3fmc/ERDeDWACtR67YNabEKBWtjqCRLNxKttazViJTZ5drcLfpX0853KoougX
	Rltp7zdoLdy4A==	Rltp7zdoLdy4A==

	From: DMARC Filter <DMARC@gen.example>;	From: DMARC Filter <DMARC@gen.example>;
	To: dmarcfail@consumer.example	To: dmarcfail@consumer.example
	Date: Tue, 19 Jul 2022 00:57:48 -0500 (CDT)	Date: Tue, 19 Jul 2022 00:57:48 -0500 (CDT)
	Subject: FW: This is the original subject	Subject: FW: This is the original subject
	Mime-Version: 1.0	Mime-Version: 1.0
	Content-Type: multipart/report; report-type=feedback-report;	Content-Type: multipart/report; report-type=feedback-report;

	boundary="=_mime_boundary_"	boundary="=_mime_boundary_"
	Message-Id: <20220719055748.4AE9D403CC@gen.example>;	Message-Id: <20220719055748.4AE9D403CC@gen.example>;

	This is a MIME-formatted message. If you see this text it means that	This is a MIME-formatted message. If you see this text it means that
	your E-mail software does not support MIME-formatted messages.	your E-mail software does not support MIME-formatted messages.

	--=_mime_boundary_	--=_mime_boundary_
	Content-Type: text/plain; charset=utf-8	Content-Type: text/plain; charset=utf-8
	Content-Disposition: inline	Content-Disposition: inline
	Content-Transfer-Encoding: 7bit	Content-Transfer-Encoding: 7bit

	This is an authentication failure report for an email message	This is an authentication failure report for an email message

	skipping to change at line 446 ¶	skipping to change at line 526 ¶
	Original-Mail-From: author=gen.example@forwarder.example	Original-Mail-From: author=gen.example@forwarder.example
	Source-IP: 192.0.2.2	Source-IP: 192.0.2.2
	Source-Port: 12345	Source-Port: 12345
	Reported-Domain: consumer.example	Reported-Domain: consumer.example

	--=_mime_boundary_	--=_mime_boundary_
	Content-Type: message/rfc822; charset=utf-8	Content-Type: message/rfc822; charset=utf-8
	Content-Transfer-Encoding: 7bit	Content-Transfer-Encoding: 7bit

	Authentication-Results: gen.example;	Authentication-Results: gen.example;

	dkim=permerror header.d=forwarder.example header.b="EjCbN/c3";	dkim=permerror header.d=forwarder.example header.b="EjCbN/c3";
	dkim=temperror header.d=forwarder.example header.b="mQ8GEWPc";	dkim=temperror header.d=forwarder.example header.b="mQ8GEWPc";
	dkim=permerror header.d=consumer.example header.b="hETrymCb";	dkim=permerror header.d=consumer.example header.b="hETrymCb";
	dkim=neutral header.d=consumer.example header.b="C2nsAp3A";	dkim=neutral header.d=consumer.example header.b="C2nsAp3A";
	Received: from mail.forwarder.example	Received: from mail.forwarder.example
	(mail.forwarder.example [IPv6:2001:db8::23ac])	(mail.forwarder.example [IPv6:2001:db8::23ac])
	by mail.gen.example (Postfix) with ESMTP id 5E8B0C159826	by mail.gen.example (Postfix) with ESMTP id 5E8B0C159826

	for <x@gen.example>; Sun, 14 Aug 2022 07:58:29 -0700 (PDT)	for <x@gen.example>; Sun, 14 Aug 2022 07:58:29 -0700 (PDT)
	Received: from mail.forwarder.example (localhost [127.0.0.1])	Received: from mail.forwarder.example (localhost [127.0.0.1])
	by mail.forwarder.example (Postfix) with ESMTP id 4Ln7Qw4fnvz6Bq	by mail.forwarder.example (Postfix) with ESMTP id 4Ln7Qw4fnvz6Bq

	for <x@gen.example>; Tue, 19 Jul 2022 07:57:44 +0200	for <x@gen.example>; Tue, 19 Jul 2022 07:57:44 +0200
	DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed;	DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed;
	d=forwarder.example; s=ed25519-59hs; t=1658210264;	d=forwarder.example; s=ed25519-59hs; t=1658210264;
	x=1663210264; bh=KYH/g7ForvDbnyyDLYSjauMYMW6sEIqu75/9w3OIONg=;	x=1663210264; bh=KYH/g7ForvDbnyyDLYSjauMYMW6sEIqu75/9w3OIONg=;
	h=Message-ID:Date:List-Id:List-Archive:List-Post:List-Help:	h=Message-ID:Date:List-Id:List-Archive:List-Post:List-Help:
	List-Subscribe:List-Unsubscribe:List-Owner:MIME-Version:Subject:	List-Subscribe:List-Unsubscribe:List-Owner:MIME-Version:Subject:
	To:References:From:In-Reply-To:Content-Type:	To:References:From:In-Reply-To:Content-Type:
	Content-Transfer-Encoding:autocrypt:cc:content-transfer-encoding:	Content-Transfer-Encoding:autocrypt:cc:content-transfer-encoding:
	content-type:date:from:in-reply-to:message-id:mime-version:	content-type:date:from:in-reply-to:message-id:mime-version:
	openpgp:references:subject:to;	openpgp:references:subject:to;
	b=EjCbN/c3bTU4QkZH/zwTbYxBDp0k8kpmWSXh5h1M7T8J4vtRo+hvafJazT3ZRgq+7	b=EjCbN/c3bTU4QkZH/zwTbYxBDp0k8kpmWSXh5h1M7T8J4vtRo+hvafJazT3ZRgq+7

	skipping to change at line 491 ¶	skipping to change at line 571 ¶
	i/KLHiZXtJsL3/Pr/4TL+HTjdX8EDSsy1K5/JCvJCFsJHnSvkEaJQGLn/2m03eW9r8	i/KLHiZXtJsL3/Pr/4TL+HTjdX8EDSsy1K5/JCvJCFsJHnSvkEaJQGLn/2m03eW9r8
	9w1bQ90aY+VCQ==	9w1bQ90aY+VCQ==
	X-Original-To: users@forwarder.example	X-Original-To: users@forwarder.example
	Received: from mail.consumer.example	Received: from mail.consumer.example
	(mail.consumer.example [192.0.2.4])	(mail.consumer.example [192.0.2.4])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	key-exchange ECDHE (P-256) server-signature ECDSA (P-384)	key-exchange ECDHE (P-256) server-signature ECDSA (P-384)
	server-digest SHA384)	server-digest SHA384)
	(Client did not present a certificate)	(Client did not present a certificate)
	by mail.forwarder.example (Postfix) with ESMTPS id 4Ln7Qs55xmz4nP	by mail.forwarder.example (Postfix) with ESMTPS id 4Ln7Qs55xmz4nP

	for <users@forwarder.example>;	for <users@forwarder.example>;
	Tue, 19 Jul 2022 07:57:41 +0200 (CEST)	Tue, 19 Jul 2022 07:57:41 +0200 (CEST)
	Authentication-Results: mail.forwarder.example;	Authentication-Results: mail.forwarder.example;
	arc=none smtp.remote-ip=192.0.2.4	arc=none smtp.remote-ip=192.0.2.4
	Authentication-Results: mail.forwarder.example;	Authentication-Results: mail.forwarder.example;
	dkim=pass (512-bit key; secure) header.d=consumer.example	dkim=pass (512-bit key; secure) header.d=consumer.example
	header.i=@consumer.example header.a=ed25519-sha256	header.i=@consumer.example header.a=ed25519-sha256
	header.s=epsilon header.b=hETrymCb;	header.s=epsilon header.b=hETrymCb;
	dkim=pass (1152-bit key; secure) header.d=consumer.example	dkim=pass (1152-bit key; secure) header.d=consumer.example
	header.i=@consumer.example header.a=rsa-sha256	header.i=@consumer.example header.a=rsa-sha256
	header.s=delta header.b=C2nsAp3A	header.s=delta header.b=C2nsAp3A

	skipping to change at line 515 ¶	skipping to change at line 595 ¶
	h=Date:Subject:To:References:From:In-Reply-To;	h=Date:Subject:To:References:From:In-Reply-To;
	b=hETrymCbz6T1Dyo5dCG9dk8rPykKLdhJCPFeJ9TiiP/kaoN2afpUYtj+SrI+I83lp	b=hETrymCbz6T1Dyo5dCG9dk8rPykKLdhJCPFeJ9TiiP/kaoN2afpUYtj+SrI+I83lp
	p1F/FfYSGy7zz3Q3OdxBA==	p1F/FfYSGy7zz3Q3OdxBA==
	DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;	DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=consumer.example; s=delta; t=1658210255;	d=consumer.example; s=delta; t=1658210255;
	bh=KYH/g7ForvDbnyyDLYSjauMYMW6sEIqu75/9w3OIONg=;	bh=KYH/g7ForvDbnyyDLYSjauMYMW6sEIqu75/9w3OIONg=;
	h=Date:To:References:From:In-Reply-To;	h=Date:To:References:From:In-Reply-To;
	b=C2nsAp3AMNX33Nq7nN/StPo921xE3XGF8Ju3iAKdYB3EKhsril0N5IjWGlglJECst	b=C2nsAp3AMNX33Nq7nN/StPo921xE3XGF8Ju3iAKdYB3EKhsril0N5IjWGlglJECst
	jLNKSo7KWZZ2lkH/dVZ9Rs1GHT2uaKy1sc/xmNIC5rHdhrxammiwpTSo4PsT8disfc	jLNKSo7KWZZ2lkH/dVZ9Rs1GHT2uaKy1sc/xmNIC5rHdhrxammiwpTSo4PsT8disfc
	3DVF6Q62n0EsdLFqcw1KY8A9inFqYKY2tqoo+y4zMtItqCYx3xjsj3I0IFLuX	3DVF6Q62n0EsdLFqcw1KY8A9inFqYKY2tqoo+y4zMtItqCYx3xjsj3I0IFLuX

	Author: Message Author <author@consumer.example>	Author: Message Author <author@consumer.example>
	Received: from [192.0.2.8] (host-8-2-0-192.isp.example [192.0.2.8])	Received: from [192.0.2.8] (host-8-2-0-192.isp.example [192.0.2.8])
	(AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3,128bits,	(AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3,128bits,
	ECDHE_RSA_AES_128_GCM_SHA256)	ECDHE_RSA_AES_128_GCM_SHA256)
	by mail.consumer.example with ESMTPSA	by mail.consumer.example with ESMTPSA
	id 00000000005DC076.00004417; Tue, 19 Jul 2022 07:57:35 +0200	id 00000000005DC076.00004417; Tue, 19 Jul 2022 07:57:35 +0200

	Message-ID: <2431dc66-b010-c9cc-4f2b-a1f889f8bdb4@consumer.example>	Message-ID: <2431dc66-b010-c9cc-4f2b-a1f889f8bdb4@consumer.example>
	Date: Tue, 19 Jul 2022 07:57:33 +0200	Date: Tue, 19 Jul 2022 07:57:33 +0200

	List-Id: <users.forwarder.example>	List-Id: <users.forwarder.example>
	List-Post: <mailto:users@forwarder.example>	List-Post: <mailto:users@forwarder.example>
	List-Help: <mailto:users+help@forwarder.example>	List-Help: <mailto:users+help@forwarder.example>
	List-Subscribe: <mailto:users+subscribe@forwarder.example>	List-Subscribe: <mailto:users+subscribe@forwarder.example>
	List-Unsubscribe: <mailto:users+unsubscribe@forwarder.example>	List-Unsubscribe: <mailto:users+unsubscribe@forwarder.example>
	List-Owner: <mailto:users+owner@forwarder.example>	List-Owner: <mailto:users+owner@forwarder.example>
	Precedence: list	Precedence: list
	MIME-Version: 1.0	MIME-Version: 1.0
	Subject: This is the original subject	Subject: This is the original subject
	Content-Language: en-US	Content-Language: en-US
	To: users@forwarder.example	To: users@forwarder.example
	Authentication-Results: consumer.example; auth=pass (details omitted)	Authentication-Results: consumer.example; auth=pass (details omitted)

	From: Message Author <author@consumer.example>	From: Message Author <author@consumer.example>
	In-Reply-To: <20220718102753.0f6d9dde.cel@example.com>	In-Reply-To: <20220718102753.0f6d9dde.cel@example.com>
	Content-Type: text/plain; charset=UTF-8; format=flowed	Content-Type: text/plain; charset=UTF-8; format=flowed
	Content-Transfer-Encoding: 8bit	Content-Transfer-Encoding: 8bit

	[ Message body was here ]	[ Message body was here ]

	</sourcecode>	--=_mime_boundary_--]]></sourcecode>
	<t>The Source-Port field definition is given by <xref target="RFC6692"></xref></
	t>	<t>The Source-Port field definition is given by <xref target="RFC6692"/>.</t>
	<t>In the final MIME entity, the local-parts of To and From addresses are	<t>In the final MIME entity, the local-parts of To and From addresses are
	reported unredacted. Since we know that the local parts are PII, we	reported unredacted. Since we know that the local parts are PII, we
	can reduce the privacy risk by redacting them. In the example, the	can reduce the privacy risk by redacting them. In the example, the

	report generator could have replaced "users" with "lRLxexey"	report generator could have replaced "users" with "lRLxexey" and
	and	"author" with "RT47aVey" throughout the entity.</t>
	"author" with "RT47aVey" throughout the entity.</t>
	<t>If the body of the message is not included, the last MIME entity	<t>If the body of the message is not included, the last MIME entity

	would have "Content-Type: text/rfc822-headers" instead of message/rfc8	would have "Content-Type: text/rfc822-headers" instead of "message/rfc822".</t>
	22.</t>
	</section>

	<section anchor="change-log-change-log"><name>Change Log {change-log}</name>
	<t>[RFC Editor: Please remove this section prior to publication.]</t>

	<section anchor="s00"><name>00 to 01</name>

	<ul>
	<li><t>Replace references to RFC7489 with references to I-D.ietf-dmarc-dmarcbis.
	</t>
	</li>
	<li><t>Replace the 2nd paragraph in the Introduction with the text proposed by N
	ed
	for Ticket #55, which enjoys some consensus:<br />

	<eref target="https://mailarchive.ietf.org/arch/msg/dmarc
	/HptVyJ9SgrfxWRbeGwORagPrhCw">https://mailarchive.ietf.org/arch/msg/dmarc/HptVyJ
	9SgrfxWRbeGwORagPrhCw</eref></t>
	</li>
	<li><t>Strike a spurious sentence about criticality of feedback, which was
	meant for feedback in general, not failure reports. In f
	act, failure
	reports are not critical to establishing and maintaining
	accurate authentication
	deployments. Still attributable to Ticket #55.</t>
	</li>
	<li><t>Remove the content of section "Verifying External Destinations"
	and refer to I-D.ietf-dmarc-aggregate-reporting.</t>
	</li>
	<li><t>Remove the content of section "Security Considerations"
	and refer to I-D.ietf-dmarc-dmarcbis.</t>
	</li>
	<li><t>Slightly tweak the wording of the example in Appendix A.1
	so that it makes sense standing alone.</t>
	</li>
	<li><t>Remove the sentence containing "must include any URI(s)",
	as the issue arose <eref target="https://mailarchive.ietf.org/arch/msg/d
	marc/mFk0qiTCy8tzghRvcxus01W_Blw"/>.</t>
	</li>
	<li><t>Add paragraph in Security Considerations, noting that
	note that Organizational Domains are only an approximation...</t>
	</li>
	<li><t>Add a Transport section, mentioning DMARC conformance and
	failure report mail loops (Ticket #28).</t>
	</li>
	</ul>
	</section>

	<section anchor="s01"><name>01 to 02</name>

	<ul spacing="compact">
	<li>Add a sentence to make clear that counting failures is not the aim.</li>
	</ul>
	</section>

	<section anchor="s02"><name>02 to 03</name>

	<ul spacing="compact">
	<li>Updated references.</li>
	</ul>
	</section>

	<section anchor="s03"><name>03 to 04</name>

	<ul>
	<li><t>Add an example report.</t>
	</li>
	<li><t>Remove the old Acknowledgements section.</t>
	</li>
	<li><t>Add a IANA Consideration section</t>
	</li>
	</ul>
	</section>

	<section anchor="s04"><name>04 to 05</name>

	<ul>
	<li><t>Convert to markdown</t>
	</li>
	<li><t>Remove irrelevant material.</t>
	</li>
	</ul>
	</section>

	<section anchor="s05"><name>05 to 06</name>

	<ul>
	<li><t>A Vesely was incorrectly removed from list of document editors.
	Corrected.</t>
	</li>
	<li><t>Added Terminology section with recoomended boilerplate re:
	RFC2119.</t>
	</li>
	</ul>
	</section>

	<section anchor="s06"><name>06 to 07</name>

	<ul>
	<li><t>Reduce Terminology section</t>
	</li>
	<li><t>minor nits</t>
	</li>
	</ul>
	</section>

	<section anchor="s07"><name>07 to 08</name>

	<ul>
	<li><t>Specify what detailed information a report contains, in the 1st paragraph
	of Section 2</t>
	</li>
	<li><t>A couple of typos</t>
	</li>
	</ul>
	</section>

	<section anchor="s08"><name>08 to 09</name>

	<ul spacing="compact">
	<li>Replace &lt; with < and &gt; with > in Appendix B</li>
	</ul>
	</section>

	<section anchor="s09"><name>09 to 10</name>

	<ul spacing="compact">
	<li>Add an informative section about other failure reports (DKIM, SPF)</li>
	</ul>
	</section>

	<section anchor="s10"><name>10 to 11</name>

	<ul spacing="compact">
	<li>Remove appendix with redundant examples - pull request by Daniel K.</li>
	</ul>
	</section>

	<section anchor="s11"><name>11 to 12</name>

	<ul spacing="compact">
	<li>Reference Terminology in <xref target="I-D.ietf-dmarc-dmarcbis"></xref></li>
	<li>Expand the Verifying External Destinations section and reference <xref targe
	t="I-D.ietf-dmarc-aggregate-reporting"></xref></li>
	</ul>
	</section>

	<section anchor="s12"><name>12 to 13</name>

	<ul spacing="compact">
	<li>Update references to numbered sections of <xref target="I-D.ietf-dmarc-dmarc
	bis"></xref> and <xref target="I-D.ietf-dmarc-aggregate-reporting"></xref></li>
	<li>Clarify potential information disclosures when failure reports are sent</li>
	<li>Minor edits for readability and clarity</li>
	</ul>
	</section>

	<section anchor="s13"><name>13 to 14</name>

	<ul spacing="compact">
	<li>In the introduction (last paragraph) mention that the purpose is twofold, de
	bug and anti-abuse.</li>
	<li>In Section 2 (2nd paragraph) clarify that failure reports allow better deter
	mining the failure reason.</li>
	</ul>
	</section>

	<section anchor="s14"><name>14 to 15</name>

	<ul spacing="compact">
	<li>Expanded Privacy Considerations section as discussed on list.</li>
	<li>Add tentative IANA Consideration subsections.</li>
	</ul>
	</section>

	<section anchor="s15"><name>15 to 16</name>

	<ul spacing="compact">
	<li>Qualification of RFCs 6651/2 in Section 3.</li>
	<li>Spell "Auth-Failure" at bullet 3 of Section 4.</li>
	<li>Cite RFC 6590 when mentioning redaction.</li>
	<li>s/using the wrong sending path/failing authentication/.</li>
	<li>Remove unnecessary IANA Considerations.</li>
	</ul>
	</section>

	<section anchor="s16"><name>16 to 17</name>

	<ul spacing="compact">
	<li>Remove the last paragraph of Secority Considerations.</li>
	</ul>
	</section>

	<section anchor="s17"><name>17 to 18</name>

	<ul spacing="compact">
	<li>Reword the first purpose (Intro) and cite aggregate-reporting.</li>
	<li>Forward reference to Privacy Consideration.</li>
	<li>s/fo=/"fo"/, /ruf=/ruf/, /urls/URIs/.</li>
	<li>Specify parent registry in IANA Considerations.</li>
	</ul>
	</section>

	<section anchor="s18"><name>18 to 19</name>

	<ul spacing="compact">
	<li>Remove the term "scalable" from Abstract and Introduction.</li>
	<li>s/Sender Domain/Domain Owner/.</li>
	<li>Reference to dmarcbis, section 3.2 on its own line.</li>
	<li>Remove the phrase (sometimes referred to as "forensic reports").</
	li>
	<li>Note that Domain Owner can use dot-forward to not decalre consumer.</li>
	<li>Mention we could have encrypted the example.</li>
	<li>Don't mention MX.</li>
	</ul>
	</section>

	<section anchor="s19"><name>19 to 20</name>

	<ul spacing="compact">
	<li>Replace "dot-forward" with a periphrasis to downplay final destina
	tion.</li>
	</ul>
	</section>

	<section anchor="s20"><name>20 to 21</name>

	<ul spacing="compact">
	<li>Move the last paragraph of Section 2 to Security Considerations.</li>
	<li>Explicitly say we obsolete 7489 and update 6591 in the abstract.</li>
	<li>Reword "Without this check, a bad actor ..." in Section 5.</li>
	<li>Fix IANA request.</li>
	<li>Mention RFC 6591 in Terminology (Section 1.1).</li>
	</ul>
	</section>

	<section anchor="s21"><name>21 to 22</name>

	<ul spacing="compact">
	<li>Reword obsoleting sentence in the abstract and move it to Section 1.2.</li>
	</ul>
	</section>	</section>


	<section anchor="s22"><name>22 to 23</name>	<!-- [rfced] FYI - We have added expansions for the following abbreviations
		per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
		expansion in the document carefully to ensure correctness.


	<ul spacing="compact">	comments and/or folding white space (CFWS)
	<li>Merge Med's pull request</li>	DomainKeys Identified Mail (DKIM)
	</ul>	Sender Policy Framework (SPF)
	</section>	-->


	<section anchor="s23"><name>23 to 24</name>	<!-- [rfced] Please review the "Inclusive Language" portion of the online
		Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
		and let us know if any changes are needed. Updates of this nature typically
		result in more precise language, which is helpful for readers.


	<ul spacing="compact">	Note that our script did not flag any words in particular, but this should
	<li>"Defang" issue.</li>	still be reviewed as a best practice.
	<li>Avoid using "defined by" twice (Section 2, paragraph 5).</li>	-->
	<li>Fix the normative part of rate-limiting (Section 2, paragraph 6).</li>
	<li>Recommend (non-2119) to rate limit (Section 5.1, paragraph 2).</li>
	<li>Reference RFC 5322 (Section 4, bullet 2).</li>
	</ul>
	</section>
	</section>

	</back>	</back>

	</rfc>	</rfc>

End of changes. 67 change blocks.
	465 lines changed or deleted	294 lines changed or added
This html diff was produced by rfcdiff 1.48.