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

<!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 --> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="independent" docName="draft-vesely-authmethod-dnswl-16"
     category="info" ipr="trust200902">

<!-- category values: std, bcp, info, exp, and historic
	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 ***** --> 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>
	<!-- The abbreviated title is used in the page header - it is only necessary if the
		full title is longer than 39 characters -->

  <title abbrev="DNSWL email-auth-method extension">DNSWL Email Auth Method Extension">DNS Whitelist
  (DNSWL) Email Authentication Method Extension</title>

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

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

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

<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>
          <country>Italy</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, xml2rfc will fill
		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 current 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 normally sufficient to
		specify just the year. -->

	<!-- Meta-data Declarations --> month="September" year="2020"/>

    <area>General</area>
    <workgroup>IETF</workgroup>

	<!-- WG name at the upperleft corner of the doc,
		IETF is fine for individual submissions.
		If this element is not present, the default is "Network Working Group",
		which is used by the RFC Editor as a nod to the history of the IETF. -->
    <keyword>DNSWL</keyword>
    <keyword>EMAIL</keyword>
    <keyword>Authentication-Results</keyword>

	<!-- Keywords will be incorporated into HTML output
		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>
This document describes an additional Email Authentication Method email authentication method compliant
with RFC 8601.  The method consists in of looking up the sender's IP address in a
DNS whitelist.  This document is provided for provides information in case the method is seen
in the field, as well as to suggest suggests a useful practice practice, and register registers the
relevant keywords.
      </t>
      <t>
	This document does not consider black lists. blacklists.
      </t>
    </abstract>
</front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
	One of the many checks that mail servers carry out is to query domain
		name system DNS
	whitelists (DNSWL). (DNSWLs).
	That method is fully discussed in <xref target="RFC5782"/>. target="RFC5782"
	format="default"/>.
	The DNS <xref target="RFC1034"/> 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"/>. 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
	(SPF) (the last paragraph of Appendix D.3 of <xref target="RFC7208"/> target="RFC7208"
	sectionFormat="of" section="D.3"/> is also illustrated in
	<xref target="example"/>). target="example" format="default"/>).
	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-Results
	header field aims at providing. 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 -- one of the major branches described by
	<xref target="RFC5782"/>. target="RFC5782" format="default"/>.  There are also black/block lists,
		DNSBL,
	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 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"/>)
	target="RFC5598" format="default"/>), which carries out the check and
	possibly stores the result 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. properties
	of the method.  The meaning of such data varies widely at the mercy
	of the list operator, hence 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.

