Diff: rfc8904xml2.original.xml

	rfc8904xml2.original.xml	rfc8904.xml

	<?xml version="1.0" encoding="US-ASCII" ?>	<?xml version="1.0" encoding="UTF-8"?>
	<!-- This template is for creating an Internet Draft using xml2rfc,
	which is available here: http://xml.resource.org. -->

	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!ENTITY RFC1034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.1034.xml">
	<!ENTITY RFC2606 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.2606.xml">
	<!ENTITY RFC3225 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.3225.xml">
	<!ENTITY RFC3629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.3629.xml">
	<!ENTITY RFC4033 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.4033.xml">
	<!ENTITY RFC4880 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.4880.xml">
	<!ENTITY RFC5198 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5198.xml">
	<!ENTITY RFC5598 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5598.xml">
	<!ENTITY RFC5782 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5782.xml">
	<!ENTITY RFC6376 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.6376.xml">
	<!ENTITY RFC6530 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.6530.xml">
	<!ENTITY RFC6762 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.6762.xml">
	<!ENTITY RFC7208 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.7208.xml">
	<!ENTITY RFC7489 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.7489.xml">
	<!ENTITY RFC8460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8460.xml">
	<!ENTITY RFC8482 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8482.xml">
	<!ENTITY RFC8601 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8601.xml">
	]>
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<!-- used by XSLT processors -->
	<!-- For a complete list and description of processing instructions (PIs),
	please see http://xml.resource.org/authoring/README.html. -->
	<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
	might want to use.
	(Here they are set differently than their defaults in xml2rfc v1.32) -->
	<?rfc strict="yes" ?>
	<!-- give errors regarding ID-nits and DTD validation -->
	<!-- control the table of contents (ToC) -->
	<?rfc toc="yes"?>
	<!-- generate a ToC -->
	<?rfc tocdepth="4"?>
	<!-- the number of levels of subsections in ToC. default: 3 -->
	<!-- control references -->
	<?rfc symrefs="yes"?>
	<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
	<?rfc sortrefs="no" ?>
	<!-- sort the reference entries alphabetically -->
	<!-- control vertical white space
	(using these PIs as follows is recommended by the RFC Editor)
	was: compact="yes" -->
	<?rfc compact="no" ?>
	<!-- do not start each main section on a new page -->
	<?rfc subcompact="yes" ?>
	<!-- keep one blank line between list items -->
	<!-- end of list of popular I-D processing instructions -->

	<rfc submissionType="independent" docName="draft-vesely-authmethod-dnswl-16" cat
	egory="info" ipr="trust200902">


	<!-- category values: std, bcp, info, exp, and historic	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	ipr values: trust200902, full3667, noModification3667, noDerivatives3667
	you can add the attributes updates="NNNN" and obsoletes="NNNN"
	they will automatically be output with "(if approved)" -->


	<!-- *** FRONT MATTER *** -->	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="independent"
		category="info" docName="draft-vesely-authmethod-dnswl-16" number="8904"
		ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true"
		tocDepth="4" symRefs="true" sortRefs="false" version="3">

	<front>	<front>

	<!-- The abbreviated title is used in the page header - it is only necess
	ary if the
	full title is longer than 39 characters -->

	<title abbrev="DNSWL email-auth-method extension">DNSWL Email Authenticat
	ion Method Extension</title>

	<!-- add 'role="editor"' below for the editors if appropriate -->

	<!-- Another author who claims to be an editor -->

	<author fullname="Alessandro Vesely" initials="A." surname="Vesely">
	<organization/>

	<address>
	<postal>
	<street>v. L. Anelli 13</street>

	<!-- Reorder these if your country does things differently -->

	<code>20122</code>
	<city>Milano</city>
	<region>MI</region>
	<country>IT</country>
	</postal>

	<email>vesely@tana.it</email>

	<!-- uri and facsimile elements may also be added -->
	</address>
	</author>

	<date month="April" year="2020" />


	<!-- If the month and year are both specified and are the current ones, x	<title abbrev="DNSWL Email Auth Method Extension">DNS Whitelist
	ml2rfc will fill	(DNSWL) Email Authentication Method Extension</title>
	in the current day for you. If only the current year is specified
	, xml2rfc will fill
	in the current day and month for you. If the year is not the curr
	ent one, it is
	necessary to specify at least a month (xml2rfc assumes day="1" if
	not specified for the
	purpose of calculating the expiry date). With drafts it is norma
	lly sufficient to
	specify just the year. -->

	<!-- Meta-data Declarations -->

	<area>General</area>


	<workgroup>IETF</workgroup>	<seriesInfo name="RFC" value="8904"/>


	<!-- WG name at the upperleft corner of the doc,	<author fullname="Alessandro Vesely" initials="A." surname="Vesely">
	IETF is fine for individual submissions.	<organization/>
	If this element is not present, the default is "Network Working G	<address>
	roup",	<postal>
	which is used by the RFC Editor as a nod to the history of the IE	<street>v. L. Anelli 13</street>
	TF. -->	<code>20122</code>
		<city>Milano</city>
		<region>MI</region>
		<country>Italy</country>
		</postal>
		<email>vesely@tana.it</email>
		</address>
		</author>
		<date month="September" year="2020"/>


	<keyword>DNSWL</keyword>	<area>General</area>
	<keyword>EMAIL</keyword>	<workgroup>IETF</workgroup>
	<keyword>Authentication-Results</keyword>	<keyword>DNSWL</keyword>
		<keyword>EMAIL</keyword>
		<keyword>Authentication-Results</keyword>


	<!-- Keywords will be incorporated into HTML output	<abstract>
	files in a meta tag but they have no effect on text or nroff
	output. If you submit your draft to the RFC Editor, the
	keywords will be used for the search engine. -->


	<abstract>	<t>
	<t>	This document describes an email authentication method compliant
	This document describes an additional Email Authentication Method	with RFC 8601. The method consists of looking up the sender's IP address in a
	compliant with RFC 8601.	DNS whitelist. This document provides information in case the method is seen
	The method consists in looking up the sender's IP address in a	in the field, suggests a useful practice, and registers the
	DNS whitelist.	relevant keywords.
	This document is provided for information in case the method	</t>
	is seen in the field, as well as to suggest a useful practice	<t>
	and register the relevant keywords.	This document does not consider blacklists.
	</t>	</t>
	<t>	</abstract>
	This document does not consider black lists.
	</t>
	</abstract>
	</front>	</front>

		<middle>
		<section numbered="true" toc="default">
		<name>Introduction</name>
		<t>
		One of the many checks that mail servers carry out is to query DNS
		whitelists (DNSWLs).
		That method is fully discussed in <xref target="RFC5782"
		format="default"/>.
		The DNS <xref target="RFC1034" format="default"/> lookup is based on
		the connecting
		client's IP address, IPv4 or IPv6, and returns zero or more A records.
		The latter are IPv4 IP addresses in the range 127.0.0.0/8. Depending
		on
		the query, TXT records with varying content can also be retrieved.
		Query examples are given in <xref target="example" format="default"/>.
		</t>
		<t>
		Since the IP address is known as soon as the connection is accepted,
		this check can occur very early in an SMTP transaction.
		Its result can be used to counterweight policies that typically
		occur at early stages too, such as the Sender Policy Framework
		(SPF) (the last paragraph of <xref target="RFC7208"
		sectionFormat="of" section="D.3"/> is also illustrated in
		<xref target="example" format="default"/>).
		In addition, the result of a DNSWL
		lookup can be used at later stages; for example, a delivery
		agent can use it to learn the trustworthiness of a mail relay in
		order to estimate the spamminess of an email message.
		The latter possibility needs a place to collect query results for
		downstream use, which is precisely what the Authentication-Results
		header field aims to provide.
		</t>
		<t>
		Results often contain additional data, encoded according to
		DNSWL-specific criteria. The method described in this document
		considers only whitelists -- one of the major branches described by
		<xref target="RFC5782" format="default"/>. There are also
		blacklists/blocklists (DNSBLs) and combined lists. Since they all have
		the same structure, the abbreviation DNSxL is used to mean any. The
		core procedures of a Mail Transfer Agent (MTA) tend to be quite
		general, leaving particular cases to be handled by add-on modules. In
		the case of combined lists, the boundary MTA (see <xref
		target="RFC5598" format="default"/>), which carries out the check and
		possibly stores the result, has to be able to discern at least the
		color of each entry, as that is required to make accept/reject
		decisions. This document provides for storing the result when the
		DNSxL record to be reported is a whitelisting one.
		</t>


	<middle>	<t>
	<section title="Introduction">	Data conveyed in A and TXT records can be stored as properties
	<t>	of the method. The meaning of such data varies widely at the mercy
	One of the many checks that mail servers carry out is to query do	of the list operator; hence, the queried zone has to be stored as
	main	well.
	name system whitelists (DNSWL).	Mail site operators who configure their MTAs to query specific
	That method is fully discussed in <xref target="RFC5782"/>.	DNWSLs marry the policies of those lists, as, in effect, they
	The DNS <xref target="RFC1034"/> lookup is based on the connectin	become tantamount to local policies, albeit outsourced.
	g
	client's IP address, IPv4 or IPv6, and returns zero or more A rec
	ords.
	The latter are IPv4 IP addresses in the range 127.0.0.0/8. Depen
	ding on
	the query, TXT records with varying content can also be retrieved
	.
	Query examples are given in <xref target="example"/>.
	</t>
	<t>
	Since the IP address is known as soon as the connection is accept
	ed,
	this check can occur very early in an SMTP transaction.
	Its result can be used to counterweight policies that typically
	occur at early stages too, such as the Sender Policy Framework
	(SPF, the last paragraph of Appendix D.3 of
	<xref target="RFC7208"/> is also illustrated in <xref target="exa
	mple"/>).
	In addition, the result of a DNSWL
	lookup can also be used at later stages; for example, a delivery
	agent can use it to learn the trustworthiness of a mail relay in
	order to estimate the spamminess of an email message.
	The latter possibility needs a place to collect query results for
	downstream use, which is precisely what the Authentication-Result
	s
	header field aims at providing.
	</t>
	<t>
	Results often contain additional data, encoded according to
	DNSWL-specific criteria. The method described in this document
	considers only whitelists --one of the major branches described
	by <xref target="RFC5782"/>. There are also black/block lists,
	DNSBL, and combined lists. Since they all have the same structur
	e,
	the abbreviation DNSxL is used to mean any.
	The core procedures of a mail transfer agent (MTA)
	tend to be quite general, leaving particular cases to be
	handled by add-on modules. In the case of combined lists,
	the boundary MTA (see <xref target="RFC5598"/>) which carries
	out the check and possibly stores the result has to be able to
	discern at least the color of each entry, as that is required to
	make accept/reject decisions.
	This document provides for storing the result when the DNSxL
	record to be reported is a whitelisting one.
	</t>
	<t>
	Data conveyed in A and TXT records can be stored as method's
	properties. The meaning of such data varies widely at the mercy
	of the list operator, hence the queried zone has to be stored as
	well.
	Mail site operators who configure their MTAs to query specific
	DNWSLs marry the policies of those lists, as, in effect, they
	become tantamount to local policies, albeit outsourced. Downstre
	am
	agents who know DNSWL-specific encoding and understand the
	meaning of that datum can use it to make delivery or display
	decisions. For example, a mail filter which detected heuristic
	evidence of a scam can counterweight such information with the
	trustworthiness score encoded in the A response, so as to
	protect agains false positives. MUAs can display those results,
	or use them to decide how to report abusive messages, if
	configured to do so.
	</t>
	<t>
	This document describes a usage of
	TXT fields consistent with other authentication methods,
	namely to serve the domain name in the TXT record. That way,
	a downstream filter could also consider whether the sending agent
	is aligned with the author domain, with semantics similar to
	<xref target="RFC7489"/>.
	</t>
	<t>
	At the time of this writing, this method is implemented by
	<xref target="Courier-MTA"/>. An outline of the implementation
	is given in <xref target="implement"/>.
	</t>
	</section>

	<section title="Method Details" anchor="mresults">
	<t>
	The result of the method states how the query did, up to the
	interpretation of the returned data.
	</t>

	<t>
	The method has four possible results:


	<list style="hanging" hangIndent="12">	Downstream agents who know DNSWL-specific encoding and understand the meaning
	<t hangText="pass:">	of that data can use it to make delivery or display decisions. For example,
	The query successfully returned applicable record	a mail filter that detects heuristic evidence of a scam can counterweight such
	s.	information with the trustworthiness score encoded in the A response so as to
	This result is usually accompanied by one or both	protect against false positives. Mail User Agents (MUAs) can display those
	of the	results or use them to decide how to report abusive messages, if configured to
	policy properties described below.	do so.
	Since the list is configured as a DNSWL, agents u	</t>
	nable	<t>
	to interpret list-specifc properties can still	This document describes a usage of
	derive a positive value from the fact that the se	TXT fields consistent with other authentication methods,
	nder	namely to serve the domain name in the TXT record. That way,
	is whitelisted.	a downstream filter could also consider whether the sending agent
	</t>	is aligned with the author domain, with semantics similar to
		<xref target="RFC7489" format="default"/>.
		</t>


	<t hangText="none:">	<t>
	The query worked but yielded no A record, or retu	At the time of this writing, this method is implemented by Courier-MTA
	rned	<xref target="Courier-MTA" format="default"/>. An outline of the
	NXDOMAIN, so the sender is not whitelisted.	implementation
	</t>	is given in <xref target="implement" format="default"/>.
		</t>
		</section>
		<section anchor="mresults" numbered="true" toc="default">
		<name>Method Details</name>
		<t>
		The result of the method states how the query did, up to the
		interpretation of the returned data.
		</t>
		<t>
		The method has four possible results:


	<t hangText="temperror:">	</t>
	The DNS evaluation could not be completed due to	<dl newline="false" indent="13">
	some	<dt>pass:</dt>
	error that is likely transient in nature, such as a temporary DNS	<dd>
	error, e.g., a DNS RCODE of 2, commonly known as SERVFAIL, or	The query successfully returned applicable
	other error condition. A later attempt may produce a	records. This result is usually accompanied
	final result.	by one or both of the policy properties
	</t>	described below. Since the list is configured
		as a DNSWL, agents unable to interpret
		list-specific properties can still derive a
		positive value from the fact that the sender
		is whitelisted.
		</dd>
		<dt>none:</dt>
		<dd>
		The query worked but yielded no A record or returned
		NXDOMAIN, so the sender is not whitelisted.
		</dd>
		<dt>temperror:</dt>
		<dd>
		The DNS evaluation could not be completed due to some
		error that is likely transient in nature, such as a temporary DNS
		error (e.g., a DNS RCODE of 2, commonly known as SERVFAIL) or
		other error condition. A later attempt may produce a
		final result.
		</dd>
		<dt>permerror:</dt>


	<t hangText="permerror:">	<dd>
	The DNS evaluation cannot work because test entri	The DNS evaluation cannot work because test entries don't
	es don't	work (that is, DNSWL is broken) or because queries are over quota
	work, that is, DNSWL is broken, or because queries are over quota,	(reported by a DNS RCODE of 5, commonly known as REFUSED, or by a
	e.g., a DNS RCODE of 5, commonly known as REFUSED, or a DNSWL-specific	DNSWL-specific
	property (policy.ip, defined below) with the same meaning.	property (policy.ip, defined below) with the same meaning).
	A later attempt is unlikely to produce a final result.	A later attempt is unlikely to produce a final result.
	Human intervention is required.	Human intervention is required.
	</t>	</dd>
	</list>	</dl>
	</t>	<t>
	<t>
	Note that there is no "fail" result.	Note that there is no "fail" result.

	</t>	</t>
		<t>
	<t>	The following ptype.property items define how the data provided
	The following ptype.property items define how the data provided	by the whitelist lookup can be saved.
	by the whitelist lookup can be saved.	</t>
	</t>	<dl newline="false" indent="13">
	<t>	<dt>dns.zone:</dt>
	<list style="hanging" hangIndent="12">	<dd>
	<t hangText="dns.zone:">	DNSWL query root domain, which defines the meaning of the
	DNSWL query root domain, which defines the meanin	policy.ip property below.
	g of the	Note that an MTA can use a local mirror with a different
	policy.ip property below.	name. The name stored here has to be the best available
	Note that an MTA can use a local mirror with a di	reference for all foreseeable downstream consumers.
	fferent	Setting dns.zone to the global zone makes the result
	name. The name stored here has to be the best av	intelligible even if the message is handed outside of the
	ailable	internal network.
	reference for all foreseeable downstream consumer	</dd>
	s.	<dt>policy.ip:</dt>
	Setting dns.zone to the global zone makes the res	<dd>
	ult	The bit mask value received in type A response,
	intelligible even if the message is handed outsid	in dotted quad notation.
	e of the	Multiple entries can be arranged in a quoted, comma-separated list
	internal network.	(quotes are necessary because commas are not allowed in a token).
	</t>	</dd>
		<dt>policy.txt:</dt>
	<t hangText="policy.ip:">	<dd>
	The bit mask value received in type A response,	The TXT record, if any. Multiple records are concatenated
	in dotted quad notation.	in the usual way (explained, for example, in
	Multiple entries can be arranged in a quoted, com	<xref target="RFC7208" sectionFormat="of" section="3.3"/>).
	ma separated list	See <xref target="TXTrecord" format="default"/> for the resulting
	(quotes are necessary because commas are not allo	content and query options.
	wed in a token.)	</dd>
	</t>	<dt>dns.sec:</dt>
		<dd>
	<t hangText="policy.txt:">	<t>
	The TXT record, if any. Multiple records are con	This is a generic property stating whether the relevant
	catenated	data was validated using DNSSEC <xref
	in the usual way (explained, for example, in Sect	target="RFC4033" format="default"/>.
	ion 3.3 of	For the present method, the relevant data consists of the
	<xref target="RFC7208" />).	reported policy properties above or, if the method result
	See <xref target="TXTrecord"/> for the resulting	is "none", its nonexistence.
	content and query options.	This property has three possible values:
	</t>

	<t hangText="dns.sec:">
	This is a generic property stating whether the re
	levant
	data was validated using DNSSEC (<xref target="RF
	C4033" />).
	For the present method, the relevant data consist
	s of the
	reported policy properties above, or, if the meth
	od result
	is "none", their non-existence.
	This property has three possible values:

	<list style="hanging" hangIndent="5">
	<t hangText="yes:">
	DNSSEC validation confirms the in
	tegrity of data.
	<xref target="seccon" /> consider
	s how that is
	related to the DNS response.
	</t>


	<t hangText="no:">	</t>
	The data are not signed. See <xr	<dl newline="false" indent="6">
	ef target="seccon" />.	<dt>yes:</dt>
	</t>	<dd>
		DNSSEC validation confirms the integrity of data.
		<xref target="seccon"
		format="default"/>
		considers how that is
		related to the DNS response.
		</dd>
		<dt>no:</dt>
		<dd>
		The data is not signed. See <xref target="seccon"
		format="default"/>.
		</dd>
		<dt>na:</dt>
		<dd>
		Not applicable. No DNSSEC validation can be performed, possibly because the
		lookup is run through a different means than a security-aware DNS resolver.
		This does not necessarily imply less security. In particular, "na" is used if
		the data was downloaded in bulk and then loaded on a local nameserver, which
		is the case of an MTA querying a local zone different from the reported
		dns.zone. DNS errors, including validation errors, can also report "na".
		This is also the value assumed by default.
		</dd>
		</dl>
		</dd>
		</dl>
		</section>
		<section anchor="TXTrecord" numbered="true" toc="default">
		<name>TXT Record Contents</name>
		<t>
		According to <xref target="RFC5782" format="default"/>, TXT records
		describe
		the reason why IP addresses are listed in a DNSWL.
		An example of a DNSWL whose TXT records contain the domain name
		of the organization assignee of the sending IP is given in
		<xref target="implement" format="default"/>.
		The domain name would correspond to the DNS domain
		name used by or within the Administrative Management Domain (ADMD)
		operating
		the relevant MTA, sometimes called the "organizational domain".
		In that case, the authentication provided by this method is
		equivalent to a DomainKeys Identified Mail (DKIM) signature
		<xref target="RFC6376" format="default"/> or
		an SPF check host <xref target="RFC7208" format="default"/>, if the
		DNSWL is
		trusted.
		</t>
		<t>
		According to a DNSWL's policy, attributing responsibility of an
		IP address to an organization may require something more than a
		mere PTR record consistency.
		If no domain names can be responsibly associated to a given IP
		address, for example, because the IP address was added without direct
		involvement of the organization concerned, DNSWLs can use a
		subdomain of .INVALID <xref target="RFC2606" format="default"/> where
		the leftmost
		label hints at why an address is whitelisted.
		For example, if the address 192.0.2.38 was added by the list
		managers solely based on their knowledge, the corresponding TXT
		record might be AUTOPROMOTED.INVALID so as to avoid explicitly
		identifying an entity that didn't opt in.
		</t>
		<t>
		Following the example of Multicast DNS (see the second
		paragraph of <xref target="RFC6762" sectionFormat="of"
		section="16"/>), names containing non-ASCII characters can be
		encoded in UTF-8 <xref target="RFC3629" format="default"/>
		using the Normalization Form C <xref target="NFC" format="default"/>,
		as
		described in "Unicode Format for Network Interchange" <xref
		target="RFC5198" format="default"/>. Inclusion of unaltered
		UTF-8 TXT values in the header entails an environment
		compatible with Email Address Internationalization (EAI) <xref
		target="RFC6530" format="default"/>.
		</t>
		<t>
		DNS queries with a QTYPE of ANY may lead to inconsistent replies,
		depending on the cache status. In addition, ANY is not "all",
		and the provisions for queries that have QTYPE=ANY
		<xref target="RFC8482" format="default"/> don't cover DNSxLs.
		A mail server can issue two simultaneous queries, A and TXT.
		Otherwise, a downstream filter can issue a TXT query on its own,
		if it knows that an A query was successful and that the DNSWL
		serves useful TXT records.
		It is unlikely that TXT records exist if a query for QTYPE A
		brought a result of "none".
		</t>
		</section>
		<section numbered="true" toc="default">


	<t hangText="na:">	<name>IANA Considerations</name>
	Not applicable. No DNSSEC valida
	tion can
	be performed, possibly because th
	e lookup is run
	through a different means than a
	security-aware
	DNS resolver.
	This does not necessarily imply l
	ess security.
	In particular, "na" is used if th
	e data were
	downloaded in bulk and then loade
	d on a local
	nameserver --which is the case of
	an MTA
	querying a local zone different f
	rom the
	reported dns.zone.
	DNS errors, including validation
	errors, can also
	report "na".
	This is also the value assumed by
	default.
	</t>
	</list>
	</t>
	</list>
	</t>


	</section>	<!-- [rfced] We made the following change to Table 1 in the IANA
		Considerations section. If no objection, we will request that IANA update
		the "Email Authentication Methods" registry at
		https://www.iana.org/assignments/email-auth/email-auth.xhtml#email-auth-methods
		accordingly before the document is published.


	<section anchor="TXTrecord" title="TXT Record Contents">	Original:
	<t>	type A response received (or a quoted,
	According to <xref target="RFC5782" />, TXT records describe	comma separated list thereof)
	the reason why IP addresses are listed in a DNSWL.
	An example of a DNSWL whose TXT records contain the domain name
	of the organization assignee of the sending IP is given in
	<xref target="implement"/>.
	The domain name would correspond to the DNS domain
	name used by or within the administrative domain (ADMD) operating
	the relevant MTA, sometimes called the "organizational domain".
	In that case, the authentication provided by this method is
	equivalent to a DKIM signature (<xref target="RFC6376" />) or
	an SPF check host (<xref target="RFC7208" />), if the DNSWL is
	trusted.
	</t>


	<t>	Updated (added hyphen):
	According to a DNSWL's policy, attributing responsibility of an	type A response received (or a quoted,
	IP address to an organization may require something more than a	comma-separated list thereof)
	mere PTR record consistency.
	If no domain names can be responsibly associated to a given IP
	address, for example because the IP address was added without dir
	ect
	involvement of the organization concerned, DNSWLs can use a
	subdomain of .INVALID (<xref target="RFC2606"/>) where the leftmo
	st
	label hints at why an address is whitelisted.
	For example, if the address 192.0.2.38 was added by the list
	managers solely based on their knowledge, the corresponding TXT
	record might be AUTOPROMOTED.INVALID, so as to avoid to explicitl
	y
	identify an entity who didn't opt-in.
	</t>


	<t>	[auth] Fine, thank you.
	Following the example of Multicast DNS (see the second paragraph
	of Section 16 of <xref target="RFC6762"/>) names containing non-A
	SCII
	characters can be encoded in UTF-8 <xref target="RFC3629"/> using
	the normalization form canonical composition (NFC) as described
	in Unicode Format for Network Interchange (<xref target="RFC5198"
	/>).
	Inclusion of unaltered UTF-8 TXT values in the header entails an
	environment compatible with EAI <xref target="RFC6530"/>.
	</t>


	<t>	tell IANA about this.
	DNS queries with a QTYPE of ANY may lead to inconsistent replies,
	depending on the cache status. In addition, ANY is not "all",
	and the provisions for queries that have QTYPE=ANY
	(<xref target="RFC8482" />) don't cover DNSxLs.
	A mail server can issue two simultaneous queries, A and TXT.
	Otherwise, a downstream filter can issue a TXT query on its own,
	if it knows that an A query was successful and that the DNSWL
	serves useful TXT records.
	It is unlikely that TXT records exist if a query for QTYPE A
	brought a result of none.
	</t>


	</section>	-->
		<t>
		IANA maintains the "Email Authentication Parameters" registry with
		several subregistries. IANA has made the assignments
		set out in the following sections.
		</t>
		<section numbered="true" toc="default">
		<name>Email Authentication Methods</name>
		<t>
		IANA has created four new entries in the "Email Authentication Methods"
		registry as follows.
		</t>
		<table align="center">
		<thead>
		<tr>
		<th align="left">Method</th>
		<th align="left">Definition</th>
		<th align="left">ptype</th>
		<th align="left">property</th>
		<th align="left">Value</th>
		<th align="left">Status</th>
		<th align="left">Version</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="left">dnswl</td>
		<td align="left">RFC 8904</td>
		<td align="left">dns</td>
		<td align="left">zone</td>
		<td align="left"><t>DNSWL publicly accessible query root domain</t></td>
		<td align="left">active</td>
		<td align="left">1</td>
		</tr>
		<tr>
		<td align="left">dnswl</td>
		<td align="left">RFC 8904</td>
		<td align="left">policy</td>
		<td align="left">ip</td>
		<td align="left"><t>type A response received (or a quoted,
		comma-separated list thereof)</t></td>
		<td align="left">active</td>
		<td align="left">1</td>
		</tr>
		<tr>
		<td align="left">dnswl</td>
		<td align="left">RFC 8904</td>
		<td align="left">policy</td>
		<td align="left">txt</td>
		<td align="left">type TXT query response</td>
		<td align="left">active</td>
		<td align="left">1</td>
		</tr>
		<tr>
		<td align="left">dnswl</td>
		<td align="left">RFC 8904</td>
		<td align="left">dns</td>
		<td align="left">sec</td>
		<td align="left">one of "yes" for DNSSEC authenticated data, "no" for
		not signed, or "na" for not applicable</td>
		<td align="left">active</td>
		<td align="left">1</td>
		</tr>
		</tbody>
		</table>
		</section>
		<section anchor="ptype" numbered="true" toc="default">
		<name>Email Authentication Property Type</name>
		<t>
		IANA has created a new entry in the "Email Authentication
		Property Types" registry as follows.
		</t>
		<table align="center">
		<thead>
		<tr>
		<th align="left">ptype</th>
		<th align="left">Definition</th>
		<th align="left">Description</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="left">dns</td>
		<td align="left">RFC 8904</td>
		<td align="left">The property being reported belongs to the
		Domain Name System.</td>
		</tr>
		</tbody>
		</table>
		</section>
		<section numbered="true" toc="default">
		<name>Email Authentication Result Names</name>
		<t>
		IANA has created four new entries in the "Email
		Authentication Result Names" registry as follows.
		</t>
		<table align="center">
		<thead>
		<tr>
		<th align="left">Auth Method</th>
		<th align="left">Code</th>
		<th align="left">Specification</th>
		<th align="left">Status</th>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td align="left">dnswl</td>
		<td align="left">pass</td>
		<td align="left">RFC 8904</td>
		<td align="left">active</td>
		</tr>
		<tr>
		<td align="left">dnswl</td>
		<td align="left">none</td>
		<td align="left">RFC 8904</td>
		<td align="left">active</td>
		</tr>
		<tr>
		<td align="left">dnswl</td>
		<td align="left">temperror</td>
		<td align="left">RFC 8904</td>
		<td align="left">active</td>
		</tr>
		<tr>
		<td align="left">dnswl</td>
		<td align="left">permerror</td>
		<td align="left">RFC 8904</td>
		<td align="left">active</td>
		</tr>
		</tbody>
		</table>
		</section>
		</section>
		<section numbered="true" toc="default">
		<name>Security Considerations</name>
		<section numbered="true" toc="default">
		<name>Over-Quota Signaling</name>
		<t>
		Some DNSWLs that provide for free access below a given quota
		are known to return special codes to signal that the
		quota has been exceeded (for
		example, 127.0.0.255).
		If the MTA cannot interpret that value, that case results
		in a false positive.
		It can accept messages that it would otherwise reject.
		A DNSWL-specific module would realize this fact and call for
		human intervention.
		</t>
		<t>
		Returning an RCODE 5 (REFUSED) conveys the
		concept that the query is "unauthorized" and human
		intervention required.
		</t>
		</section>
		<section anchor="seccon" numbered="true" toc="default">
		<name>Security of DNSSEC Validation</name>
		<t>
		The dns.sec property is meant to be as secure as DNSSEC results.
		It makes sense to use it in an environment where the DNSSEC
		validation can succeed.
		</t>
		<t>
		<xref target="RFC4033" sectionFormat="of"
		section="7"/> examines various ways of
		setting up a stub resolver that either validates DNSSEC locally
		or trusts the validation provided through a secure
		channel.


	<section title="IANA Considerations">	For a different class, it is possible to set up a dedicated,
	<t>	caching, DNSSEC-enabled resolver reachable by the mail
	IANA maintains the "Email Authentication Parameters" registry wit	server through interprocess communication on 127.0.0.1.
	h	In such cases, the property dns.sec=yes corresponds to the
	several subregistries. IANA is requested to make assignments as	Authenticated Data (AD) bit in the DNS response header.
	set out in the following sections.	</t>
		<t>
		When the response contains no DNSSEC data, a security-aware
		resolver seeks a signed proof of the nonexistence
		of a DS record at some delegation point. If no error is
		returned, the zone is unsigned and dns.sec=no can be set.
		The Security Considerations section of <xref
		target="RFC3225" format="default"/> states:
	</t>	</t>


	<section title="Email Authentication Methods">	<blockquote>
	<t>	The absence of DNSSEC data in response to a query with the DO bit set
	IANA is requested to create four new entries in the "Emai	MUST NOT be taken to mean no security information is available for
	l	that zone as the response may be forged or a non-forged response of
	Authentication Methods" registry as follows.	an altered (DO bit cleared) query.
	</t>	</blockquote>
	<figure><artwork><![CDATA[
	Method\|Definition\|ptype \|property\| Value \|Status\|Version
	dnswl \|[This.I-D]\|dns \|zone \| DNSWL publicly \|active\| 1
	\| \| \| \| accessible query \| \|
	\| \| \| \| root domain \| \|
	dnswl \|[This.I-D]\|policy\|ip \| type A response \|active\| 1
	\| \| \| \| received (or a \| \|
	\| \| \| \| quoted, comma \| \|
	\| \| \| \| separated list \| \|
	\| \| \| \| thereof) \| \|
	dnswl \|[This.I-D]\|policy\|txt \| type TXT query \|active\| 1
	\| \| \| \| response \| \|
	dnswl \|[This.I-D]\|dns \|sec \| one of "yes" for \|active\| 1
	\| \| \| \| DNSSEC \| \|
	\| \| \| \| authenticated \| \|
	\| \| \| \| data, "no" for \| \|
	\| \| \| \| not signed, or \| \|
	\| \| \| \| "na" for not \| \|
	\| \| \| \| applicable \| \|
	]]></artwork></figure>
	</section>

	<section anchor="ptype" title="Email Authentication Property Type">
	<t>
	IANA is requested to create a new entry in the "Email Aut
	hentication
	Property Types" registry as follows.
	</t>

	<texttable>
	<ttcol align='left'>ptype</ttcol>
	<ttcol align='left'>Definition</ttcol>
	<ttcol align='left'>Description</ttcol>
	<c>dns</c>
	<c>[This.I-D]</c>
	<c>The property being reported belongs to the Domain Name System<
	/c>
	</texttable>
	</section>

	<section title="Email Authentication Result Names">
	<t>
	IANA is requested to create four new entries in the "Emai
	l
	Authentication Result Names" registry as follows.
	</t>

	<texttable>
	<ttcol align='left'>Auth Method</ttcol>
	<ttcol align='left'>Code</ttcol>
	<ttcol align='left'>Specification</ttcol>
	<ttcol align='left'>Status</ttcol>
	<c>dnswl</c>
	<c>pass</c>
	<c>[This.I-D]</c>
	<c>active</c>

	<c>dnswl</c>
	<c>none</c>
	<c>[This.I-D]</c>
	<c>active</c>

	<c>dnswl</c>
	<c>temperror</c>
	<c>[This.I-D]</c>
	<c>active</c>

	<c>dnswl</c>
	<c>permerror</c>
	<c>[This.I-D]</c>
	<c>active</c>
	</texttable>
	</section>
	</section>

	<section title="Security Considerations">
	<section title="Over Quota Signaling">
	<t>
	Some DNSWLs which provide for free access below a given q
	uota
	are known to return special codes to signal over quota, f
	or
	example 127.0.0.255.
	If the MTA cannot interpret that value, that case results
	in a false positive.
	It can accept messages that it would otherwise reject.
	A DNSWL-specific module would realize the fact and call f
	or
	human intervention.
	</t>
	<t>
	Returning an RCODE 5 (REFUSED) conveys the
	concept that the query is "unauthorized", and human
	intervention required.
	</t>
	</section>

	<section anchor="seccon" title="Security of DNSSEC Validation">
	<t>
	The dns.sec property is meant to be as secure as DNSSEC r
	esults.
	It makes sense to use it in an environment where the DNSS
	EC
	validation can succeed.
	</t>

	<t>
	Section 7 of <xref target="RFC4033"/> examines various wa
	ys of
	setting up a stub resolver which either validates DNSSEC
	locally
	or trusts the validation provided through a secure channe
	l.
	For a different class, it is possible to set up a dedicat
	ed,
	caching, dnssec-enabled resolver reachable by the mail
	server through interprocess communication on 127.0.0.1.
	In such cases, the property dns.sec=yes corresponds to th
	e
	Authenticated Data (AD) bit in the DNS response header.
	</t>

	<t>
	When the response contains no DNSSEC data, a security-awa
	re
	resolver seeks a signed proof of the non-existence
	of a DS record, at some delegation point. If no error is
	returned, the zone is unsigned and dns.sec=no can be set.
	According to the Security Considerations Section of <xref
	target="RFC3225"/>:
	The absence of DNSSEC data in response to a query with th
	e DO bit set
	must not be taken to mean no security information is avai
	lable for
	that zone as the response may be forged or a non-forged r
	esponse of
	an altered (DO bit cleared) query.
	</t>

	<t>
	If the application verifies the DNSSEC signatures on its
	own, it effectively behaves like a validating stub resolv
	er,
	and hence can set dns.sec correspondingly.
	</t>

	<t>
	When the data are downloaded in bulk and made available o
	n a
	trusted channel without using DNSSEC, set dns.sec=na or n
	ot
	at all. DNSWL who publish bulk versions of their data ca
	n
	also sign that data, for example using OpenPGP (<xref tar
	get="RFC4880"/>).
	It is the responsibility of system administrators to
	authenticate the data by downloading and validating the s
	ignature.
	The result of such validation is not reported using dns.s
	ec.
	</t>
	</section>

	<section title="Inherited Security Considerations">
	<t>
	For DNSSEC, the considerations of Section 12 of <xref tar
	get="RFC4033"/> apply.
	</t>


	<t>	<t>
	All of the considerations described in Section 7 of	If the application verifies the DNSSEC signatures on its
	<xref target="RFC8601"/> apply.	own, it effectively behaves like a validating resolver
	That includes securing against tampering all the channels	and hence can set dns.sec correspondingly.
	after	</t>
	the production of this Authentication-Results header fiel	<t>
	d.	When the data is downloaded in bulk and made available on a
	</t>	trusted channel without using DNSSEC, the application sets dns.sec=na o
		r not
		at all. For example, consider DNSWLs that publish bulk versions of
		their data duly signed using OpenPGP <xref
		target="RFC4880" format="default"/>.
		It is the responsibility of system administrators to
		authenticate the data by downloading and validating the signature.
		The result of such validation is not reported using dns.sec.
		</t>
		</section>
		<section numbered="true" toc="default">
		<name>Inherited Security Considerations</name>
		<t>
		For DNSSEC, the considerations of <xref
		target="RFC4033" sectionFormat="of" section="12"/> apply.
		</t>
		<t>
		All of the considerations described in
		<xref target="RFC8601" sectionFormat="of" section="7"/> apply.
		That includes securing against tampering all the channels after
		the production of the Authentication-Results header field.
		</t>
		<t>
		In addition, the usual caveats apply about importing text from
		external online sources. Although queried DNSWLs are well-known,
		trusted entities, it is suggested that TXT records be reported
		only if, upon inspection, their content is deemed actionable
		and their format compatible with the computing environment.
		</t>
		</section>
		</section>
		</middle>


	<t>	<back>
	In addition, the usual caveats apply about importing text	<references>
	from	<name>References</name>
	external online sources. Although queried DNSWLs are wel	<references>
	l known,	<name>Normative References</name>
	trusted entities, it is suggested that TXT records be rep	<xi:include
	orted	href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
	only if, upon inspection, their content is deemed actuall	2606.xml"/>
	y actionable,	<xi:include
	and their format compatible with the computing environmen	href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
	t.	5782.xml"/>
	</t>	<xi:include
	</section>	href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
	</section>	8601.xml"/>
	</middle>	</references>
		<references>
		<name>Informative References</name>
		<xi:include
		href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
		1034.xml"/>
		<xi:include
		href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
		3225.xml"/>
		<xi:include
		href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
		3629.xml"/>
		<xi:include
		href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
		4033.xml"/>
		<xi:include
		href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
		4880.xml"/>
		<xi:include
		href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
		5198.xml"/>
		<xi:include
		href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
		5598.xml"/>
		<xi:include
		href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
		6376.xml"/>
		<xi:include
		href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
		6530.xml"/>
		<xi:include
		href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
		6762.xml"/>
		<xi:include
		href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
		7208.xml"/>
		<xi:include
		href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
		7489.xml"/>
		<xi:include
		href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
		8460.xml"/>
		<xi:include
		href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.
		8482.xml"/>


	<!-- ***BACK MATTER *** -->	<reference anchor="Courier-MTA" target="https://www.courier-mta.org/">
		<front>
		<title>Courier Mail Server</title>
		<author/>
		</front>
		</reference>


	<back>	<reference anchor="DNSWL" target="https://www.dnswl.org/">
	<references title="Normative References">	<front>
	&RFC2606;	<title>dnswl.org - E-Mail Reputation – Protect against false
	&RFC5782;	positives</title>
	&RFC8601;	<author/>
	</references>	</front>
		</reference>


	<references title="Informative References">	<reference anchor="NFC"
	&RFC1034;	target="https://www.unicode.org/reports/tr15/tr15-50.html">
	&RFC3225;	<front>
	&RFC3629;	<title>Unicode Normalization Forms</title>
	&RFC4033;	<author initials="K." surname="Whistler" fullname="Ken Whistler"
	&RFC4880;	role="editor">
	&RFC5198;	<organization />
	&RFC5598;	</author>
	&RFC6376;	<date month="February" year="2020" />
	&RFC6530;	</front>
	&RFC6762;	<seriesInfo name="Unicode Standard Annex" value="15" />
	&RFC7208;
	&RFC7489;
	&RFC8460;
	&RFC8482;
	<reference anchor="Courier-MTA" target="https://www.courier-mta.org/">
	<front>
	<title>Courier Mail Server</title>
	<author/>
	<date/>
	</front>
	</reference>
	<reference anchor="dnswl.org" target="https://www.dnswl.org/">
	<front>
	<title>DNSWL.ORG</title>
	<author/>
	<date/>
	</front>
	</reference>	</reference>


	</references>	</references>
		</references>


	<section anchor="example" title="Example">	<section anchor="example" numbered="true" toc="default">
	<figure align="center"><artwork><![CDATA[	<name>Example</name>
		<figure>
		<name>Trace Fields at the Top of the Header</name>
		<sourcecode name="" type=""><![CDATA[
	Delivered-To: recipient@example.org	Delivered-To: recipient@example.org
	Return-Path: <sender@example.com>	Return-Path: <sender@example.com>
	Authentication-Results: mta.example.org;	Authentication-Results: mta.example.org;
	dkim=pass (whitelisted) header.i=@example.com	dkim=pass (whitelisted) header.i=@example.com
	Authentication-Results: mta.example.org;	Authentication-Results: mta.example.org;
	dnswl=pass dns.zone=list.dnswl.example dns.sec=na	dnswl=pass dns.zone=list.dnswl.example dns.sec=na
	policy.ip=127.0.10.1	policy.ip=127.0.10.1
	policy.txt="fwd.example https://dnswl.example/?d=fwd.example"	policy.txt="fwd.example https://dnswl.example/?d=fwd.example"
	Received-SPF: fail (Address does not pass Sender Policy Framework)	Received-SPF: fail (Address does not pass Sender Policy Framework)
	client-ip=2001:db8::2:1;	client-ip=2001:db8::2:1;
	envelope-from="sender@example.com";	envelope-from="sender@example.com";
	helo=mail.fwd.example;	helo=mail.fwd.example;
	receiver=mta.example.org;	receiver=mta.example.org;
	Received: from mail.fwd.example (mail.fwd.example [2001:db8::2:1])	Received: from mail.fwd.example (mail.fwd.example [2001:db8::2:1])
	(TLS: TLSv1/SSLv3,128bits,ECDHE-RSA-AES128-GCM-SHA256)	(TLS: TLSv1/SSLv3,128bits,ECDHE-RSA-AES128-GCM-SHA256)
	by mta.example.org with ESMTPS; Thu, 03 Oct 2019 19:23:11 +0200	by mta.example.org with ESMTPS; Thu, 03 Oct 2019 19:23:11 +0200
	id 00000000005DC044.000000005702D87C.000007FC	id 00000000005DC044.000000005702D87C.000007FC

	]]></artwork><postamble>	]]></sourcecode>
	Trace fields at the top of the header	</figure>
	</postamble></figure>	<t>The message went through a third party, fwd.example, which forwarded
		it to the final MTA. The mail path was not arranged beforehand with
	<t>The message went through a third party, fwd.example, which forwarded	the involved MTAs; it emerged spontaneously. This message would not
	it to the final MTA. Such mail path was not arranged beforehand with	have
	the involved MTAs, it emerged spontaneously. This message would not have	made it to the target without whitelisting, because:</t>
	made it to the target without whitelisting, because:<list style="symbols"	<ul>
	>	<li>the author domain published a strict SPF policy (-all),</li>
	<t>the author domain published a strict SPF policy (-all),</t>	<li>the forwarder did not alter the bounce address, and</li>
	<t>the forwarder did not alter the bounce address, and</t>	<li>the target usually honors reject on fail, according to <xref
	<t>the target usually honors reject-on-fail, according to Section 8.4 of	target="RFC7208" sectionFormat="of" section="8.4"/>.</li>
	<xref target="RFC7208"/>.</t></list></t>	</ul>
		<t>However, the target also implemented the last paragraph of <xref
	<t>However, the target also implemented the last paragraph of Appendix	target="RFC7208" sectionFormat="of" section="D.3"/>. Its behavior
	D.3 of <xref target="RFC7208"/>. Its behavior hinges on the following	hinges on the following DNS entries:</t>
	DNS entries:</t>	<figure>
		<name>DNS Resource Records for 2001:db8::2:1
	<figure><artwork><![CDATA[	(line breaks for editorial reasons)</name>
		<sourcecode name=""><![CDATA[
	1.0.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.b.8.2.0.0.1.	1.0.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.b.8.2.0.0.1.
	list.dnswl.example.	list.dnswl.example.
	IN A 127.0.10.1	IN A 127.0.10.1
	IN TXT "fwd.example https://dnswl.example/?d=fwd.example"	IN TXT "fwd.example https://dnswl.example/?d=fwd.example"

		]]></sourcecode>
		</figure>
		<t>If mail.fwd.example had connected from address 192.0.2.1, then
		the query name would have been <tt>1.2.0.192.list.dnswl.example</tt>.
		See full description in <xref target="RFC5782" format="default"/>.</t>
		<t>At connection time, because the remote IP address is whitelisted,
		the target MTA did not reject the message before DATA. Instead, it
		recorded the SPF fail result and indicated the local policy mechanism
		that was applied in order to override that result.
		Subsequent filtering verified DKIM <xref target="RFC6376"
		format="default"/>.</t>
		<t>At later stages, mail filters can reject or quarantine the message
		based on its content.
		A deeper knowledge of the policy values obtained from dnswl.example
		allows interpreting the values of policy.ip and weighing them against
		other factors so as to make better decisions.</t>
		</section>
		<section anchor="implement" numbered="true" toc="default">
		<name>Known Implementation</name>
		<t>
		Implementation details mentioned in this section have been
		stable for several years.
		Yet, this description is necessarily superficial, version
		dependent, and subject to change.
		</t>
		<t>
		Courier-MTA <xref target="Courier-MTA" format="default"/> can be
		configured to look up DNSBLs
		and DNSWLs, with similar command-line switches:
		</t>
		<sourcecode name=""><![CDATA[
		-block=zone[=displayzone][,var[/n.n.n.n][,msg]]
		-allow=zone[=displayzone][,var[/n.n.n.n[,]]]
		]]></sourcecode>
		<t>
		"zone" is the zone to be queried.
		</t>
		<t>
		"displayzone" is only used for -allow; it is the value to be set
		in the dns.zone property.
		</t>
		<t>
		"var" stands for the environment variable whose existence triggers
		a special action. The default variable names result in a
		conventional behavior implemented by Courier-MTA.
		By setting different environment variables,
		users can customize the behavior. Conventional behavior differs
		widely
		between -block and -allow. The former rejects the message; the latter
		produces Authentication-Results header fields.
		</t>
		<t>
		The n.n.n.n IP address requires a precise A record response. If
		not given, any response results in setting the corresponding variable.
		If given, variables are set only if the response matches exactly.
		Such syntax provides for a very limited interpretation of the
		information encoded in A records.
		However, it is considered to be too complicated already.
		Even specifying a range, an enumeration of values, or a regular
		expression would require something beyond what a normal user
		would be willing to manage.
		</t>
		<t>
		Finally, the trailing message, which overrides the 5xx SMTP reply
		for -block, is not used for -allow, except that its mere presence
		requires querying TXT records to be registered in policy.txt.
		</t>


	DNS resource records for 2001:db8::2:1	<t>
	(line breaks for editorial reasons)	SPF is part of Courier-MTA's core. It is configured separately
	]]></artwork></figure>	and provides for an "allowok" keyword to indicate the choice to
		override
		rejection in case of SPF failure and -allow whitelisting.
		</t>


	<t>If mail.fwd.example had connected from address 192.0.2.1, then	<t>
	the query name would have been 1.2.0.192.list.dnswl.example.	A customary whitelist is defined by DNSWL.org <xref target="DNSWL"
	See full description in <xref target="RFC5782"/></t>	format="default"/>. It serves A records
		encoded as follows:
		</t>


	<t>At connection time, because the remote IP address is whitelisted,	<dl newline="false" spacing="normal">
	the target MTA did not reject the message before DATA. Instead, it	<dt>1st octet:</dt><dd>127.</dd>
	recorded the SPF fail result, and indicated the local policy mechanism
	which was applied in order to override that result.
	Subsequent filtering verified DKIM <xref target="RFC6376"/>.</t>


	<t>At later stages, mail filters can reject or quarantine the message	<dt>2nd octet:</dt><dd>0.</dd>
	based on its content.
	A deeper knowledge of the policy values obtained from dnswl.example
	allows to interpret the values of policy.ip and weight them against
	other factors so as to make better decisions.</t>
	</section>


	<section anchor="implement" title="Known Implementation">	<dt>3rd octet:</dt><dd>Category of business, 15 values.</dd>
	<t>
	Implementation details mentioned in this section have been
	stable for several years.
	Yet, this description is necessarily superficial, version
	dependent, and subject to change.
	</t>
	<t>
	<xref target="Courier-MTA"/> can be configured to lookup DNSBL
	and DNSWL, with similar command line switches:
	</t>


	<figure><artwork><![CDATA[	<dt>4th octet:</dt><dd>Trustworthiness/score, 4 values.</dd>
	-block=zone[=displayzone][,var[/n.n.n.n][,msg]]	</dl>
	-allow=zone[=displayzone][,var[/n.n.n.n[,]]]
	]]></artwork></figure>


	<t>	<t>
	zone is the zone to be queried.	They also serve TXT records containing the domain name followed by a
	</t>	URL pointing to further information about the relevant organization,
	<t>	such as what other IP addresses of theirs are being whitelisted.
	displayzone is only used for -allow, it is the value to be set	They don't use UTF-8.
	in the dns.zone property.	</t>
	</t>
	<t>
	var stands for the environment variable whose existence triggers
	a special action. The default variable names result in a
	conventional behavior implemented by Courier-MTA.
	By setting different environment variables,
	users can customize the behavior. Conventional behavior differs
	widely
	between -block and -allow. The former rejects the message, the l
	atter
	produces Authentication-Results header fields.
	</t>
	<t>
	The n.n.n.n IP address requires a precise A record response. If
	not given, any response results in setting the corresponding vari
	able.
	If given, variables are set only if the response matches exactly.
	Such syntax provides for a very limited interpretation of the
	information encoded in A records.
	However, it is considered to be too complicated already.
	Even specifying a range, an enumeration of values, or a regular
	expression would require something beyond what a normal user
	would be willing to manage.
	</t>
	<t>
	Finally, the trailing message, which overrides the 5xx SMTP reply
	for -block, is not used for -allow, except that its mere presence
	requires to query TXT records to be registered in policy.txt.
	</t>
	<t>
	SPF is part of Courier-MTA's core. It is configured separately,
	and provides for an "allowok" keyword to indicate to override
	rejection in case of SPF failure and -allow whitelisting.
	</t>
	<t>
	A customary whitelist is <xref target="dnswl.org"/>. It serves
	A records encoded as follows:
	<list>
	<t>1st octect: 127.</t>
	<t>2nd octect: 0.</t>
	<t>3rd octect: Category of business, 15 values.</t>
	<t>4th octect: Trusworthiness/score, 4 values.</t>
	</list>
	They also serve TXT records containing the domain name followed
	by an URL pointing to further info about the relevant organizatio
	n,
	such as what other IP addresses of theirs are being whitelisted.
	They don't use UTF-8.
	</t>
	<t>
	dnswl.org provides for free registration and free access below
	100,000 queries per day.
	They use the special return code 127.0.0.255 exemplified above
	to signal over quota.
	Although Courier-MTA itself does not recognize it, it has a mail
	filter (zdkimfilter, named after its main usage) where recognitio
	n
	of that code, as well as that of trusworthiness in
	the 4th octect are hard-coded.
	</t>
	</section>


	<section title="Future possibilities of the 'dns' ptype">	<t>
	<t>	DNSWL.org provides for free
	The description of the new ptype proposed in <xref target="ptype"	registration and free access below
	/>	100,000 queries per day.
	just says "The property being reported belongs to the Domain Name	They use a special return code, 127.0.0.255 as exemplified above,
	System". That definition can broadly include any tag found in a	to signal that the quota has been exceeded.
	domain's TXT record. For example, auth methods designers can
	agree that within a resinfo of a given method, any dns ptype
	refers to tags in the relevant DNS record, unless otherwise
	specified. So one could have, say:
	</t>


	<figure><artwork><![CDATA[	Although Courier-MTA itself does not recognize this return code, it has a mail
		filter (zdkimfilter, named after its main usage) that hard codes recognition
		of this code and the code for trustworthiness in the 4th octet.
		</t>
		</section>
		<section numbered="true" toc="default">
		<name>Future Possibilities of the 'dns' ptype</name>
		<t>
		The description of the new ptype proposed in <xref target="ptype"
		format="default"/>
		says, "The property being reported belongs to the Domain Name
		System." That definition can broadly include any tag found in a
		domain's TXT record. For example, designers of
		authentication methods can
		agree that within a resinfo of a given method, any dns ptype
		refers to tags in the relevant DNS record, unless otherwise
		specified. So one could have, say:
		</t>
		<sourcecode name="" type=""><![CDATA[
	Authentication-Results: example.com;	Authentication-Results: example.com;
	spf=pass smtp.mailfrom=example.net dns.sec=y;	spf=pass smtp.mailfrom=example.net dns.sec=y;
	dkim=pass header.i=@example.org header.b=jIvx30NG dns.s=tlsrpt	dkim=pass header.i=@example.org header.b=jIvx30NG dns.s=tlsrpt

	]]></artwork></figure>	]]></sourcecode>
		<t>
	<t>	While dns.sec is defined above, albeit not for the spf method,
	While dns.sec is defined above, albeit not for the spf method,	the use of tlsrpt in the DKIM record is exemplified in
	the use of tlsrpt in the DKIM record is exemplified in	<xref target="RFC8460" sectionFormat="of" section="3"/>.
	Section 3 of <xref target="RFC8460"/>.	The tag s= is part of the DKIM TXT record, not to be confused
	The tag s= is part of the DKIM TXT record, not to be confused	with the selector s=, which is part of a DKIM signature. Just
	with the selector s=, which is part of a DKIM-Signature. Just	like the latter can be reported as header.s because the DKIM
	like the latter can be reported as header.s because the DKIM	header field is in the message header, it may make sense to
	header field is in the message header, it may make sense to	report the former as dns.s because the DKIM DNS record is in the
	report the former as dns.s because the DKIM DNS record is in the	DNS.
	DNS.	</t>
	</t>	<t>
	<t>	NOTE: This is only a hint at what may become a consistent naming
	NOTE: This is only a hint at what may become a consistent naming	convention around the new ptype. In any case, any new property
	convention around the new ptype. In any case, any new property	using this ptype requires its own formal definition. This document
	using this ptype requires its own formal definition. This docume	does NOT define the property dns.s=, let alone the service tlsrpt.
	nt	</t>
	does NOT define the property dns.s=, let alone the service tlsrpt	</section>
	.
	</t>
	</section>

	</back>	</back>
	</rfc>	</rfc>

End of changes. 46 change blocks.
	831 lines changed or deleted	782 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/