rfc9091xml2.original.xml		rfc9091.xml
	<?xml version="1.0" encoding="US-ASCII"?>		<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<?rfc toc="yes"?>
	<?rfc sortrefs="yes"?>
	<?rfc symrefs="yes"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<rfc category="exp"		<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	docName="draft-ietf-dmarc-psd-15"
	ipr="trust200902">
	<front>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-dmarc-psd-14
	<title abbrev="PSD DMARC">Experimental DMARC Extension For Public Suffix Doma		" number="9091" ipr="trust200902" obsoletes="" updates="" submissionType="IETF"
	ins		category="exp" consensus="true" xml:lang="en" tocInclude="true" sortRefs="true"
	</title>		symRefs="true" version="3">
	<author initials="S." surname="Kitterman"		<front>
	fullname="Scott Kitterman">		<title abbrev="PSD DMARC">Experimental Domain-Based Message
			Authentication, Reporting, and Conformance (DMARC) Extension for Public
			Suffix Domains
			</title>
			<seriesInfo name="RFC" value="9091"/>
			<author initials="S." surname="Kitterman" fullname="Scott Kitterman">
	<organization>fTLD Registry Services</organization>		<organization>fTLD Registry Services</organization>
	<address>		<address>
	<postal>		<postal>
	<street>600 13th Street, NW, Suite 400</street>		<extaddr>Suite 400</extaddr>
	<city>Washington</city>		<street>600 13th Street, NW</street>
	<region>DC</region>		<city>Washington</city>
	<code>20005</code>		<region>DC</region>
	<country>United States of America</country>		<code>20005</code>
	</postal>		<country>United States of America</country>
			</postal>
	<phone>+1 301 325-5475</phone>		<phone>+1 301 325-5475</phone>
	<email>scott@kitterman.com</email>		<email>scott@kitterman.com</email>
	</address>		</address>
	</author>		</author>
			<author role="editor" initials="T." surname="Wicinski" fullname="Tim Wicinsk
	<author role="editor" initials="T." surname="Wicinski" fullname="Tim Wicinski"		i">
	>		<organization/>
	<organization></organization>		<address>
	<address>		<postal>
	<postal>		<street/>
	<street></street>		<city>Elkins</city>
	<city>Elkins</city>		<code>26241</code>
	<code>26241</code>		<country>United States of America</country>
	<country>USA</country>		<region>WV</region>
	<region>WV</region>		</postal>
	</postal>		<phone/>
	<phone></phone>		<email>tjw.ietf@gmail.com</email>
	<email>tjw.ietf@gmail.com</email>		<uri/>
	<uri></uri>		</address>
	</address>		</author>
	</author>		<date month="July" year="2021"/>
			<keyword>DMARC</keyword>
	<date month="June" year="2021" />		<keyword>email authentication</keyword>
			<keyword>TLD</keyword>
	<keyword>DMARC</keyword>		<abstract>
	<keyword>email authentication</keyword>
	<keyword>TLD</keyword>
	<abstract>
	<t>Domain-based Message Authentication, Reporting, and Conformance		<t>Domain-based Message Authentication, Reporting, and Conformance
	(DMARC) permits a domain-controlling organization to express		(DMARC), defined in RFC 7489, permits a domain-controlling organization to express
	domain-level policies and preferences for message validation,		domain-level policies and preferences for message validation,
	disposition, and reporting, which a mail-receiving organization		disposition, and reporting, which a mail-receiving organization
	can use to improve mail handling.</t>		can use to improve mail handling.</t>
	<t>DMARC distinguishes the portion of a name that is a		<t>DMARC distinguishes the portion of a name that is a
	Public Suffix Domain (PSD), below which		Public Suffix Domain (PSD), below which
	organizational domain names are created. The basic DMARC		Organizational Domain names are created. The basic DMARC
	capability allows organizational domains to specify policies		capability allows Organizational Domains to specify policies
	that apply to their subdomains, but it does not give that		that apply to their subdomains, but it does not give that
	capability to PSDs. This document describes an extension to		capability to PSDs. This document describes an extension to
	DMARC to fully enable DMARC functionality for PSDs.</t>		DMARC to fully enable DMARC functionality for PSDs.</t>
	<t>Some implementations of DMARC consider a PSD to be ineligible for		<t>Some implementations of DMARC consider a PSD to be ineligible for
	DMARC enforcement. This specification addresses that case.</t>		DMARC enforcement. This specification addresses that case.</t>
			</abstract>
	</abstract>		</front>
	</front>		<middle>
			<section anchor="intro" numbered="true" toc="default">
	<middle>		<name>Introduction</name>
	<section anchor="intro" title="Introduction">		<t>DMARC <xref target="RFC7489" format="default"/> provides a mechanism fo
	<t>DMARC <xref target="RFC7489"/> provides a mechanism for publishing		r publishing
	organizational policy information to email receivers. DMARC allows poli cy to be		organizational policy information to email receivers. DMARC allows poli cy to be
	specified for both individual domains and for organizational domains		specified for both individual domains and for Organizational Domains
	and their sub-domains within a single organization.</t>		and their subdomains within a single organization.</t>
	<t>To determine the organizational domain for a message under evaluation,		<t>To determine the Organizational Domain for a message under
	and thus where to look for a policy statement, DMARC makes use of a publ		evaluation, and thus where to look for a policy statement, DMARC makes
	ic suffix		use of a public suffix list. The process for doing this can be found in
	list. The process for doing this can be found in Section 3.2 of the DMAR		<xref target="RFC7489" sectionFormat="of" section="3.2">the DMARC
	C		specification</xref>. Currently, the most common public suffix list being
	specification. Currently, the public suffix list being used is the		used is the
	most common one that is maintained by the Mozilla Foundation and made pu		one maintained by the Mozilla Foundation and made public at <eref brackets
	blic at		="angle"
	<eref target="http://publicsuffix.org">http://publicsuffix.org</eref>.</		target="https://publicsuffix.org"/>.</t>
	t>		<t>In the basic DMARC model, Public Suffix Domains (PSDs) are not Organiza
	<t>In the basic DMARC model, Public Suffix Domains (PSDs) are not organizat		tional Domains
	ional domains
	and are thus not subject to DMARC processing. In DMARC, domains		and are thus not subject to DMARC processing. In DMARC, domains
	fall into one of three categories: organizational domains,		fall into one of three categories: Organizational Domains,
	sub-domains of organizational domains, or PSDs. A PSD can only		subdomains of Organizational Domains, or PSDs. A PSD can only
	publish DMARC policy for itself, and not for any sub-domains		publish DMARC policy for itself and not for any subdomains
	under it. In some cases, this limitation allows for the abuse		under it. In some cases, this limitation allows for the abuse
	of non-existent organizational-level domains and hampers		of non-existent organizational-level domains and hampers
	identification of domain abuse in email.</t>		identification of domain abuse in email.</t>
	<t>This document specifies experimental updates to the DMARC		<t>This document specifies experimental updates to the DMARC
	specification cited above, in an attempt to mitigate this abuse.</t>		specification <xref target="RFC7489" format="default"/> in an attempt to
	<section anchor="example" title="Example">		mitigate this abuse.</t>
	<t>As an example, imagine a Top-Level Domain (TLD), ".example", that has		<section anchor="example" numbered="true" toc="default">
			<name>Example</name>
			<t>As an example, imagine a Top-Level Domain (TLD), ".example", that has
	public subdomains for government and commercial use (".gov.example"		public subdomains for government and commercial use (".gov.example"
	and ".com.example"). The maintainer of a list of such a PSD structure		and ".com.example"). The maintainer of a list of such a PSD structure
	would include entries for both of these sub-domains, thereby		would include entries for both of these subdomains, thereby
	indicating that they are PSDs, below which organizational domains can		indicating that they are PSDs, below which Organizational Domains can
	be registered. Suppose further that there exists a legitimate domain		be registered. Suppose further that there exists a legitimate domain
	called "tax.gov.example", registered within ".gov.example".</t>		called "tax.gov.example", registered within ".gov.example".</t>
	<t>However, by exploiting the typically unauthenticated nature		<t>By exploiting the typically unauthenticated nature of email, there ar
	of email, there are regular malicious campaigns to impersonate this		e
	organization that use similar-looking ("cousin") domains such as		regular malicious campaigns to impersonate this organization that use
	"t4x.gov.example". Such domains are not registered.</t>		similar-looking ("cousin") domains such as "t4x.gov.example". Such
	<t>Within the ".gov.example" public suffix, use of DMARC has been mandated,		domains are not registered.</t>
			<t>Within the ".gov.example" public suffix, use of DMARC has been mandat
			ed,
	so "gov.example" publishes the following DMARC DNS record:		so "gov.example" publishes the following DMARC DNS record:
	<figure><artwork>		</t>
			<sourcecode><![CDATA[
	_dmarc.gov.example. IN TXT ( "v=DMARC1; p=reject;"		_dmarc.gov.example. IN TXT ( "v=DMARC1; p=reject;"
	"rua=mailto:dmc@dmarc.svc.gov.example" )		"rua=mailto:dmc@dmarc.svc.gov.example" )
	</artwork></figure>		]]></sourcecode>
			<t>
	This DMARC record provides policy and a reporting destination for		This DMARC record provides policy and a reporting destination for
	mail sent from @gov.example. Similarly, "tax.gov.example" will have		mail sent from @gov.example. Similarly, "tax.gov.example" will have
	a DMARC record that specifies policy for mail sent from addresses		a DMARC record that specifies policy for mail sent from addresses
	@tax.gov.example. However, due to DMARC's current method of		@tax.gov.example. However, due to DMARC's current method of
	discovering and applying policy at the organizational domain		discovering and applying policy at the Organizational Domain
	level, the non-existent organizational domain of @t4x.gov.example		level, the non-existent Organizational Domain of @t4x.gov.example
	does not and cannot fall under a DMARC policy.		does not and cannot fall under a DMARC policy.
	</t>		</t>
	<t> Defensively registering all variants of "tax" is not a scalable		<t> Defensively registering all variants of "tax" is not a scalable
	strategy. The intent of this specification, therefore, is to enhance t he		strategy. The intent of this specification, therefore, is to enhance t he
	DMARC discovery method by enabling an agent receiving such a		DMARC discovery method by enabling an agent receiving such a
	message to be able to determine that a relevant policy is present at		message to be able to determine that a relevant policy is present at
	"gov.example", which is precluded by the current DMARC specification.		"gov.example", which is precluded by the current DMARC specification.
	</t>		</t>
	</section>		</section>
	<section anchor="discussion" title="Discussion">		<section anchor="discussion" numbered="true" toc="default">
	<t> This document provides a simple extension to <xref target="RFC7489"/>		<name>Discussion</name>
			<t> This document provides a simple extension to <xref target="RFC7489"
			format="default"/>
	to allow operators of Public Suffix Domains (PSDs) to:		to allow operators of Public Suffix Domains (PSDs) to:
	<list style="symbols">		</t>
	<t>Express policy at the level of the PSD that covers all
	organizational domains that do not explicitly publish DMARC records</t		<ul spacing="normal">
	>		<li>Express policy at the level of the PSD that covers all
	<t>Extends the DMARC policy query functionality to detect		Organizational Domains that do not explicitly publish DMARC records</l
	and process such a policy</t>		i>
	<t>Describes receiver feedback for such policies</t>		<li>Extend the DMARC policy query functionality to detect
	<t>Provides controls to mitigate potential privacy considerations		and process such a policy</li>
	associated with this extension</t>		<li>Describe receiver feedback for such policies</li>
	</list>		<li>Provide controls to mitigate potential privacy considerations
	</t>		associated with this extension</li>
	<t>This document also provides a new DMARC tag		</ul>
			<t>This document also provides a new DMARC tag
	to indicate requested handling policy for non-existent subdomains.		to indicate requested handling policy for non-existent subdomains.
	This is provided specifically to support phased deployment of PSD		This is provided specifically to support phased deployment of PSD
	DMARC, but is expected to be useful more generally. Undesired		DMARC but is expected to be useful more generally. Undesired
	rejection risks for mail purporting to be from domains that do not		rejection risks for mail purporting to be from domains that do not
	exist are substantially lower than for those that do, so the		exist are substantially lower than for those that do, so the
	operational risk of requesting harsh policy treatment (e.g., reject) is		operational risk of requesting harsh policy treatment (e.g., reject) is
	lower.		lower.
	</t>		</t>
	<t>As an additional benefit, the PSD DMARC extension clarifies		<t>As an additional benefit, the PSD DMARC extension clarifies
	existing requirements. Based on the requirements of <xref		existing requirements. Based on the requirements of <xref
	target="RFC7489"/>, DMARC should function above the		target="RFC7489" format="default"/>, DMARC should function above the
	organizational level for exact domain matches (i.e., if a DMARC record		organizational level for exact domain matches (i.e., if a DMARC record
	were published for "example", then mail from example@example should be		were published for "example", then mail from example@example should be
	subject to DMARC processing). Testing had revealed that this is not		subject to DMARC processing). Testing has revealed that this is not
	consistently applied in different implementations.		consistently applied in different implementations.
	</t>		</t>
	<t>There are two types of Public Suffix Operators (PSOs) for which this		<t>There are two types of Public Suffix Operators (PSOs) for which this
	extension would be useful and appropriate:		extension would be useful and appropriate:
	</t>		</t>
	<t><list style="symbols">
	<t>Branded PSDs (e.g., ".google"): These domains are
	effectively Organizational Domains as discussed in <xref
	target="RFC7489"/>. They control all
	subdomains of the tree. These are effectively private
	domains, but listed in the current public suffix list.
	They are
	treated as Public for DMARC
	purposes. They require the same protections as DMARC
	Organizational Domains, but are currently unable to
	benefit from DMARC.
	</t>
	<t>Multi-organization PSDs that require DMARC usage (e.g.,
	".bank"): Because existing Organizational Domains using
	this PSD have their own DMARC policy, the applicability of
	this extension is for non-existent domains. The extension
	allows the brand protection benefits of DMARC to extend to
	the entire PSD,
	including cousin domains of registered organizations.
	</t>
	</list></t>
	<t>Due to the design of DMARC and the nature
	of the Internet <xref target="RFC5598">email architecture</xref>, there
	are interoperability issues associated with
	DMARC deployment. These are discussed in <xref target="RFC7960">
	Interoperability Issues between DMARC and Indirect Email Flows</xref>.
	These issues are not typically applicable to PSDs, since they (e.g., th
	e
	".gov.example" used above) do not typically send mail.
	</t>
	</section>		<dl newline="true">
			<dt>Branded PSDs (e.g., ".google"):
			</dt>
			<dd>These domains are effectively Organizational Domains as discussed in <xref
			target="RFC7489" format="default"/>. They control all subdomains of the
			tree. These are effectively private domains but listed in the current public
			suffix list. They are treated as public for DMARC purposes. They require the
			same protections as DMARC Organizational Domains but are currently unable to
			benefit from DMARC.
			</dd>
			<dt>Multi-organization PSDs that require DMARC usage (e.g., ".bank"):
			</dt>
			<dd>Because existing Organizational Domains using this PSD have their own
			DMARC policy, the applicability of this extension is for non-existent
			domains. The extension allows the brand protection benefits of DMARC to extend
			to the entire PSD, including cousin domains of registered organizations.
			</dd>
			</dl>
			<t>Due to the design of DMARC and the nature of the Internet <xref
			target="RFC5598" format="default">email architecture</xref>, there are
			interoperability issues associated with DMARC deployment. These are
			discussed in "Interoperability Issues between Domain-based Message
			Authentication, Reporting, and Conformance (DMARC) and Indirect Email
			Flows" <xref target="RFC7960" format="default"/>. These issues are
			not typically applicable to PSDs since they (e.g., the ".gov.example"
			used above) do not typically send mail.
			</t>
	</section>		</section>
			</section>
			<section numbered="true" toc="default">
			<name>Terminology and Definitions</name>
	<section title="Terminology and Definitions">		<t>This section defines terms used in the rest of the document.
	<t>This section defines terms used in the rest of the document.		</t>
	</t>		<section numbered="true" toc="default">
	<section title="Conventions Used in This Document">		<name>Conventions Used in This Document</name>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",		<t>
	"MAY", and "OPTIONAL" in this document are to be interpreted as		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	described in BCP&nbsp;14 <xref target="RFC2119"/>		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	<xref target="RFC8174"/> when, and only when, they appear in all		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	capitals, as shown here.		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	</t>		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
	</section>		to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
	<section title="Public Suffix Domain (PSD)">		<xref target="RFC8174"/> when, and only when, they appear in all capitals,
	<t> The global Internet Domain Name System (DNS) is documented in		as shown here.
			</t>
			</section>
			<section numbered="true" toc="default">
			<name>Public Suffix Domain (PSD)</name>
			<t> The global Internet Domain Name System (DNS) is documented in
	numerous RFCs. It defines a tree of names		numerous RFCs. It defines a tree of names
	starting with root, ".", immediately below which are Top Level		starting with root, ".", immediately below which are Top-Level
	Domain names such as ".com" and ".us".		Domain names such as ".com" and ".us".
	The domain name structure consists of a tree of names, each of		The domain name structure consists of a tree of names, each of
	which is made of a sequence of words ("labels") separated by		which is made of a sequence of words ("labels") separated by
	period characters. The root of the tree is simply called ".".		period characters. The root of the tree is simply called ".".
	The Internet community at large, through processes and policies		The Internet community at large, through processes and policies
	external to this work, selects points in this tree at which to		external to this work, selects points in this tree at which to
	register domain names "owned" by independent organizations.		register domain names "owned" by independent organizations.
	Real-world examples are ".com", ".org", ".us", and ".gov.uk".		Real-world examples are ".com", ".org", ".us", and ".gov.uk".
	Names at which such registrations occur are called Public		Names at which such registrations occur are called "Public
	Suffix Domains (PSDs), and a registration consists of a label		Suffix Domains (PSDs)", and a registration consists of a label
	selected by the registrant to which a desirable PSD is		selected by the registrant to which a desirable PSD is
	appended. For example, "ietf.org" is a registered domain name,		appended. For example, "ietf.org" is a registered domain name,
	and ".org" is its PSD.		and ".org" is its PSD.
	</t>		</t>
	</section>		</section>
	<section title="Organizational Domain">		<section numbered="true" toc="default">
	<t> The term Organizational Domains is defined in <xref		<name>Organizational Domain</name>
	target="RFC7489"/> Section 3.2.</t>		<t> The term "Organizational Domain" is defined in <xref target="RFC7489
	</section>		" sectionFormat="of" section="3.2" format="default"/>.</t>
	<section anchor="lpsd" title="Longest PSD">		</section>
	<t> The longest PSD is the Organizational Domain with one label		<section anchor="lpsd" numbered="true" toc="default">
			<name>Longest PSD</name>
			<t> The longest PSD is the Organizational Domain with one label
	removed. It names the immediate parent node of the Organizational		removed. It names the immediate parent node of the Organizational
	Domain in the DNS namespace tree.</t>		Domain in the DNS namespace tree.</t>
	</section>		</section>
	<section title="Public Suffix Operator (PSO)">		<section numbered="true" toc="default">
	<t>A Public Suffix Operator is an organization which manages		<name>Public Suffix Operator (PSO)</name>
			<t>A Public Suffix Operator is an organization that manages
	operations within a PSD, particularly the DNS records published		operations within a PSD, particularly the DNS records published
	for names at and under that domain name.		for names at and under that domain name.
	</t>		</t>
	</section>		</section>
	<section title="PSO Controlled Domain Names">
	<t>PSO Controlled Domain Names are names in the DNS that are		<section numbered="true" toc="default">
			<name>PSO-Controlled Domain Names</name>
			<t>PSO-Controlled Domain Names are names in the DNS that are
	managed by a PSO and are not available for use as Organizational		managed by a PSO and are not available for use as Organizational
	Domains. PSO Controlled Domain Names may have one (e.g., ".com")		Domains. PSO-Controlled Domain Names may have one (e.g., ".com")
	or more (e.g., ".co.uk") name components, depending on PSD policy .		or more (e.g., ".co.uk") name components, depending on PSD policy .
	</t>		</t>
	</section>		</section>
	<section title="Non-existent Domains">
	<t>For DMARC purposes, a non-existent
	domain is a domain for which there is an NXDOMAIN or NODATA
	response for A, AAAA, and MX records. This is a broader definition
	than that in <xref target="RFC8020"/>.
	</t>
	</section>
	</section>
	<section title="PSD DMARC Updates to DMARC Requirements">		<section numbered="true" toc="default">
			<name>Non-existent Domains</name>
			<t>For DMARC purposes, a non-existent domain is a domain for which
			there is an NXDOMAIN or NODATA response for A, AAAA, and MX records.
			This is a broader definition than that in <xref target="RFC8020"
			format="default"/>.
			</t>
			</section>
			</section>
			<section numbered="true" toc="default">
			<name>PSD DMARC Updates to DMARC Requirements</name>
	<t>To participate in this experiment, implementations should		<t>To participate in this experiment, implementations should interpret
	interpret RFC7489 as follows:</t>		<xref target="RFC7489"/> as described in the following subsections.</t>
			<section numbered="true" toc="default">
			<name>General Updates</name>
			<t>References to "Domain Owners" also apply to PSOs.</t>
			</section>
			<section anchor="genrecfmt" numbered="true" toc="default">
			<name>Changes in Section 6.3 ("General Record Format")</name>
			<t>The following paragraph is added to this section. A new tag is
			added after "fo":</t>
			<blockquote>
			<dl newline="false" spacing="normal">
			<dt>np:</dt>
			<dd> Requested Mail Receiver policy for non-existent subdomains
			(plain-text; <bcp14>OPTIONAL</bcp14>). Indicates the policy to be
			enacted by the Receiver at the request of the Domain Owner. It
			applies only to non-existent subdomains of the domain queried and
			not to either existing subdomains or the domain itself. Its syntax
			is identical to that of the "p" tag defined below. If the "np" tag
			is absent, the policy specified by the "sp" tag (if the "sp" tag is
			present) or the policy specified by the "p" tag (if the "sp" tag is
			absent) <bcp14>MUST</bcp14> be applied for non-existent subdomains.
			Note that "np" will be ignored for DMARC records published on
			subdomains of Organizational Domains and PSDs due to the effect of
			the DMARC policy discovery mechanism described in <xref
			target="RFC7489" sectionFormat="of" section="6.6.3"></xref>.
			</dd>
	<section title="General Updates">		</dl>
	<t>References to "Domain Owners" also apply to PSOs.</t>		</blockquote>
	</section>
	<section anchor="genrecfmt" title='Changes in Section 6.3 "General Record F		<t>The following tag definitions from DMARC are updated:
	ormat"'>		</t>
	<t>If this experiment is successful, this paragraph is added to this sec
	tion.		<dl newline="false" spacing="normal">
	A new tag is added after "fo":</t>		<dt>p:</dt>
	<t><list style="hanging">		<dd>The sentence 'Policy applies to the domain queried and to
	<t hangText="np:"> Requested Mail Receiver policy for non-existent		subdomains, unless subdomain policy is explicitly described using
	subdomains (plain-text; OPTIONAL). Indicates the policy to be		the "sp" tag' is updated to read 'Policy applies to the domain
	enacted by the Receiver at the request of the Domain Owner. It		queried and to subdomains, unless subdomain policy is explicitly
	applies only to non-existent subdomains of the domain queried and		described using the "sp" or "np" tags.'
	not to either existing subdomains or the domain itself. Its		</dd>
	syntax is identical to that of the "p" tag defined below. If		<dt>sp:</dt>
	the "np" tag is absent, the policy specified by the "sp" tag (if		<dd>The sentence 'If absent, the policy specified by the "p" tag
	the "sp" tag is present) or the policy specified by the "p" tag,		<bcp14>MUST</bcp14> be applied for subdomains' is updated to read
	if the "sp" tag is not present, MUST be applied for non-existent		'If both the "sp" tag is absent and the "np" tag is either absent or
	subdomains. Note that "np" will be ignored for DMARC records		not applicable, the policy specified by the "p" tag
	published on subdomains of Organizational Domains and PSDs due to		<bcp14>MUST</bcp14> be applied for subdomains.'
	the effect of the DMARC policy discovery mechanism described in		</dd>
	DMARC Section 6.6.3.		</dl>
	</t>
	</list></t>		</section>
	<t>The following tag definitions from DMARC
	are updated:		<section>
	</t>		<name>Changes in Section 6.4 ("Formal Definition")</name>
	<t><list style="hanging">		<t>The ABNF <xref target="RFC5234"/> for DMARC is updated to include a new
	<t hangText="p:">The sentence 'Policy applies to the domain queried		definition,
	and to subdomains, unless subdomain policy is explicitly described		"dmarc-nprequest": </t>
	using the "sp" tag' is updated to read 'Policy applies to the domai		<sourcecode type="abnf"><![CDATA[
	n
	queried and to subdomains, unless subdomain policy is explicitly
	described using the "sp" or "np" tags.'
	</t>
	<t hangText="sp:">The sentence 'If absent, the policy specified by
	the "p" tag MUST be applied for subdomains' is updated to read
	'If both the "sp" tag is absent and the "np" tag is either absent
	or not applicable, the policy specified by the "p" tag MUST be
	applied for subdomains.
	</t>
	</list></t>
	</section>
	<section title='Changes in Section 6.4 "Formal Definition"'>
	<t>The ABNF for DMARC shall updated to include a new definition
	"dmarc-nprequest" which is defined as:
	<figure><artwork>
	dmarc-nprequest = "np" *WSP "=" *WSP		dmarc-nprequest = "np" *WSP "=" *WSP
	( "none" / "quarantine" / "reject" )		( "none" / "quarantine" / "reject" )
			]]></sourcecode>
	</artwork></figure>		<t> The "dmarc-record" definition is also updated to include the follow
	The "dmarc-record" definition is also updated to include the following		ing:</t>
	:		<sourcecode><![CDATA[
	<figure><artwork>		dmarc-record = dmarc-version dmarc-sep
			[dmarc-request]
			[dmarc-sep dmarc-srequest]
			[dmarc-sep dmarc-auri]
			[dmarc-sep dmarc-furi]
			[dmarc-sep dmarc-adkim]
			[dmarc-sep dmarc-aspf]
			[dmarc-sep dmarc-ainterval]
			[dmarc-sep dmarc-fo]
			[dmarc-sep dmarc-rfmt]
			[dmarc-sep dmarc-percent]
			[dmarc-sep]
	[dmarc-sep dmarc-nprequest]		[dmarc-sep dmarc-nprequest]
	</artwork></figure>		; components other than dmarc-version and
	</t>		; dmarc-request may appear in any order
	</section>		]]></sourcecode>
	<section title='Changes in Section 6.5 "Domain Owner Actions"'>
	<t>In addition to the DMARC domain owner actions, PSOs that require		</section>
	use of DMARC and participate in PSD DMARC ought to make that		<section numbered="true" toc="default">
	information available to receivers. This document is an experime		<name>Changes in Section 6.5 ("Domain Owner Actions")</name>
	ntal		<t>In addition to the DMARC Domain Owner actions, PSOs that require
	mechanism for doing so. See the [this document] <xref		use of DMARC and participate in PSD DMARC ought to make that
	target="experiment">experiment description</xref>.		information available to receivers. This document is an experimental
	</t>		mechanism for doing so; see the description in <xref
	</section>		target="registry" format="default"/>.
	<section title='Changes in Section 6.6.1 "Extract Author Domain"'>		</t>
	<t> Experience with DMARC has shown that some implementations		</section>
	short-circuit messages, bypassing DMARC policy application, when		<section numbered="true" toc="default">
	the domain name extracted by the receiver (from the RFC5322.From)		<name>Changes in Section 6.6.1 ("Extract Author Domain")</name>
	is on the public suffix list used by the receiver. This		<t> Experience with DMARC has shown that some implementations
	negates the capability being created by this specification.		short-circuit messages, bypassing DMARC policy application, when the
	Therefore, the following paragraph is appended to Section 6.6.1		domain name extracted by the receiver (from the RFC5322.From domain) is
	of DMARC:		on
	</t>		the public suffix list used by the receiver. This negates the
	<t> Note that domain names that appear on a public suffix list are		capability being created by this specification. Therefore, the
			following paragraph is appended to <xref target="RFC7489"
			sectionFormat="of" section="6.6.1">the DMARC
			specification</xref>:
			</t>
			<blockquote>
			Note that domain names that appear on a public suffix list are
	not exempt from DMARC policy application and reporting.		not exempt from DMARC policy application and reporting.
	</t>		</blockquote>
	</section>		</section>
	<section anchor="poldis" title='Changes in Section 6.6.3 "Policy Discovery"		<section anchor="poldis" numbered="true" toc="default">
	'>		<name>Changes in Section 6.6.3 ("Policy Discovery")</name>
	<t>A new step between step 3 and 4 is added:</t>		<t>A new step is added between steps 3 and 4:</t>
	<t><list style="hanging">
	<t hangText="3A.">If the set is now empty and the <xref
	target="lpsd">longest PSD</xref> of the Organizational
	Domain is one that the receiver has determined is acceptable
	for PSD DMARC (discussed in the [this document] <xref
	target="experiment">experiment description</xref>), the Mail
	Receiver MUST query the DNS for a DMARC TXT record at the DNS
	domain matching the [this document] <xref target="lpsd">
	longest PSD</xref> in
	place of the RFC5322.From domain in the message (if
	different). A possibly empty set of records is returned.
	</t>
	</list> </t>
	<t>As an example, for a message with the Organizational Domain of
	"example.compute.cloudcompany.com.example", the query for PSD DMARC
	would use "compute.cloudcompany.com.example" as the [this document]
	<xref
	target="lpsd">longest PSD</xref>. The receiver would check to see
	if that PSD is listed in the DMARC PSD Registry, and if so, perform
	the policy lookup at "_dmarc.compute.cloudcompany.com.example".
	</t>
	<t>Note: Because the PSD policy query comes after the Organizational
	Domain policy query, PSD policy is not used for Organizational
	domains that have published a DMARC policy. Specifically, this
	is not a mechanism to provide feedback addresses (RUA/RUF) when
	an Organizational Domain has declined to do so.
	</t>
	</section>
	<section title='Changes in Section 7 "DMARC Feedback"'>
	<t>If this experiment is successful, this paragraph is added to this se
	ction.</t>
	<t> Operational note for PSD DMARC: For PSOs, feedback for non-existent
	domains is desirable and useful, just as it is for org-level
	DMARC operators. See <xref target="privacy"/> of [this document] fo
	r
	discussion of Privacy Considerations for PSD DMARC.
	</t>
	</section>
	</section>
	<section anchor="privacy" title="Privacy Considerations">		<blockquote>
			<dl newline="false" spacing="normal">
			<dt>3A.</dt>
			<dd>If the set is now empty and the longest PSD ([RFC9091], <xref targ
			et="lpsd"
			format="default"></xref>) of the Organizational Domain is
			one that the receiver has determined is acceptable for PSD DMARC
			(based on the data in one of the DMARC PSD Registry Examples described
			in <xref target="registry" format="default"></xref> of [RFC9091]), the
			Mail Receiver <bcp14>MUST</bcp14> query the DNS for a DMARC TXT record
			at the DNS domain matching the longest PSD in place of the RFC5322.Fr
			om
			domain in the message (if different). A possibly empty set of
			records is returned.
			</dd>
			</dl>
			</blockquote>
			<t>As an example, for a message with the Organizational Domain of
			"example.compute.cloudcompany.com.example", the query for PSD DMARC
			would use "compute.cloudcompany.com.example" as the
			longest PSD. The receiver
			would check to see if that PSD is listed in the DMARC PSD Registry,
			and if so, perform the policy lookup at
			"_dmarc.compute.cloudcompany.com.example".
			</t>
			<t indent="3">Note: Because the PSD policy query comes after the Organiz
			ational
			Domain policy query, PSD policy is not used for Organizational Domains
			that have published a DMARC policy. Specifically, this is not a
			mechanism to provide feedback addresses (RUA/RUF) when an
			Organizational Domain has declined to do so.
			</t>
			</section>
			<section numbered="true" toc="default">
			<name>Changes in Section 7 ("DMARC Feedback")</name>
			<t>The following paragraph is added to this section:</t>
			<blockquote>
			<t> Operational note for PSD DMARC: For PSOs, feedback for
			non-existent domains is desirable and useful, just as it is for
			org-level DMARC operators. See <xref target="privacy"
			format="default"/> of [RFC9091] for discussion of privacy
			considerations for PSD DMARC.
			</t>
			</blockquote>
			</section>
			</section>
			<section anchor="privacy" numbered="true" toc="default">
			<name>Privacy Considerations</name>
	<t>These privacy considerations are developed based on the requirements of		<t>These privacy considerations are developed based on the requirements of
	<xref target="RFC6973"/>.		<xref target="RFC6973" format="default"/>.
	Additionally, the Privacy Considerations of <xref target="RFC7489"/>		Additionally, the privacy considerations of <xref target="RFC7489" for
			mat="default"/>
	apply to the mechanisms described by this document.		apply to the mechanisms described by this document.
	If this experiment is successful, this section should be		To participate in this experiment, implementations should be aware of
	incorporated into the Privacy Considerations section as "Feedback leak		the privacy considerations described in this section. If this
	age".		experiment is successful, this section should be incorporated into th
			e
			"Privacy Considerations" section as "Feedback Leakage".
	</t>		</t>
	<t>Providing feedback reporting to PSOs can, in some cases, cause		<t>Providing feedback reporting to PSOs can, in some cases, cause
	information to leak out of an organization to the PSO.		information to leak out of an organization to the PSO.
	This leakage could potentially be utilized as part of a program		This leakage could potentially be utilized as part of a program
	of pervasive surveillance (See <xref target="RFC7624"/>). There		of pervasive surveillance (see <xref target="RFC7624" form
	are roughly three cases to consider:		at="default"/>). There
	</t>		are roughly three cases to consider:
	<t><list style="symbols">		</t>
	<t>Single Organization PSDs (e.g., ".google"), RUA and RUF		<dl newline="true">
	reports based on PSD DMARC have the potential to contain
	information about emails related to entities managed by		<dt>Single Organization PSDs (e.g., ".google"):
	the organization. Since both the PSO and the		</dt>
	Organizational Domain owners are common, there is no		<dd>RUA and RUF reports based on PSD DMARC have the potential to contain
	additional privacy risk for either normal or non-existent		information about emails related to entities managed by the organization.
	Domain reporting due to PSD DMARC.		Since both the PSO and the Organizational Domain Owners are common, there is
	</t>		no additional privacy risk for either normal or non-existent domain reporting
	<t>Multi-organization PSDs that require DMARC usage (e.g.,		due to PSD DMARC.
	".bank"): PSD DMARC based reports will only be generated		</dd>
	for domains that do not publish a DMARC policy at the
	organizational or host level. For domains that do publish		<dt>Multi-organization PSDs that require DMARC usage (e.g., ".bank"):
	the required DMARC policy records, the feedback reporting		</dt>
	addresses (RUA and RUF) of the organization (or hosts)		<dd>Reports based on PSD DMARC will only be generated for domains that do not
	will be used. The only direct feedback leakage risk for		publish a DMARC policy at the organizational or host level. For domains that
	these PSDs are for Organizational Domains that are out of		do publish the required DMARC policy records, the feedback reporting addresses
	compliance with PSD policy. Data on non-existent cousin		(RUA and RUF) of the organization (or hosts) will be used. The only direct
	domains would be sent to the PSO.		risk of feedback leakage for these PSDs are for Organizational Domains that are
	</t>		out of compliance with PSD policy. Data on non-existent cousin domains would
	<t>Multi-organization PSDs (e.g., ".com") that do not mandate		be sent to the PSO.
	DMARC usage: Privacy risks for Organizational Domains		</dd>
	that have not deployed DMARC within such PSDs are
	significant. For non-DMARC Organizational Domains, all		<dt>Multi-organization PSDs (e.g., ".com") that do not mandate DMARC usage:
	DMARC feedback will be directed to the PSO. PSD DMARC is		</dt>
	opt-out (by publishing a DMARC record at the		<dd>Privacy risks for Organizational Domains that have not deployed DMARC
	Organizational Domain level) instead of opt-in, which would		within such PSDs are significant. For non-DMARC Organizational Domains, all
	be		DMARC feedback will be directed to the PSO. PSD DMARC is opt out (by
	the more desirable characteristic. This means that any		publishing a DMARC record at the Organizational Domain level) instead of
	non-DMARC organizational domain would have its feedback		opt in, which would be the more desirable characteristic. This means that any
	reports redirected to the PSO. The content of such		non-DMARC Organizational Domain would have its Feedback Reports redirected to
	reports, particularly for existing domains, is privacy		the PSO. The content of such reports, particularly for existing domains, is
	sensitive.		privacy sensitive.
	</t>		</dd>
	</list></t>
	<t>PSOs will receive feedback on non-existent domains, which may be		</dl>
	similar to existing Organizational Domains. Feedback related to
	such cousin domains have a small risk of carrying information		<t>PSOs will receive feedback on non-existent domains, which may be similar
	related to an actual Organizational Domain. To minimize		to existing Organizational Domains. Feedback related to such cousin domains
	this potential concern, PSD DMARC feedback MUST be limited		have a small risk of carrying information related to an actual
	to Aggregate Reports. Feedback Reports carry more detailed		Organizational Domain. To minimize this potential concern, PSD DMARC
	information and present a greater risk.		feedback <bcp14>MUST</bcp14> be limited to Aggregate Reports. Feedback
	</t>		Reports carry more detailed information and present a greater risk.
	<t>Due to the inherent Privacy and Security risks associated with		</t>
	PSD DMARC for Organizational Domains in multi-organization PSDs		<t>Due to the inherent privacy and security risks associated with
	that do not participate in DMARC, any Feedback Reporting		PSD DMARC for Organizational Domains in multi-organization PSDs
	related to multi-organizational PSDs MUST be limited		that do not participate in DMARC, any feedback reporting
			related to multi-organizational PSDs <bcp14>MUST</bcp14> be limited
	to non-existent domains		to non-existent domains
	except in cases where the reporter knows that PSO		except in cases where the reporter knows that PSO
	requires use of DMARC (by checking the DMARC PSD Registry).		requires use of DMARC (by checking the DMARC PSD Registry).
	</t>
	</section>
	<section title="Security Considerations">
	<t> This document does not change the Security Considerations of
	<xref target="RFC7489"/> and <xref target="RFC7960"/>.
	</t>		</t>
	<t> The risks of the issues identified in <xref target="RFC7489"/>,		</section>
	Section 12.3, DNS Security, are amplified by PSD DMARC. In		<section numbered="true" toc="default">
	particular, DNS cache poisoning (or Name Chaining), see <xref		<name>Security Considerations</name>
	target="RFC3833"/> for details, consequences are increased because a		<t> This document does not change the security considerations of
	successful attack would potentially have a much wider scope.		<xref target="RFC7489" format="default"/> and <xref target="RFC7960" f
			ormat="default"/>.
	</t>		</t>
	<t> The risks of the issues identified in <xref target="RFC7489"/>,		<t> The risks of the issues identified in <xref target="RFC7489"
	Section 12.5, External Reporting Addresses, are amplified by PSD		sectionFormat="of" section="12.3" format="default"/> ("DNS Security") are
	DMARC. By design, PSD DMARC causes unrequested reporting of feedback		amplified by PSD DMARC. In particular, consequences of DNS cache poisonin
	to entities external to the Organizational Domain. This is discussed		g (or name
	in more detail in <xref target="privacy"/>.		chaining) are increased because a successful attack would potentially
			have a much wider scope (see <xref target="RFC3833" format="default"/>
			for details).
	</t>		</t>
	</section>		<t> The risks of the issues identified in <xref target="RFC7489"
			sectionFormat="of" section="12.5" format="default"/> ("External Reporting
	<section anchor="iana" title="IANA Considerations">		Addresses") are amplified by PSD DMARC. By design, PSD DMARC causes
	<t>This section describes actions requested to be completed by IANA.</t>		unrequested reporting of feedback to entities external to the
			Organizational Domain. This is discussed in more detail in <xref
			target="privacy" format="default"/>.
			</t>
			</section>
			<section anchor="iana" numbered="true" toc="default">
			<name>IANA Considerations</name>
	<section anchor="iana1" title="Subdomain Policy Tag">		<t>IANA has added a new tag to the "DMARC Tag Registry" in the
	<t>IANA is requested to add a new tag to DMARC Tag Registry in the Do		"Domain-based Message Authentication, Reporting, and Conformance
	main-based Message Authentication,		(DMARC) Parameters" registry. The "Status" column is defined in <xref
	Reporting, and Conformance (DMARC) Parameters Registry. The "Stat		target="RFC7489" sectionFormat="of" section="11.4" format="default"/>.
	us" column is		</t>
	defined in <xref target="RFC7489"/>Section 11.4.		<t>The new entry is as follows:
	</t>		</t>
	<t>The entry is as follows:
	<figure><artwork>
	+----------+-----------+---------+-------------------------------+
	| Tag Name | Reference | Status | Description |
	+----------+-----------+---------+-------------------------------+
	| np | this | current | Requested handling policy for |
	| | document | | non-existent subdomains |
	+----------+-----------+---------+-------------------------------+
	</artwork> </figure>
	[RFC EDITOR: Please replace "This document" with the RFC number of this docume
	nt.]
	</t>
	</section>
	</section>
	</middle>
	<back>		<table anchor="table_1">
	<references title="Normative References">		<name></name>
	<?rfc include="reference.RFC.2119" ?>		<thead>
	<?rfc include="reference.RFC.7489" ?>		<tr>
	<?rfc include="reference.RFC.8174" ?>		<th>Tag Name</th>
	</references>		<th>Reference</th>
			<th>Status</th>
			<th>Description</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td>np</td>
			<td>RFC 9091</td>
			<td>current</td>
			<td>Requested handling policy for non-existent subdomains</td>
			</tr>
	<references title="Informative References">		</tbody>
	<?rfc include="reference.RFC.3833" ?>		</table>
	<?rfc include="reference.RFC.8126" ?>
	<?rfc include="reference.RFC.5598" ?>
	<?rfc include="reference.RFC.6973" ?>
	<?rfc include="reference.RFC.7624" ?>
	<?rfc include="reference.RFC.7960" ?>
	<?rfc include="reference.RFC.8020" ?>
	<reference anchor="psddmarc.org" target="https://psddmarc.org/">
	<front>
	<title>PSD DMARC Web Site</title>
	<author>
	<organization>multiple</organization>
	</author>
	<date month="April" year="2019" />
	</front>
	</reference>
	</references>		<t>
	<section anchor="experiment"		</t>
	title="PSD DMARC Privacy Concern Mitigation Experiment">		</section>
			</middle>
			<back>
			<references>
			<name>References</name>
			<references>
			<name>Normative References</name>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.2119.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.7489.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8174.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.5234.xml"/>
			</references>
			<references>
			<name>Informative References</name>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.3833.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8126.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.5598.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.6973.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.7624.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.7960.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8020.xml"/>
	<t>The experiment being performed has three different questions which are		<reference anchor="PSD-DMARC" target="https://psddmarc.org/">
	looking to be addressed in this document. </t>		<front>
	<t><list style="symbols">		<title>Public Suffix Domain DMARC</title>
			<author>
			</author>
			</front>
			</reference>
			</references>
			</references>
			<section anchor="experiment" numbered="true" toc="default">
			<name>PSD DMARC Privacy Concern Mitigation Experiment</name>
			<t>The experiment being performed has three different questions that are
			looking to be addressed in this document. </t>
			<ul spacing="normal">
			<li><xref target="genrecfmt"/> modifies policy discovery to add an
			additional DNS lookup. To determine if this lookup is useful, PSDs
			will add additional DMARC records in place and will analyze the DMARC
			reports. Success will be determined if a consensus of PSDs that
			publish DMARC records are able to collect useful data.</li>
			<li><xref target="genrecfmt"/> adds the "np" tag for non-existent
			subdomains (DNS NXDOMAIN). PSOs wishing to test this will add this
			flag to their DMARC record and will analyze DMARC reports for
			deployment. Success will be determined if organizations find
			explicitly blocking non-existent subdomains desirable and that doing
			so provides added value. </li>
			<li><xref target="privacy"/> discusses three cases where providing
			feedback could cause information to leak out of an organization. This
			experiment will analyze the Feedback Reports generated for each case
			to determine if there is information leakage.</li>
			</ul>
	<t>Section 3.2 modifies policy discovery to add an additional DNS lookup.		</section>
	To determine if this lookup is useful, PSDs will add additional DMARC record		<section anchor="registry" numbered="true" toc="default">
	s		<name>DMARC PSD Registry Examples</name>
	in place, and will analyze the DMARC reports. Success will be determined		<t>To facilitate experimentation around mitigation of data leakage, sample
	if a consensus of PSDs that publish DMARC records are able to collect useful		s
	data.</t>		of the DNS-based and IANA-like registries are available at <xref
	<t>Section 3.2 adds the "np" tag for non-existent subdomains (DNS NXDOMAIN).		target="PSD-DMARC" format="default"/>.
	PSOs wishing to test this will add this flag to their DMARC record, and will		</t>
	analyze DMARC reports for deployment. Success will be determined if		<section anchor="dnsregistry" numbered="true" toc="default">
	organizations find explicitly blocking non-existent subdomains domains		<name>DMARC PSD DNS Query Service</name>
	desirable and provide added value. </t>		<t> A sample stand-alone DNS query service is available at <xref
	<t> Section 4.1 discusses three cases where providing feedback could cause		target="PSD-DMARC" format="default"/>. It was developed based on the
	information to leak out of an organization. This experiment will analyze		contents suggested for an IANA registry in an earlier draft version of t
	the feedback reports generated for each case to determine if there is		his
	information leakage.</t>		document. Usage of the service is described at <xref
	</list></t>		target="PSD-DMARC" format="default"/>.
			</t>
			</section>
	</section>		<section anchor="iana2" numbered="true" toc="default">
	<section anchor="registry" title="DMARC PSD Registry Examples">		<name>DMARC PSD Registry</name>
	<t> To facilitate experimentation around data leakage mitigation, samp		<t> <xref target="PSD-DMARC" format="default"/> provides an IANA-like
	les		DMARC Public Suffix Domain (PSD) Registry as a stand-alone DNS query
	of the DNS based and IANA like registries are available at		service. It follows the contents and structure described below.
	<xref target="psddmarc.org"/>.		There is a Comma-Separated Value (CSV) version of the listed PSDs
	</t>		that is suitable for use in build updates for PSD DMARC-capable software
	<section anchor="dnsregistry" title="DMARC PSD DNS Query Service">		.
	<t> A sample stand-alone DNS query service is available at <xref		</t>
	target="psddmarc.org"/>. It was developed based on the contents		<t>PSDs that are deploying DMARC and are participating in PSD DMARC
	suggested for an IANA registry in an earlier revision of this draf
	t.
	Usage of the service is described on the web site.
	</t>
	</section>
	<section anchor="iana2" title="DMARC Public Suffix Domain (PSD) Registry
	">
	<t> <xref target="psddmarc.org"/> provides an IANA like DMARC Public
	Suffix Domain (PSD) Registry as a stand-alone DNS query service.
	It
	follows the contents and structure described below. There is a Co
	mma
	Separated Value (CSV) version of the listed PSD domains which is
	suitable for use in build updates for PSD DMARC capable software.
	</t>
	<t>PSDs that are deploying DMARC and are participating in PSD DMARC
	must register their public suffix domain in this		must register their public suffix domain in this
	new registry. The requirement has to be documented in a		new registry. The requirement has to be documented in a
	manner that satisfies the terms of Expert Review, per <xref		manner that satisfies the terms of Expert Review, per <
	target="RFC8126"/>. The Designated Expert needs to confirm that		xref target="RFC8126" format="default"/>. The Designated Expert needs to confir
	provided documentation adequately describes PSD policy to require		m that
	domain owners to use DMARC or that all domain owners are part of		provided documentation adequately describes PSD
	a single organization with the PSO.		policy to require
	</t>		Domain Owners to use DMARC or that all Do
	<t>The initial set of entries in this registry is as follows:		main Owners are part of
	<figure><artwork>		a single organization with the PSO
	+-------------+---------------+		.
	| PSD | Status |		</t>
	+-------------+---------------+		<t>The authoritative registry can be found here:
	| .bank | current |		<eref brackets="angle" target="https://psddmarc.org"/></t>
	+-------------+---------------+
	| .insurance | current |		</section>
	+-------------+---------------+		<section anchor="pslplus" numbered="true" toc="default">
	| .gov.uk | current |		<name>DMARC PSD PSL Extension</name>
	+-------------+---------------+		<t> <xref target="PSD-DMARC" format="default"/> provides a file formatte
	| .mil | current |		d like the
	+-------------+---------------+
	</artwork> </figure>
	</t>
	</section>
	<section anchor="pslplus" title="DMARC PSD PSL Extension">
	<t> <xref target="psddmarc.org"/> provides a file formatted like the
	Public Suffix List (PSL) in order to		Public Suffix List (PSL) in order to
	facilitate identification of PSD DMARC participants. Contents ar e		facilitate identification of PSD DMARC participants. Contents ar e
	functionally identical to the IANA like registry, but presented i n		functionally identical to the IANA-like registry but presented in
	a different format.		a different format.
	</t>		</t>
	<t> When using this approach, the input domain of the extension lookup		<t> When using this approach, the input domain of the extension lookup
	is supposed to be the output domain of the regular PSL lookup, i. e.,		is supposed to be the output domain of the regular PSL lookup, i. e.,
	the organizational domain. This alternative data approach is		the Organizational Domain. This alternative data approach is
	potentially useful since DMARC implementations already need to be		potentially useful since DMARC implementations already need to be
	able to parse the data format, so it should be easier to implemen t.		able to parse the data format, so it should be easier to implemen t.
	</t>		</t>
	</section>		</section>
	</section>		</section>
			<section anchor="implementations" numbered="true" toc="default">
	<section anchor="implementations" title="Implementations">		<name>Implementations</name>
	<t> There are two known implementations of PSD DMARC available for testing .		<t> There are two known implementations of PSD DMARC available for testing .
	</t>		</t>
	<section title="Authheaders Module">		<section numbered="true" toc="default">
	<t>The authheaders Python module and command line tool is available		<name>Authheaders Module</name>
			<t>The authheaders Python module and command line tool is available
	for download or installation from Pypi (Python Packaging Index).		for download or installation from Pypi (Python Packaging Index).
	</t>		</t>
	<t>It supports both use of the DNS based query service and download		<t>It supports both use of the DNS-based query service and download
	of the CSV registry file from <xref target="psddmarc.org"/>.		of the CSV registry file from <xref target="PSD-DMARC" format="defaul
	</t>		t"/>.
			</t>
	</section>		</section>
	<section title="Zdkimfilter Module">		<section numbered="true" toc="default">
	<t>The zdkimfilter module is a separately available add-on to		<name>Zdkimfilter Module</name>
			<t>The zdkimfilter module is a separately available add-on to
	Courier-MTA.		Courier-MTA.
	</t>		</t>
	<t>Mostly used for DKIM signing, it can be configured to also verify,		<t>Mostly used for DomainKeys Identified Mail (DKIM) signing, it can
	apply DMARC policies, and send aggregate reports. For PSD DMARC		be configured to also verify, apply DMARC policies, and send Aggregate
	it uses the PSL extension list approach, which is available		Reports. For PSD DMARC, it uses the PSL extension list approach, which
	from <xref target="psddmarc.org"/>		is available from <xref target="PSD-DMARC" format="default"/>.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="thanks" title="Acknowledgements" numbered="no">		<section anchor="thanks" numbered="false" toc="default">
			<name>Acknowledgements</name>
	<t> Thanks to the following individuals for their contributions (both		<t> Thanks to the following individuals for their contributions (both
	public and private) to improving this document. Special shout out to		public and private) to improving this document:
	Dave Crocker for naming the beast.</t>		<contact fullname="Kurt Andersen"/>, <contact fullname="Seth
	<t> Kurt Andersen, Seth Blank, Dave Crocker, Heather Diaz, Tim Draegen,		Blank"/>, <contact fullname="Dave Crocker"/>, <contact fullname="Heather
	Zeke Hendrickson, Andrew Kennedy, John Levine, Dr Ian Levy, Craig		Diaz"/>, <contact fullname="Tim Draegen"/>, <contact fullname="Zeke
	Schwartz, Alessandro Vesely, and Tim Wicinski</t>		Hendrickson"/>, <contact fullname="Andrew Kennedy"/>, <contact
			fullname="John Levine"/>, <contact fullname="Dr. Ian Levy"/>, <contact
			fullname="Craig Schwartz"/>, <contact fullname="Alessandro Vesely"/>,
			and <contact fullname="Tim Wicinski"/>.</t>
			<t>A special mention to
			<contact fullname="Dave Crocker"/> for coming up with the name.</t>
	</section>		</section>
	</back>
			</back>
	</rfc>		</rfc>
End of changes. 71 change blocks.
	547 lines changed or deleted		636 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/