Downstream agents who know DNSWL-specific encoding and understand the meaning
of that datum data can use it to make delivery or display decisions.  For example,
a mail filter which detected that detects heuristic evidence of a scam can counterweight such
information with the trustworthiness score encoded in the A response, response so as to
protect agains against false positives.  MUAs  Mail User Agents (MUAs) can display those results,
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"/>. target="RFC7489" format="default"/>.
      </t>

      <t>
	At the time of this writing, this method is implemented by Courier-MTA
	<xref target="Courier-MTA"/>. target="Courier-MTA" format="default"/>.  An outline of the
	implementation
	is given in <xref target="implement"/>. target="implement" format="default"/>.
      </t>
    </section>
    <section title="Method Details" anchor="mresults"> 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:

		<list style="hanging" hangIndent="12">
			<t hangText="pass:">

      </t>
      <dl newline="false" indent="13">
        <dt>pass:</dt>
        <dd>
	  The query successfully returned applicable
	  records.  This result is usually accompanied
	  by one or both of the policy properties
	  described below.  Since the list is configured
	  as a DNSWL, agents unable to interpret list-specifc
	  list-specific properties can still derive a
	  positive value from the fact that the sender
	  is whitelisted.
			</t>

			<t hangText="none:">
	</dd>
        <dt>none:</dt>
        <dd>
	  The query worked but yielded no A record, record or returned
	  NXDOMAIN, so the sender is not whitelisted.
			</t>

			<t hangText="temperror:">
	</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.,
	  error (e.g., a DNS RCODE of 2, commonly known as SERVFAIL, SERVFAIL) or
	  other error condition.  A later attempt may produce a
	  final result.
			</t>

			<t hangText="permerror:">
	</dd>
        <dt>permerror:</dt>

        <dd>
	  The DNS evaluation cannot work because test entries don't
	work, that
	  work (that is, DNSWL is broken, broken) or because queries are over quota,
	e.g., quota
	  (reported by a DNS RCODE of 5, commonly known as REFUSED, or by a
	  DNSWL-specific
	  property (policy.ip, defined below) with the same meaning. meaning).
	  A later attempt is unlikely to produce a final result.
	  Human intervention is required.
			</t>
		</list>
	</t>
	</dd>
      </dl>
      <t>
	Note that there is no "fail" result.
      </t>
      <t>
	The following ptype.property items define how the data provided
	by the whitelist lookup can be saved.
      </t>
	<t>
		<list style="hanging" hangIndent="12">
			<t hangText="dns.zone:">
      <dl newline="false" indent="13">
        <dt>dns.zone:</dt>
        <dd>
	  DNSWL query root domain, which defines the meaning of the
	  policy.ip property below.
	  Note that an MTA can use a local mirror with a different
	  name.  The name stored here has to be the best available
	  reference for all foreseeable downstream consumers.
	  Setting dns.zone to the global zone makes the result
	  intelligible even if the message is handed outside of the
	  internal network.
			</t>

			<t hangText="policy.ip:">
	</dd>
        <dt>policy.ip:</dt>
        <dd>
	  The bit mask value received in type A response,
	  in dotted quad notation.
	  Multiple entries can be arranged in a quoted, comma separated comma-separated list
	  (quotes are necessary because commas are not allowed in a token.)
			</t>

			<t hangText="policy.txt:"> token).
	</dd>
        <dt>policy.txt:</dt>
        <dd>
	  The TXT record, if any.  Multiple records are concatenated
	  in the usual way (explained, for example, in Section 3.3 of
	  <xref target="RFC7208" />). sectionFormat="of" section="3.3"/>).
	  See <xref target="TXTrecord"/> target="TXTrecord" format="default"/> for the resulting
	  content and query options.
			</t>

			<t hangText="dns.sec:">
	</dd>
        <dt>dns.sec:</dt>
        <dd>
          <t>
	    This is a generic property stating whether the relevant
	    data was validated using DNSSEC (<xref <xref
	    target="RFC4033" />). format="default"/>.
	    For the present method, the relevant data consists of the
	    reported policy properties above, above or, if the method result
	    is "none", their non-existence. its nonexistence.
	    This property has three possible values:

				<list style="hanging" hangIndent="5">
					<t hangText="yes:">

          </t>
          <dl newline="false" indent="6">
            <dt>yes:</dt>
            <dd>
	      DNSSEC validation confirms the integrity of data.
	      <xref target="seccon" />
		          format="default"/>
	      considers how that is
	      related to the DNS response.
					</t>

					<t hangText="no:">
	    </dd>
            <dt>no:</dt>
            <dd>
	      The data are is not signed.  See <xref target="seccon" />.
					</t>

					<t hangText="na:">
	      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 were was downloaded in bulk and then loaded on a local
						nameserver --which 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.
					</t>
				</list>
			</t>
		</list>
	</t>
	    </dd>
          </dl>
        </dd>
      </dl>
    </section>
    <section anchor="TXTrecord" title="TXT numbered="true" toc="default">
      <name>TXT Record Contents"> 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"/>. target="implement" format="default"/>.
	The domain name would correspond to the DNS domain
	name used by or within the administrative domain 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 DKIM DomainKeys Identified Mail (DKIM) signature (<xref
	<xref target="RFC6376" />) format="default"/> or
	an SPF check host (<xref <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 example, because the IP address was added without direct
	involvement of the organization concerned, DNSWLs can use a
	subdomain of .INVALID (<xref target="RFC2606"/>) <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, AUTOPROMOTED.INVALID so as to avoid to explicitly
		identify
	identifying an entity who that didn't opt-in. opt in.
      </t>
      <t>
	Following the example of Multicast DNS (see the second
	paragraph of Section 16 of <xref target="RFC6762"/>) target="RFC6762" sectionFormat="of"
	section="16"/>), names containing non-ASCII characters can be
	encoded in UTF-8 <xref target="RFC3629"/> target="RFC3629" format="default"/>
	using the normalization form canonical composition (NFC) Normalization Form C <xref target="NFC" format="default"/>,
	as
	described in Unicode "Unicode Format for Network Interchange (<xref target="RFC5198"/>). Interchange" <xref
	target="RFC5198" format="default"/>.  Inclusion of unaltered
	UTF-8 TXT values in the header entails an environment
	compatible with EAI Email Address Internationalization (EAI) <xref target="RFC6530"/>.
	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
	<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. "none".
      </t>
    </section>
    <section title="IANA Considerations"> numbered="true" toc="default">

      <name>IANA Considerations</name>

