draft-brotman-dkim-fbl-01.txt		draft-brotman-dkim-fbl-02.txt
	Network Working Group A. Brotman		Network Working Group A. Brotman
	Internet-Draft Comcast, Inc		Internet-Draft Comcast, Inc
	Intended status: Standards Track 23 October 2023		Intended status: Standards Track 26 March 2024
	Expires: 25 April 2024		Expires: 27 September 2024
	Email Feedback Reports for DKIM Signers		Email Feedback Reports for DKIM Signers
	draft-brotman-dkim-fbl-01		draft-brotman-dkim-fbl-02
	Abstract		Abstract
	Mechanism to discover a destination used to deliver user-supplied FBL		Mechanism to discover a destination used to deliver user-supplied FBL
	reports to an original DKIM signer or other responsible parties.		reports to an original DKIM signer or other responsible parties.
	This should allow the reporting entity to deliver reports via email		This allows the reporting entity to deliver reports for each party
	for each party which has affixed a validating DKIM signature. The		which has affixed a validating DKIM signature. The discovery is made
	discovery is made via DNS and the record is constructed using items		via DNS and the record is constructed using items within the DKIM
	within the DKIM signature in the message.		signature in the message.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 25 April 2024.		This Internet-Draft will expire on 27 September 2024.
	Copyright Notice		Copyright Notice
	Copyright (c) 2023 IETF Trust and the persons identified as the		Copyright (c) 2024 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
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	RFC draft-brotman-dkim-fbl-01 DKIM-FBL October 2023
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Discovery using DNS . . . . . . . . . . . . . . . . . . . . . 2		2. Discovery using DNS . . . . . . . . . . . . . . . . . . . . . 3
	3. DNS Record Location . . . . . . . . . . . . . . . . . . . . . 3		3. DNS Record Location . . . . . . . . . . . . . . . . . . . . . 3
	4. DNS Record Format . . . . . . . . . . . . . . . . . . . . . . 4		4. DNS Record Format . . . . . . . . . . . . . . . . . . . . . . 4
	4.1. Samples . . . . . . . . . . . . . . . . . . . . . . . . . 4		4.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 5
	5. Report Contents . . . . . . . . . . . . . . . . . . . . . . . 5		5. Report Contents . . . . . . . . . . . . . . . . . . . . . . . 5
	6. Verifying External Destinations . . . . . . . . . . . . . . . 5		5.1. arf . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 5		5.2. xarf . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	7.1. Feedback to Malicious Senders . . . . . . . . . . . . . . 6		5.3. Aggregate FBL Reports . . . . . . . . . . . . . . . . . . 5
	7.2. Report Contents for ARF . . . . . . . . . . . . . . . . . 6		5.3.1. Report Format . . . . . . . . . . . . . . . . . . . . 6
	8. Other Considerations . . . . . . . . . . . . . . . . . . . . 6		6. Content Flag . . . . . . . . . . . . . . . . . . . . . . . . 6
	8.1. Supplying FP Reports . . . . . . . . . . . . . . . . . . 6		7. Delivery Methods . . . . . . . . . . . . . . . . . . . . . . 6
	8.2. Site Requirements . . . . . . . . . . . . . . . . . . . . 6		7.1. mailto . . . . . . . . . . . . . . . . . . . . . . . . . 6
	8.3. Report Delivery . . . . . . . . . . . . . . . . . . . . . 6		7.2. https . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6		7.2.1. https Feedback-Type Header . . . . . . . . . . . . . 7
	10. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		8. Verifying External Destinations . . . . . . . . . . . . . . . 8
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	12. Normative References . . . . . . . . . . . . . . . . . . . . 6		9.1. Feedback to Malicious Senders . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7		9.2. Report Contents for ARF . . . . . . . . . . . . . . . . . 9
			10. Other Considerations . . . . . . . . . . . . . . . . . . . . 9
			10.1. Supplying FP Reports . . . . . . . . . . . . . . . . . . 9
			10.2. Site Requirements . . . . . . . . . . . . . . . . . . . 9
			11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9
			12. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
			13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
			14. Normative References . . . . . . . . . . . . . . . . . . . . 9
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	Historically, Feedback Loops (FBL), typically comprised of False		Historically, Feedback Loops (FBL), typically comprised of False
	Positive (FP) and False Negative (FN) reports, have allowed users the		Positive (FP) and False Negative (FN) reports, have allowed users the
	ability to inform their Mailbox Provider (MBP) that they disagree		ability to inform their Mailbox Provider (MBP) that they disagree
	with a message's placement in the Inbox or Spam folder. In some		with a message's placement in the Inbox or Spam folder. In some
	situations, a MBP may then forward that complaint directly, or via an		situations, an MBP may then forward that feedback directly, or via an
	intermediary, to the original source system of that message.		intermediary, to the original source system of that message.
	Additionally, these complaints reach the source system via a		Traditionally, this source system identified via a registration
	registration system, typically tying a set of IPs or DKIM-based		system, typically tying a set of IPs or DKIM-based domains to a
	domains to a specific reporting address.		specific reporting location.
	By allowing reporters to discover the destination on their own, this		By allowing reporters to discover the destination and reporting
	should make getting FBLs to the original DKIM signer(s) easier.		preferences on their own, this will reduce friction getting FBLs to
			the original DKIM signer(s).
	2. Discovery using DNS		2. Discovery using DNS
	There are alternative approaches for discovering the feedback		There are alternative approaches for discovering the feedback
	information proposed. Particularly, by adding a new header to every		information proposed. This document describes a method for using DNS
	outbound message to define the feedback address.		to discover a feedback address by utilizing the DKIM signature(s)
			within a message itself.
	The advantage of the DNS approach is that it can be changed after		The advantage of the DNS approach is that it can be changed after
	messages are delivered, allowing for old reports to be processed		messages are delivered, allowing for old reports to be processed
	after migrating to a new report receiving endpoint. It also avoids		after migrating to a new report processing provider. It also avoids
	common problems with modifying headers of messages that are already		common problems with modifying headers of messages that are already
	signed by another DKIM signature.		signed by another DKIM signature.
	RFC draft-brotman-dkim-fbl-01 DKIM-FBL October 2023
	Email service providers and intermediaries, which have a shared		Email service providers and intermediaries, which have a shared
	responsibility with an upstream sender, will commonly add their own		responsibility with an upstream sender, will commonly add their own
	DKIM signatures to the messages; thus resulting in the message having		DKIM signatures to the messages, thus resulting in the message having
	two signatures in different DKIM d= domains. Dual-signed messages		two signatures in different DKIM d= domains. Dual-signed messages
	will result in feedback going to the location specified in the DNS		will result in feedback going to the location specified in the DNS
	for both domains. Thus there is no reason to modify any message		for both domains. Thus there is no reason to modify any message
	headers and potentially breaking the original DKIM signature.		headers and potentially break the original DKIM signature.
	3. DNS Record Location		3. DNS Record Location
	The record will combine a label with the "d" value from the DKIM		The record will combine a label with the "d" value from the DKIM
	signature in the message being sent, optionally using a DNS wildcard		signature in the message being sent, optionally using a DNS wildcard
	(* character). Such as the case where "d=example.org", the record		(* character). Such as the case where "d=example.org", the record
	would be located at:		would be located at:
	_feedback._domainkey.example.org		_feedback._domainkey.example.org
	or		or
	*._feedback._domainkey.example.org		*._feedback._domainkey.example.org
	If the reporting destination needs to be different for individual		If the reporting destination needs to be different for individual
	DKIM selectors, each selector will need a DNS record with a value		DKIM selectors, each selector will need a DNS record with a value
	combined with a label with the "s=" value from the DKIM signature in		combined with a label with the "s=" value from the DKIM signature in
	the message being sent. Such as the case where "d=example.org", and		the message being sent. Such as the case where "d=example.org", and
	"s=contact":		"s=contact", for example:
	contact._feedback._domainkey.example.org		contact._feedback._domainkey.example.org
	By including the selector, this allows a domain to be able to segment		By including the selector, this allows a domain to be able to segment
	the feedback to various report processing providers, but a wildcard		the feedback to various report processing providers, but a wildcard
	can no longer be used as a catch-all and an individual record must be		can no longer be used as a catch-all and an individual record must be
	created for each selector in use. DKIM selectors are not supposed to		created for each selector in use. DKIM selectors are not supposed to
	be used for identification purposes, and they should change		be used for identification purposes, and they should change
	frequently to facilitate key rotation. The need for selector level		frequently to facilitate key rotation.
	feedback still needs to be assessed.
			_The need for selector level feedback still needs to be assessed._
	All domain owners that want to ensure they receive all feedback		All domain owners that want to ensure they receive all feedback
	should, at a mimimum, publish a record at the following location as a		should, at a minimum, publish a record at the following location as a
	catch-all:		catch-all:
	_feedback._domainkey.example.org		_feedback._domainkey.example.org
	The DNS entry will contain a TXT record described below.		The DNS entry will contain a TXT record described below.
	RFC draft-brotman-dkim-fbl-01 DKIM-FBL October 2023
	4. DNS Record Format		4. DNS Record Format
	The DNS record should contain the information necessary for a report		The DNS record MUST contain the information necessary for a report
	generator to send the feedback to the proper location.		generator to send the feedback to the proper location.
	v: A string identifying the record. The value must be "DKIMRFBLv1"		v: A string identifying the record. The value must be "DKIMRFBLv1"
	ra: An email address destination for reports. The address should		ra: An address destination for reports. The address should match the
	match the format defined in [RFC5321]. If there is a "rfr" entry,		format defined in [RFC5321]. If there is a "rfr" entry, the "ra" may
	the "ra" may be omitted. If there is more than one target address,		be omitted. If there is more than one target address, the entries
	the entries must be separated by a comma (",").		must be separated by a comma (","). The destination MUST use a
			classification of "mailto" or "https", indicating the transfer
			methods supported by the DKIM signer.
	rfr: An optional field to refer the report generator(s) to another		rfr: An optional field to refer the report generator(s) to another
	DNS entry.		DNS entry.
	c: Content flag. If set to 'n', the reporting entity SHOULD remove		c: Content flag. If set to 'n', the reporting entity SHOULD remove
	all content beyond the headers of the original message that is being		all content beyond the headers of the original message that is being
	reported.		reported. The default is "y".
	h: The header by which the signer can identify the recipient, sender,		h: The header by which the signer can identify the recipient, sender,
	and campaign. If a report generator is trying to create a		and campaign. If a report generator is trying to create a
	minimalistic report, this would be the minimum amount of information		minimalistic report, this would be the minimum amount of information
	to properly act to the report. This field is OPTIONAL, and may		to properly act on the report. This field is OPTIONAL, and MUST
	contain only one attribute.		contain only one attribute.
	f: Format requested by report receiver. Options are "arf" and		hp: The header by which the signer can only identify the campaign.
	"xarf". Default is "arf", and multiple values may be separated by a		If present, the report generator may use the hp header instead of the
	comma (,). If a report sender is unable to generate a report in a		h header if the recipient needs to remain private and there is no
			expectation of future sending to the recipient to be suppressed.
			This field is OPTIONAL, and MUST contain only one attribute.
			f: Format requested by report receiver. Options are "arf" or "xarf".
			Default is "arf", and multiple values may be separated by a comma
			(,). If a report sender is unable to generate a report in a
	requested format, they SHOULD NOT send a report.		requested format, they SHOULD NOT send a report.
	4.1. Samples		4.1. Examples
	_feedback._domainkey.example.org TXT		_feedback._domainkey.example.org TXT
	"v=DKIMRFBLv1;ra=reporting@feedback.example.org"		"v=DKIMRFBLv1;ra=mailto://reporting@feedback.example.org"
	contact._feedback._domainkey.example.org TXT		contact._feedback._domainkey.example.org TXT
	"v=DKIMRFBLv1;rfr=_feedback._domainkey.example.org"		"v=DKIMRFBLv1;rfr=_feedback._domainkey.example.org"
	contact._feedback._domainkey.example.org TXT		contact._feedback._domainkey.example.org TXT
	"v=DKIMRFBLv1;ra=fbl@example.org;rfr=_feedback._domainkey.example.org		"v=DKIMRFBLv1;ra=mailto://fbl@example.org;rfr=_feedback._domainkey.ex
	"		ample.org"
	*._feedback._domainkey.example.org TXT		*._feedback._domainkey.example.org TXT
	"v=DKIMRFBLv1;ra=other_fbl@example.org"		"v=DKIMRFBLv1;ra=mailto://other_fbl@example.org"
	RFC draft-brotman-dkim-fbl-01 DKIM-FBL October 2023		_feedback._domainkey.example.org TXT
			"v=DKIMRFBLv1;c=n;ra=https://ra.example.org/
			reports;h=SendingIdentifer" (https://ra.example.org/
			reports;h=SendingIdentifer")
	5. Report Contents		5. Report Contents
			5.1. arf
	When the report format is specified as "arf", the report contents		When the report format is specified as "arf", the report contents
	should adhere to [RFC5965].		should adhere to [RFC5965]
			5.2. xarf
	When the report format is chosen as "xarf" [XARF], the report		When the report format is chosen as "xarf" [XARF], the report
	generator should reference the materials below as to the format.		generator should reference the materials below as to the format.
	XARF follows a JSON format and the format may change over time to		XARF follows a JSON format and the format may change over time to
	match that specification.		match that specification.
	The current format can be referenced:		The current format can be referenced:
	https://github.com/abusix/xarf/blob/master/schemas/3/spam.schema.json		https://github.com/abusix/xarf/blob/master/schemas/3/spam.schema.json
	(https://github.com/abusix/xarf/blob/master/schemas/3/		(https://github.com/abusix/xarf/blob/master/schemas/3/
	spam.schema.json)		spam.schema.json)
	6. Verifying External Destinations		5.3. Aggregate FBL Reports
			A reporting entity may desire to send only aggregate data for a given
			time period, and that report may not contain any content of the
			original messages. When this is the case, the reporter should
			utilize the hp field in the DNS declaration to be used as the value
			by which the sender will be able to recognize the message stream.
			The hp field MUST be signed by the corresponding DKIM signature, and
			that signature must validate. As a message may be signed by multiple
			signatures, it's possible that there could be multiple headers match
			an hp definition.
			5.3.1. Report Format
			NOTE: This could be created as an XARF, TBD
			<feedback>
			<report_metadata>
			<date_range>
			<begin>15141231</begin>
			<end>15152525</end>
			<date_range>
			<report_id>20231212-favw3ra34vwa3ra</report_id>
			<selector>dkim_sel</selector>
			<domain>dkim_domain</domain>
			<feedback_header>HeaderName</feedback_header>
			<header_contents>123:c21vRA3-V3A</header_contents>
			</report_metadata>
			<record>
			<row>
			<source_ip>1.2.3.4</source_ip>
			<fn_complaints>3</fn_complaints>
			</row>
			</record>
			</feedback>
			6. Content Flag
			Some DKIM signers may prefer that they only receive headers from a
			reporter. The reporter SHOULD attempt to adhere to those wishes of
			the signer. In a situation where c=n and h has a value, the report
			generator would send a report with only that single header. if the
			'hp' tag has a value then the report generator MAY use that value
			instead of the 'h' tag if the recipient's privacy needs to be
			preserved at the expense of future sending possibly not being
			suppressed to that address.
			7. Delivery Methods
			Reports MUST be sent to the address specified by the "ra" tag.
			7.1. mailto
			Refer to [RFC5965]
			7.2. https
			A DKIM signer may specify that they wish to receive reports via
			HTTPS. When doing so, the reporter should continue to use the format
			specifed by the rest of the declaration.
			The report generator SHOULD follow redirects.
			The HTTP method MUST be POST.
			HTTP GET requests to the URL MUST provide easy to follow instructions
			for users to report complaints.
			The report generator SHOULD NOT remove parameters from the URL before
			submitting the report unless the 'hp' tag is specified. If the 'hp'
			tag is specified then the parameters can be removed if the report
			generator needs to preserve the privacy of the recipient at the
			expense of the report not causing suppressed sending to that
			recipient in the future.
			DNS record
			v=DKIMRFBLv1;c=n;ra=https://ra.example.org/dkim-
			fbl?track=xzy;h=Message-Id;hp=Feedback-Id (https://ra.example.org/
			dkim-fbl?track=xzy;h=Message-Id;hp=Feedback-Id)
			Header in Email
			DKIM-FBL: https://ra.example.com/reports (https://ra.example.com/
			reports) Message-Id: opaque@example.com Feedback-Id: opaque
			Resulting POST request
			POST /dkim-fbl?optional=opaquePart HTTP/1.1 Host: ra.example.com
			Content-Type: application/x-www-form-urlencoded Feedback-Type: abuse
			Content-Length: 26
			... NEED examples of each: arf and xarf to provide the 'h' or 'hp'
			7.2.1. https Feedback-Type Header
			A reporter MAY include a HTTP header that denotes which report type
			is being delivered. If used, the header MUST be titled "Feedback-
			Type", and adhere to the definition referenced in [RFC5965] section
			7.3 or the associated IANA declarations. If this header is absent,
			the Feedback-Type MUST be considered "abuse".
			8. Verifying External Destinations
	In order to limit the possibility of misdirected reports, if the		In order to limit the possibility of misdirected reports, if the
	receiving entity domain does not match the d= of the DKIM signature,		receiving entity domain does not align to the d= of the DKIM
	there must be a DNS record to verify the external destination.		signature, there must be a DNS record to verify the external
			destination.
			Domain alignment is determined by the logic defined by [DMARCbis].
			Domain alignment applies to domain of the email address in the 'rua'
			tag if the 'f' tag is 'arf' or 'xarf'. Domain alignment applies to
			the domain defined in the URI of the header referenced by the 'rua'
			tag if the 'f' tag is 'https'
	Consider the record:		Consider the record:
	foo._feedback._domainkey.example.org TXT		foo._feedback._domainkey.example.org TXT
	"v=DKIMRFBLv1 ; ra=reporting@othersite.com"		"v=DKIMRFBLv1;ra=mailto://reporting@othersite.com"
	In order for "othersite.com" to receive reports for this DKIM		In order for "othersite.com" to receive reports for this DKIM
	signature, a record must exist at specified location, and contain a		signature, a record must exist at specified location, and contain a
	specified value.		specified value.
	1. Using the domain of the destination		1. Using the domain of the destination
	2. Prepend "_report._feedback"		2. Prepend "_report._feedback"
	3. Prepend the values from d= and s= from the original signature.		3. Prepend the values from d= and s= from the original signature.
	4. Ensure the value is set to "v=DKIMRFBLv1"		4. Ensure the value is set to "v=DKIMRFBLv1"
	foo.example.org._report._feedback.othersite.com TXT "v=DKIMRFBLv1"		foo.example.org._report._feedback.othersite.com TXT "v=DKIMRFBLv1"
	If the feedback receiver is comfortable with receiving feedback for		If the feedback receiver is comfortable with receiving feedback for
	all selectors within a domain, then they may omit the s= value from		all selectors within a domain, then they may omit the s= value from
	the DNS record location. The record would be named:		the DNS record location. The record would be named:
	example.org._report._feedback.othersite.com TXT "v=DKIMRFBLv1"		example.org._report._feedback.othersite.com TXT "v=DKIMRFBLv1"
	7. Security Considerations		9. Security Considerations
	RFC draft-brotman-dkim-fbl-01 DKIM-FBL October 2023
	7.1. Feedback to Malicious Senders		9.1. Feedback to Malicious Senders
	There is some concern that a MBP may provide some advantage or useful		There is some concern that a MBP may provide some advantage or useful
	information to a malicious entity by providing them with FBL data.		information to a malicious entity by providing them with FBL data.
	Each MBP should use their own judgement when deciding where to send		Each MBP should use their own judgement when deciding where to send
	reports. It is possible that an attacker could use this information		reports. It is possible that an attacker could use this information
	to attempt to bypass anti-spam filters, or to validate a recipient at		to attempt to bypass anti-spam filters, or to validate a recipient at
	a given site.		a given site.
	7.2. Report Contents for ARF		9.2. Report Contents for ARF
	Noting in [RFC5965] section 2.g, there should be enough information		Noting in [RFC5965] section 2.g, there should be enough information
	for most senders to process a complaint without the content of the		for most senders to process a complaint without the content of the
	message. While the c flag allows the report receiver to state that		message. While the c flag allows the report receiver to state that
	they do not wish to receive content, the report generator, as per		they do not wish to receive content, the report generator, as per
	[RFC5965] does not need to include that information, regardless of		[RFC5965] does not need to include that information, regardless of
	the flag settings.		the flag settings.
	8. Other Considerations		10. Other Considerations
	8.1. Supplying FP Reports		10.1. Supplying FP Reports
	It is at the discretion of the report generator as to whether they		It is at the discretion of the report generator as to whether they
	supply False Positive reports to the report requester.		supply False Positive reports to the report requester.
	8.2. Site Requirements		10.2. Site Requirements
	A report generator may place some requirements on the sender in order		A report generator may place some requirements on the sender in order
	to be eligible to receive reports. This could include something such		to be eligible to receive reports. This could include something such
	as a DMARC policy requirements, TLS usage, or some level of		as a DMARC policy requirements, TLS usage, or some level of
	reputation.		reputation.
	8.3. Report Delivery		11. Contributors
	In this document, only delivery via SMTP is specified. However, a
	separate document could be created to allow for feedback via HTTPS,
	UDP, or something yet to be defined.
	9. Contributors		12. Notes
	10. Notes		13. References
	11. References		[DMARCbis] https://datatracker.ietf.org/doc/draft-ietf-dmarc-
			dmarcbis/ (https://datatracker.ietf.org/doc/draft-ietf-dmarc-
			dmarcbis/)
	12. Normative References		14. Normative References
	RFC draft-brotman-dkim-fbl-01 DKIM-FBL October 2023
	[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,		[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
	DOI 10.17487/RFC5321, October 2008,		DOI 10.17487/RFC5321, October 2008,
	<https://www.rfc-editor.org/info/rfc5321>.		<https://www.rfc-editor.org/info/rfc5321>.
	[RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An		[RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An
	Extensible Format for Email Feedback Reports", RFC 5965,		Extensible Format for Email Feedback Reports", RFC 5965,
	DOI 10.17487/RFC5965, August 2010,		DOI 10.17487/RFC5965, August 2010,
	<https://www.rfc-editor.org/info/rfc5965>.		<https://www.rfc-editor.org/info/rfc5965>.
End of changes. 47 change blocks.
	83 lines changed or deleted		209 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/