rfc9990v1.txt		rfc9990.txt
	skipping to change at line 151 ¶		skipping to change at line 151 ¶
	* Mail Receiver		* Mail Receiver
	* Organizational Domain		* Organizational Domain
	* Report Consumer		* Report Consumer
	2. Document Status		2. Document Status
	This document, in part, along with [RFC9989] and [RFC9991], obsoletes		This document, in part, along with [RFC9989] and [RFC9991], obsoletes
	and replaces DMARC [RFC7489].		and replaces DMARC [RFC7489]. Note that errata for this document has
			been addressed as described in [RFC9989].
	3. DMARC Feedback		3. DMARC Feedback
	Providing Domain Owners with visibility into how Mail Receivers		Providing Domain Owners with visibility into how Mail Receivers
	implement and enforce the DMARC mechanism in the form of feedback is		implement and enforce the DMARC mechanism in the form of feedback is
	critical to establishing and maintaining accurate authentication		critical to establishing and maintaining accurate authentication
	deployments. When Domain Owners can see what effect their policies		deployments. When Domain Owners can see what effect their policies
	and practices are having, they are better willing and able to use		and practices are having, they are better willing and able to use
	quarantine and reject policies.		quarantine and reject policies.
	skipping to change at line 425 ¶		skipping to change at line 426 ¶
	there will be at least one "record" element.		there will be at least one "record" element.
	This element contains all the authentication results that were		This element contains all the authentication results that were
	evaluated by the receiving system for the given set of messages.		evaluated by the receiving system for the given set of messages.
	An unlimited number of "record" elements may be specified.		An unlimited number of "record" elements may be specified.
	Use of extensions may cause other elements to be added to the end of		Use of extensions may cause other elements to be added to the end of
	the record; such elements MUST be namespaced.		the record; such elements MUST be namespaced.
	One record per (IP, result, authentication identifiers) tuples.		One record (IP, result, authentication identifiers) per tuple.
	The elements in this table MUST appear in the order listed.		The elements in this table MUST appear in the order listed.
	+==============+===+============================================+		+==============+===+============================================+
	| Element name | # | Content |		| Element name | # | Content |
	+==============+===+============================================+		+==============+===+============================================+
	| row | R | See Section 3.1.1.8. |		| row | R | See Section 3.1.1.8. |
	+--------------+---+--------------------------------------------+		+--------------+---+--------------------------------------------+
	| identifiers | R | The data that was used to apply policy for |		| identifiers | R | The data that was used to apply policy for |
	| | | the given "row"; see Section 3.1.1.10. |		| | | the given "row"; see Section 3.1.1.10. |
	skipping to change at line 630 ¶		skipping to change at line 631 ¶
	to report: example.com, foo.example.com, and bar.example.com. There		to report: example.com, foo.example.com, and bar.example.com. There
	will be explicit DMARC Policy Records for example.com and		will be explicit DMARC Policy Records for example.com and
	bar.example.com, with distinct policies. There is no explicit DMARC		bar.example.com, with distinct policies. There is no explicit DMARC
	Policy Record for foo.example.com, so it will be reliant on the		Policy Record for foo.example.com, so it will be reliant on the
	policy described for example.com. For a report period, there would		policy described for example.com. For a report period, there would
	now be two reports.		now be two reports.
	The first report will be for bar.example.com and contain only one		The first report will be for bar.example.com and contain only one
	"record", for bar.example.com. The second report will be for		"record", for bar.example.com. The second report will be for
	example.com and will contain multiple "record" elements, one for		example.com and will contain multiple "record" elements, one for
	example.com and one for foo.example.com (and extensibly, other		example.com and one for foo.example.com (and by extension, other
	"record" elements for subdomains that likewise did not have an		"record" elements for subdomains that likewise did not have an
	explicit DMARC Policy Record).		explicit DMARC Policy Record).
	3.1.3. DKIM Signatures in Aggregate Reports		3.1.3. DKIM Signatures in Aggregate Reports
	Within a single message, the possibility exists that there could be		Within a single message, the possibility exists that there could be
	multiple DKIM signatures. When validation of the message occurs,		multiple DKIM signatures. When validation of the message occurs,
	some signatures may pass, while some may not. As these pertain to		some signatures may pass, while some may not. As these pertain to
	DMARC, and especially to aggregate reporting, reporters may not find		DMARC, and especially to aggregate reporting, reporters may not find
	it clear which DKIM signatures they should include in a report.		it clear which DKIM signatures they should include in a report.
	skipping to change at line 787 ¶		skipping to change at line 788 ¶
	The format specified here is not very strict, as the key goal is		The format specified here is not very strict, as the key goal is
	uniqueness. In order to create this uniqueness, the Mail Receiver		uniqueness. In order to create this uniqueness, the Mail Receiver
	may wish to use elements such as the receiving domain, the sending		may wish to use elements such as the receiving domain, the sending
	domain, and a timestamp in combination. An example string might be		domain, and a timestamp in combination. An example string might be
	"1721054318-example.com@example.org". An alternate could use a date		"1721054318-example.com@example.org". An alternate could use a date
	string such as "2024-03-27_example.com@example.org".		string such as "2024-03-27_example.com@example.org".
	3.5.2. Email		3.5.2. Email
	The message generated by the Mail Receiver MUST be a [RFC5322]		The message generated by the Mail Receiver MUST be as described in
	message formatted per [RFC2045]. The aggregate report itself MUST be		[RFC5322] and formatted per [RFC2045]. The aggregate report itself
	included in one of the parts of the message, as an attachment with a		MUST be included in one of the parts of the message, as an attachment
	corresponding media type from below. A human-readable annotation MAY		with a corresponding media type from below. A human-readable
	be included as a body part (with a human-friendly content-type, such		annotation MAY be included as a body part (with a human-friendly
	as "text/plain" or "text/html").		content-type, such as "text/plain" or "text/html").
	The aggregate data MUST be an XML file that SHOULD be subjected to		The aggregate data MUST be an XML file that SHOULD be subjected to
	GZIP [RFC1952] compression. Declining to apply compression can cause		GZIP [RFC1952] compression. Declining to apply compression can cause
	the report to be too large for a receiver to process (the total		the report to be too large for a receiver to process (the total
	message size could exceed the receiver SMTP size limit); doing the		message size could exceed the receiver SMTP size limit); doing the
	compression increases the chances of acceptance of the report at some		compression increases the chances of acceptance of the report at some
	compute cost. The aggregate data MUST be present using the media		compute cost. The aggregate data MUST be present using the media
	type "application/gzip" if compressed (see [RFC6713]) and "text/xml"		type "application/gzip" if compressed (see [RFC6713]) and "text/xml"
	otherwise. The attachment filename MUST be constructed using the		otherwise. The attachment filename MUST be constructed using the
	following ABNF:		following ABNF:
	skipping to change at line 920 ¶		skipping to change at line 921 ¶
	* Reject back to sender, ideally with a permfail error noting the		* Reject back to sender, ideally with a permfail error noting the
	duplicate receipt		duplicate receipt
	* Discard upon receipt		* Discard upon receipt
	* Inspect the contents to evaluate the timestamps and reported data,		* Inspect the contents to evaluate the timestamps and reported data,
	act as appropriate		act as appropriate
	* Accept the duplicate data		* Accept the duplicate data
	When accepting the data, that's likely in a situation where it's not		When accepting the data, it's likely that the duplicate data has not
	yet noticed or a one-off experience. Long-term duplicate data is not		yet been noticed and is a one-off experience. Long-term duplicate
	ideal. In the situation of a partial time frame overlap, there is no		data is not ideal. In the situation of a partial time frame overlap,
	clear way to distinguish the impact of the overlap. The receiver		there is no clear way to distinguish the impact of the overlap. The
	would need to accept or reject the duplicate data in whole.		receiver would need to accept or reject the duplicate data in whole.
	4. Verifying External Destinations		4. Verifying External Destinations
	It is possible to specify destinations for the different reports that		It is possible to specify destinations for the different reports that
	are outside the authority of the Domain Owner making the request.		are outside the authority of the Domain Owner making the request.
	This allows domains that do not operate mail servers to request		This allows domains that do not operate mail servers to request
	reports and have them go someplace that is able to receive and		reports and have them go someplace that is able to receive and
	process them.		process them.
	Without checks, this would allow a bad actor to publish a DMARC		Without checks, this would allow a bad actor to publish a DMARC
	skipping to change at line 1017 ¶		skipping to change at line 1018 ¶
	can use a wildcard DNS record. For example, a TXT resource record at		can use a wildcard DNS record. For example, a TXT resource record at
	"*._report._dmarc.example.com" containing at least "v=DMARC1"		"*._report._dmarc.example.com" containing at least "v=DMARC1"
	confirms that example.com is willing to receive DMARC reports for any		confirms that example.com is willing to receive DMARC reports for any
	domain.		domain.
	If the Report Consumer is overcome by volume, it can simply remove		If the Report Consumer is overcome by volume, it can simply remove
	the confirming DNS record. However, due to positive caching, the		the confirming DNS record. However, due to positive caching, the
	change could take as long as the Time to Live (TTL) on the record to		change could take as long as the Time to Live (TTL) on the record to
	go into effect.		go into effect.
	If the length of the DNS query is excessively long (Step 4 above),		If the DNS query length is excessively long (Step 4 above), the
	the Domain Owner may need to reconsider the domain being used to be		Domain Owner may need to consider using a shorter domain name or
	shorter or reach out to another party that may allow for a shorter		coordinate with another party that may allow for a shorter DNS label.
	DNS label.
	5. Extensible Reporting		5. Extensible Reporting
	DMARC reports allow for some extensibility, as defined by future		DMARC reports allow for some extensibility, as defined by future
	documents that utilize DMARC as a foundation. These extensions MUST		documents that utilize DMARC as a foundation. These extensions MUST
	be properly formatted XML and meant to exist within the structure of		be properly formatted XML and meant to exist within the structure of
	a DMARC report. Two positions of type "<any>" are provided in the		a DMARC report. Two positions of type "<any>" are provided in the
	existing DMARC structure: one at file level in an "<extension>"		existing DMARC structure: one at file level in an "<extension>"
	element after "<policy_published>" and one at record level after		element after "<policy_published>" and one at record level after
	"<auth_results>". In either case, the extensions MUST contain a URI		"<auth_results>". In either case, the extensions MUST contain a URI
	skipping to change at line 1722 ¶		skipping to change at line 1722 ¶
	<xs:sequence>		<xs:sequence>
	<xs:element name="version" type="xs:decimal"		<xs:element name="version" type="xs:decimal"
	minOccurs="0" maxOccurs="1"/>		minOccurs="0" maxOccurs="1"/>
	<xs:element name="report_metadata" type="ReportMetadataType"		<xs:element name="report_metadata" type="ReportMetadataType"
	minOccurs="1" maxOccurs="1"/>		minOccurs="1" maxOccurs="1"/>
	<xs:element name="policy_published" type="PolicyPublishedType"		<xs:element name="policy_published" type="PolicyPublishedType"
	minOccurs="1" maxOccurs="1"/>		minOccurs="1" maxOccurs="1"/>
	<!-- Extension at top level -->		<!-- Extension at top level -->
	<xs:element name="extension" type="ExtensionType"		<xs:element name="extension" type="ExtensionType"
	minOccurs="0" maxOccurs="1"/>		minOccurs="0" maxOccurs="1"/>
	<!-- One record per (IP, result, IDs Auths) tuples -->		<!-- One record (IP, result, IDs Auths) per tuple -->
	<xs:element name="record" type="RecordType"		<xs:element name="record" type="RecordType"
	minOccurs="1" maxOccurs="unbounded"/>		minOccurs="1" maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
	</xs:schema>		</xs:schema>
	Appendix B. Sample Report		Appendix B. Sample Report
	<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0">		<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0">
End of changes. 7 change blocks.
	19 lines changed or deleted		19 lines changed or added
This html diff was produced by rfcdiff 1.48.