<!-- [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.

Original:
type A response received (or a quoted,
comma separated list thereof)

Updated (added hyphen):
type A response received (or a quoted,
comma-separated list thereof)

[auth] Fine, thank you.

tell IANA about this.

-->
      <t>
	IANA maintains the "Email Authentication Parameters" registry with
	several subregistries.  IANA is requested to make has made the assignments as
	set out in the following sections.
      </t>
      <section title="Email numbered="true" toc="default">
        <name>Email Authentication Methods"> Methods</name>
        <t>
IANA is requested to create has created four new entries in the "Email Authentication Methods"
registry as follows.
        </t>
		<figure><artwork><![CDATA[
------+----------+------+--------+-------------------+------+-------
Method|Definition|ptype |property| Value             |Status|Version
------+----------+------+--------+-------------------+------+-------
dnswl |[This.I-D]|dns   |zone    | DNSWL
<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    |active|   1
      |          |      |        | accessible query  |      |
      |          |      |        | root domain       |      |
dnswl |[This.I-D]|policy|ip      | type 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   |active|   1
      |          |      |        | received (or a    |      |
      |          |      |        | quoted, comma     |      |
      |          |      |        | separated
      comma-separated list    |      |
      |          |      |        | thereof)          |      |
dnswl |[This.I-D]|policy|txt     | type 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    |active|   1
      |          |      |        | response          |      |
dnswl |[This.I-D]|dns   |sec     | one 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  |active|   1
      |          |      |        | DNSSEC            |      |
      |          |      |        | authenticated     |      |
      |          |      |        | data, "no" for    |      |
      |          |      |        |
      not signed, or    |      |
      |          |      |        | "na" for not      |      |
      |          |      |        | applicable        |      |
------+----------+------+--------+-------------------+------+-------
]]></artwork></figure> applicable</td>
      <td align="left">active</td>
      <td align="left">1</td>
    </tr>
  </tbody>
</table>
      </section>
      <section anchor="ptype" title="Email numbered="true" toc="default">
        <name>Email Authentication Property Type"> Type</name>
        <t>
	  IANA is requested to create has created a new entry in the "Email Authentication
	  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
        <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</c>
		</texttable> System.</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section title="Email numbered="true" toc="default">
        <name>Email Authentication Result Names"> Names</name>
        <t>
	  IANA is requested to create has created four new entries in the "Email
	  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>
        <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 title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <section title="Over Quota Signaling"> numbered="true" toc="default">
        <name>Over-Quota Signaling</name>
        <t>
	  Some DNSWLs which that provide for free access below a given quota
	  are known to return special codes to signal over quota, for
			example 127.0.0.255. 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 the this fact and call for
	  human intervention.
        </t>
        <t>
	  Returning an RCODE 5 (REFUSED) conveys the
	  concept that the query is "unauthorized", "unauthorized" and human
	  intervention required.
        </t>
      </section>
      <section anchor="seccon" title="Security numbered="true" toc="default">
        <name>Security of DNSSEC Validation"> 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>
			Section 7 of
	  <xref target="RFC4033"/> target="RFC4033" sectionFormat="of"
		section="7"/> examines various ways of
	  setting up a stub resolver which that either validates DNSSEC locally
	  or trusts the validation provided through a secure
	  channel.

For a different class, it is possible to set up a dedicated,
caching, dnssec-enabled 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 the
Authenticated Data (AD) bit in the DNS response header.
        </t>
        <t>
	  When the response contains no DNSSEC data, a security-aware
	  resolver seeks a signed proof of the non-existence nonexistence
	  of a DS record, record at some delegation point.  If no error is
	  returned, the zone is unsigned and dns.sec=no can be set.
			According to the
	  The Security Considerations Section section of <xref target="RFC3225"/>:
	  target="RFC3225" format="default"/> states:
	</t>

<blockquote>
   The absence of DNSSEC data in response to a query with the DO bit set
			must not
   MUST NOT be taken to mean no security information is available for
   that zone as the response may be forged or a non-forged response of
   an altered (DO bit cleared) query.
		</t>
</blockquote>

        <t>
	  If the application verifies the DNSSEC signatures on its
	  own, it effectively behaves like a validating stub resolver, resolver
	  and hence can set dns.sec correspondingly.
        </t>
        <t>
	  When the data are is downloaded in bulk and made available on a
	  trusted channel without using DNSSEC, set the application sets dns.sec=na or not
	  at all.  DNSWL who For example, consider DNSWLs that publish bulk versions of
	  their data can
			also sign that data, for example duly signed using OpenPGP (<xref target="RFC4880"/>). <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 title="Inherited numbered="true" toc="default">
        <name>Inherited Security Considerations"> Considerations</name>
        <t>
	  For DNSSEC, the considerations of Section 12 of <xref target="RFC4033"/>
	  target="RFC4033" sectionFormat="of" section="12"/> apply.
        </t>
        <t>
	  All of the considerations described in Section 7 of
	  <xref target="RFC8601"/> target="RFC8601" sectionFormat="of" section="7"/> apply.
	  That includes securing against tampering all the channels after
	  the production of this 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, well-known,
	  trusted entities, it is suggested that TXT records be reported
	  only if, upon inspection, their content is deemed actually actionable, actionable
	  and their format compatible with the computing environment.
        </t>
      </section>
    </section>
  </middle>

<!--  *****BACK MATTER ***** -->

<back>
	<references title="Normative References">
	&RFC2606;
	&RFC5782;
	&RFC8601;
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include
	    href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2606.xml"/>
        <xi:include
	    href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5782.xml"/>
        <xi:include
	    href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8601.xml"/>
      </references>

	<references title="Informative References">
	&RFC1034;
	&RFC3225;
	&RFC3629;
	&RFC4033;
	&RFC4880;
	&RFC5198;
	&RFC5598;
	&RFC6376;
	&RFC6530;
	&RFC6762;
	&RFC7208;
	&RFC7489;
	&RFC8460;
	&RFC8482;
      <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"/>

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

        <reference anchor="dnswl.org" anchor="DNSWL" target="https://www.dnswl.org/">
          <front>
			<title>DNSWL.ORG</title>
            <title>dnswl.org - E-Mail Reputation – Protect against false
	    positives</title>
          <author/>
			<date/>
          </front>
        </reference>

        <reference anchor="NFC"
		   target="https://www.unicode.org/reports/tr15/tr15-50.html">
          <front>
            <title>Unicode Normalization Forms</title>
            <author initials="K." surname="Whistler" fullname="Ken Whistler"
		    role="editor">
                <organization />
            </author>
            <date month="February" year="2020" />
          </front>
        <seriesInfo name="Unicode Standard Annex" value="15" />
	</reference>

      </references>
    </references>

    <section anchor="example" title="Example">
	<figure align="center"><artwork><![CDATA[ numbered="true" toc="default">
      <name>Example</name>
<figure>
<name>Trace Fields at the Top of the Header</name>
<sourcecode name="" type=""><![CDATA[
Delivered-To: recipient@example.org
Return-Path: <sender@example.com>
Authentication-Results: mta.example.org;
  dkim=pass (whitelisted) header.i=@example.com
Authentication-Results: mta.example.org;
  dnswl=pass dns.zone=list.dnswl.example dns.sec=na
  policy.ip=127.0.10.1
  policy.txt="fwd.example https://dnswl.example/?d=fwd.example"
Received-SPF: fail (Address does not pass Sender Policy Framework)
  client-ip=2001:db8::2:1;
  envelope-from="sender@example.com";
  helo=mail.fwd.example;
  receiver=mta.example.org;
Received: from mail.fwd.example (mail.fwd.example [2001:db8::2:1])
  (TLS: TLSv1/SSLv3,128bits,ECDHE-RSA-AES128-GCM-SHA256)
  by mta.example.org with ESMTPS; Thu, 03 Oct 2019 19:23:11 +0200
  id 00000000005DC044.000000005702D87C.000007FC
]]></artwork><postamble>
	Trace fields at the top of the header
	</postamble></figure>
]]></sourcecode>
</figure>
      <t>The message went through a third party, fwd.example, which forwarded
      it to the final MTA.  Such  The mail path was not arranged beforehand with
      the involved MTAs, MTAs; it emerged spontaneously.  This message would not
      have
      made it to the target without whitelisting, because:<list style="symbols">
	<t>the because:</t>
      <ul>
        <li>the author domain published a strict SPF policy (-all),</t>
	<t>the (-all),</li>
        <li>the forwarder did not alter the bounce address, and</t>
	<t>the and</li>
        <li>the target usually honors reject-on-fail, reject on fail, according to Section 8.4 of <xref target="RFC7208"/>.</t></list></t>
	target="RFC7208" sectionFormat="of" section="8.4"/>.</li>
      </ul>
      <t>However, the target also implemented the last paragraph of Appendix
	D.3 of <xref target="RFC7208"/>.
      target="RFC7208" sectionFormat="of" section="D.3"/>.  Its behavior
      hinges on the following DNS entries:</t>

	<figure><artwork><![CDATA[
<figure>
<name>DNS Resource Records for 2001:db8::2:1
                (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.
                                               list.dnswl.example.
       IN  A    127.0.10.1
       IN  TXT  "fwd.example https://dnswl.example/?d=fwd.example"

               DNS resource records for 2001:db8::2:1
                (line breaks for editorial reasons)
]]></artwork></figure>
]]></sourcecode>
</figure>
      <t>If mail.fwd.example had connected from address 192.0.2.1, then
      the query name would have been 1.2.0.192.list.dnswl.example. <tt>1.2.0.192.list.dnswl.example</tt>.
      See full description in <xref target="RFC5782"/></t> 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, result and indicated the local policy mechanism
	which
      that was applied in order to override that result.
      Subsequent filtering verified DKIM <xref target="RFC6376"/>.</t> 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 to interpret interpreting the values of policy.ip and weight weighing them against
      other factors so as to make better decisions.</t>
    </section>
    <section anchor="implement" title="Known Implementation"> 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"/> target="Courier-MTA" format="default"/> can be
	configured to lookup DNSBL look up DNSBLs
	and DNSWL, DNSWLs, with similar command line command-line switches:
      </t>

	<figure><artwork><![CDATA[
<sourcecode name=""><![CDATA[
-block=zone[=displayzone][,var[/n.n.n.n][,msg]]
-allow=zone[=displayzone][,var[/n.n.n.n[,]]]
]]></artwork></figure>
]]></sourcecode>
      <t>
		zone
	"zone" is the zone to be queried.
      </t>
      <t>
		displayzone
	"displayzone" is only used for -allow, -allow; it is the value to be set
	in the dns.zone property.
      </t>
      <t>
		var
	"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, 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 to query querying TXT records to be registered in policy.txt.
      </t>

      <t>
	SPF is part of Courier-MTA's core.  It is configured separately, separately
	and provides for an "allowok" keyword to indicate the choice to
	override
	rejection in case of SPF failure and -allow whitelisting.
      </t>

<t>
   A customary whitelist is defined by DNSWL.org <xref target="dnswl.org"/>. target="DNSWL"
   format="default"/>.  It serves A records
   encoded as follows:
		<list>
		<t>1st octect: 127.</t>
		<t>2nd octect: 0.</t>
		<t>3rd octect: Category
</t>

<dl newline="false" spacing="normal">
   <dt>1st octet:</dt><dd>127.</dd>

   <dt>2nd octet:</dt><dd>0.</dd>

   <dt>3rd octet:</dt><dd>Category of business, 15 values.</t>
		<t>4th octect: Trusworthiness/score, values.</dd>

   <dt>4th octet:</dt><dd>Trustworthiness/score, 4 values.</t>
		</list> values.</dd>
</dl>

<t>
   They also serve TXT records containing the domain name followed by an a
   URL pointing to further info information about the relevant organization,
   such as what other IP addresses of theirs are being whitelisted.
   They don't use UTF-8.
</t>

      <t>
		dnswl.org
	DNSWL.org provides for free
	registration and free access below
	100,000 queries per day.
	They use the a special return code code, 127.0.0.255 as exemplified above above,
	to signal over quota. that the quota has been exceeded.

Although Courier-MTA itself does not recognize it, this return code, it has a mail
filter (zdkimfilter, named after its main usage) where recognition
		of that code, as well as that hard codes recognition
of trusworthiness this code and the code for trustworthiness in the 4th octect are hard-coded. octet.
      </t>
    </section>
    <section title="Future possibilities numbered="true" toc="default">
      <name>Future Possibilities of the 'dns' ptype"> ptype</name>
      <t>
	The description of the new ptype proposed in <xref target="ptype"/>
		just says target="ptype"
	format="default"/>
	says, "The property being reported belongs to the Domain Name
		System".
	System."  That definition can broadly include any tag found in a
	domain's TXT record.  For example, auth methods 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>

	<figure><artwork><![CDATA[
<sourcecode name="" type=""><![CDATA[
Authentication-Results: example.com;
  spf=pass smtp.mailfrom=example.net dns.sec=y;
  dkim=pass header.i=@example.org header.b=jIvx30NG dns.s=tlsrpt
]]></artwork></figure>
]]></sourcecode>
      <t>
	While dns.sec is defined above, albeit not for the spf method,
	the use of tlsrpt in the DKIM record is exemplified in
		Section 3 of
	<xref target="RFC8460"/>. target="RFC8460" sectionFormat="of" section="3"/>.
	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. DKIM signature.  Just
	like the latter can be reported as header.s because the DKIM
	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
	DNS.
      </t>
      <t>
	NOTE: This is only a hint at what may become a consistent naming
	convention around the new ptype.  In any case, any new property
	using this ptype requires its own formal definition.  This document
	does NOT define the property dns.s=, let alone the service tlsrpt.
      </t>
    </section>

</back>
</rfc>