draft-ietf-dmarc-psd.xml

<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<rfc category="exp"
     docName="draft-ietf-dmarc-psd-14"
     ipr="trust200902">

 <front>
   <title abbrev="PSD DMARC">Experimental DMARC Extension For Public Suffix Domains
   </title>

   <author initials="S." surname="Kitterman"
	   fullname="Scott Kitterman">
      <organization>fTLD Registry Services</organization>

      <address>
	 <postal>
	    <street>600 13th Street, NW, Suite 400</street>
	    <city>Washington</city>
	    <region>DC</region>
	    <code>20005</code>
	    <country>United States of America</country>
	 </postal>

	 <phone>+1 301 325-5475</phone>
	 <email>scott@kitterman.com</email>
      </address>
   </author>

  <author role="editor" initials="T." surname="Wicinski" fullname="Tim Wicinski">
    <organization></organization>
    <address>
    <postal>
    <street></street>
    <city>Elkins</city>
    <code>26241</code>
    <country>USA</country>
    <region>WV</region>
    </postal>
    <phone></phone>
    <email>tjw.ietf@gmail.com</email>
    <uri></uri>
    </address>
  </author>

   <date month="May" year="2021" />

   <keyword>DMARC</keyword>
   <keyword>email authentication</keyword>
   <keyword>TLD</keyword>

   <abstract>
      <t>Domain-based Message Authentication, Reporting, and Conformance
         (DMARC) permits a domain-controlling organization to express
         domain-level policies and preferences for message validation,
         disposition, and reporting, which a mail-receiving organization
         can use to improve mail handling.</t>
      <t>DMARC distinguishes the portion of a name that is a
         Public Suffix Domain (PSD), below which
         organizational domain names are created.  The basic DMARC
         capability allows organizational domains to specify policies
         that apply to their subdomains, but it does not give that
         capability to PSDs. This document describes an extension to
         DMARC to fully enable DMARC functionality for PSDs.</t>
      <t>Some implementations of DMARC consider a PSD to be ineligible for
         DMARC enforcement.  This specification addresses that case.</t>

   </abstract>
 </front>

 <middle>
   <section anchor="intro" title="Introduction">
     <t>DMARC <xref target="RFC7489"/> provides a mechanism for publishing
        organizational policy information to email receivers.  DMARC allows policy to be
        specified for both individual domains and for organizational domains
        and their sub-domains within a single organization.</t>
     <t>To determine the organizational domain for a message under evaluation,
        and thus where to look for a policy statement, DMARC makes use of a public suffix
        list. The process for doing this can be found in Section 3.2 of the DMARC
        specification.  Currently, the public suffix list being used is the
        most common one that is maintained by the Mozilla Foundation and made public at
        <eref target="http://publicsuffix.org">http://publicsuffix.org</eref>.</t>
     <t>In the basic DMARC model, Public Suffix Domains (PSDs) are not organizational domains
        and are thus not subject to DMARC processing.  In DMARC, domains
        fall into one of three categories: organizational domains,
        sub-domains of organizational domains, or PSDs.  A PSD can only
        publish DMARC policy for itself, and not for any sub-domains
        under it.  In some cases, this limitation allows for the abuse
        of non-existent organizational-level domains and hampers
        identification of domain abuse in email.</t>
     <t>This document specifies experimental updates to the DMARC
        specification cited above, in an attempt to mitigate this abuse.</t>
   <section anchor="example" title="Example">
     <t>As an example, imagine a Top-Level Domain (TLD), ".example", that has
        public subdomains for government and commercial use (".gov.example"
        and ".com.example").  The maintainer of a list of such a PSD structure
        would include entries for both of these sub-domains, thereby
        indicating that they are PSDs, below which organizational domains can
        be registered.  Suppose further that there exists a legitimate domain
        called "tax.gov.example", registered within ".gov.example".</t>
     <t>However, by exploiting the typically unauthenticated nature
       of email, there are regular malicious campaigns to impersonate this
       organization that use similar-looking ("cousin") domains such as
       "t4x.gov.example".  Such domains are not registered.</t>
     <t>Within the ".gov.example" public suffix, use of DMARC has been mandated,
        so "gov.example" publishes the following DMARC DNS record:
         <figure><artwork>
_dmarc.gov.example. IN TXT ( "v=DMARC1; p=reject;"
                             "rua=mailto:dmc@dmarc.svc.gov.example" )
        </artwork></figure>
       This DMARC record provides policy and a reporting destination for
       mail sent from @gov.example.  Similarly, "tax.gov.example" will have
       a DMARC record that specifies policy for mail sent from addresses
       @tax.gov.example.  However, due to DMARC's current method of
       discovering and applying policy at the organizational domain
       level, the non-existent organizational domain of @t4x.gov.example
       does not and cannot fall under a DMARC policy.

     </t>
     <t> Defensively registering all variants of "tax" is not a scalable
         strategy.  The intent of this specification, therefore, is to enhance the
         DMARC discovery method by enabling an agent receiving such a
         message to be able to determine that a relevant policy is present at
         "gov.example", which is precluded by the current DMARC specification.
     </t>
   </section>
   <section anchor="discussion" title="Discussion">
     <t> This document provides a simple extension to <xref target="RFC7489"/>
         to allow operators of Public Suffix Domains (PSDs) to:
      <list style="symbols">
        <t>Express policy at the level of the PSD that covers all
          organizational domains that do not explicitly publish DMARC records</t>
        <t>Extends the DMARC policy query functionality to detect
            and process such a policy</t>
       <t>Describes receiver feedback for such policies</t>
       <t>Provides controls to mitigate potential privacy considerations
       associated with this extension</t>
     </list>
     </t>
     <t>This document also provides a new DMARC tag
	to indicate requested handling policy for non-existent subdomains.
	This is provided specifically to support phased deployment of PSD
	DMARC, but is expected to be useful more generally.  Undesired
	rejection risks for mail purporting to be from domains that do not
	exist are substantially lower than for those that do, so the
	operational risk of requesting harsh policy treatment (e.g., reject) is
	lower.
     </t>
     <t>As an additional benefit, the PSD DMARC extension clarifies
	existing requirements.  Based on the requirements of <xref
        target="RFC7489"/>, DMARC should function above the
        organizational level for exact domain matches (i.e., if a DMARC record
        were published for "example", then mail from example@example should be
        subject to DMARC processing).  Testing had revealed that this is not
        consistently applied in different implementations.
     </t>
     <t>There are two types of Public Suffix Operators (PSOs) for which this
         extension would be useful and appropriate:
     </t>
         <t><list style="symbols">
                  <t>Branded PSDs (e.g., ".google"): These domains are
                      effectively Organizational Domains as discussed in <xref
                      target="RFC7489"/>.  They control all
                      subdomains of the tree.  These are effectively private
                      domains, but listed in the current public suffix list.
                      They are
                      treated as Public for DMARC
                      purposes.  They require the same protections as DMARC
                      Organizational Domains, but are currently unable to
                      benefit from DMARC.
                  </t>
                  <t>Multi-organization PSDs that require DMARC usage (e.g.,
                      ".bank"):  Because existing Organizational Domains using
                      this PSD have their own DMARC policy, the applicability of
                      this extension is for non-existent domains.  The extension
                      allows the brand protection benefits of DMARC to extend to
                      the entire PSD,
                      including cousin domains of registered organizations.
                  </t>
          </list></t>
     <t>Due to the design of DMARC and the nature
         of the Internet <xref target="RFC5598">email architecture</xref>, there
         are interoperability issues associated with
         DMARC deployment.  These are discussed in <xref target="RFC7960">
         Interoperability Issues between DMARC and Indirect Email Flows</xref>.
         These issues are not typically applicable to PSDs, since they (e.g., the
         ".gov.example" used above) do not typically send mail.
     </t>

   </section>
      </section>

   <section title="Terminology and Definitions">
       <t>This section defines terms used in the rest of the document.
       </t>
       <section title="Conventions Used in This Document">
           <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
               NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
               "MAY", and "OPTIONAL" in this document are to be interpreted as
               described in BCP&nbsp;14 <xref target="RFC2119"/>
               <xref target="RFC8174"/> when, and only when, they appear in all
               capitals, as shown here.
           </t>
       </section>
       <section title="Public Suffix Domain (PSD)">
           <t> The global Internet Domain Name System (DNS) is documented in
               numerous RFCs.  It defines a tree of names
               starting with root, ".", immediately below which are Top Level
               Domain names such as ".com" and ".us".

               The domain name structure consists of a tree of names, each of
               which is made of a sequence of words ("labels") separated by
               period characters.  The root of the tree is simply called ".".
               The Internet community at large, through processes and policies
               external to this work, selects points in this tree at which to
               register domain names "owned" by independent organizations.
               Real-world examples are ".com", ".org", ".us", and ".gov.uk".
               Names at which such registrations occur are called Public
               Suffix Domains (PSDs), and a registration consists of a label
               selected by the registrant to which a desirable PSD is
               appended.  For example, "ietf.org" is a registered domain name,
               and ".org" is its PSD.
           </t>
       </section>
       <section title="Organizational Domain">
           <t> The term Organizational Domains is defined in <xref
                target="RFC7489"/> Section 3.2.</t>
       </section>
       <section anchor="lpsd" title="Longest PSD">
           <t> The longest PSD is the Organizational Domain with one label
               removed. It names the immediate parent node of the Organizational
               Domain in the DNS namespace tree.</t>
       </section>
       <section title="Public Suffix Operator (PSO)">
           <t>A Public Suffix Operator is an organization which manages
              operations within a PSD, particularly the DNS records published
              for names at and under that domain name.
           </t>
       </section>
       <section title="PSO Controlled Domain Names">
           <t>PSO Controlled Domain Names are names in the DNS that are
               managed by a PSO and are not available for use as Organizational
               Domains.  PSO Controlled Domain Names may have one (e.g., ".com")
               or more (e.g., ".co.uk") name components, depending on PSD policy.
           </t>
       </section>
       <section title="Non-existent Domains">
           <t>For DMARC purposes, a non-existent
	      domain is a domain for which there is an NXDOMAIN or NODATA
	      response for A, AAAA, and MX records.  This is a broader definition
	      than that in <xref target="RFC8020"/>.
           </t>
       </section>
   </section>

   <section title="PSD DMARC Updates to DMARC Requirements">

     <t>To participate in this experiment, implementations should
      interpret RFC7489 as follows:</t>

     <section title="General Updates">
         <t>References to "Domain Owners" also apply to PSOs.</t>
     </section>
     <section anchor="genrecfmt" title='Changes in Section 6.3 "General Record Format"'>
	 <t>If this experiment is successful, this paragraph is added to this section.
    A new tag is added after "fo":</t>
	 <t><list style="hanging">
	    <t hangText="np:"> Requested Mail Receiver policy for non-existent
	     subdomains (plain-text; OPTIONAL).  Indicates the policy to be
	     enacted by the Receiver at the request of the Domain Owner.  It
	     applies only to non-existent subdomains of the domain queried and
	     not to either existing subdomains or the domain itself.  Its
	     syntax is identical to that of the "p" tag defined below.  If
	     the "np" tag is absent, the policy specified by the "sp" tag (if
	     the "sp" tag is present) or the policy specified by the "p" tag,
	     if the "sp" tag is not present, MUST be applied for non-existent
	     subdomains.  Note that "np" will be ignored for DMARC records
	     published on subdomains of Organizational Domains and PSDs due to
	     the effect of the DMARC policy discovery mechanism described in
	     DMARC Section 6.6.3.
	    </t>
         </list></t>
	 <t>The following tag definitions from DMARC
	    are updated:
	 </t>
	 <t><list style="hanging">
	    <t hangText="p:">The sentence 'Policy applies to the domain queried
	      and to subdomains, unless subdomain policy is explicitly described
	      using the "sp" tag' is updated to read 'Policy applies to the domain
              queried and to subdomains, unless subdomain policy is explicitly
              described using the "sp" or "np" tags.'
	    </t>
	    <t hangText="sp:">The sentence 'If absent, the policy specified by
	      the "p" tag MUST be applied for subdomains' is updated to read
	      'If both the "sp" tag is absent and the "np" tag is either absent
	      or not applicable, the policy specified by the "p" tag MUST be
	      applied for subdomains.
	    </t>
         </list></t>
     </section>
     <section title='Changes in Section 6.5 "Domain Owner Actions"'>
         <t>In addition to the DMARC domain owner actions, PSOs that require
             use of DMARC and participate in PSD DMARC ought to make that
	         information available to receivers. This document is an experimental
            mechanism for doing so.  See the [this document] <xref
             target="experiment">experiment description</xref>.
         </t>
     </section>
     <section title='Changes in Section 6.6.1 "Extract Author Domain"'>
         <t> Experience with DMARC has shown that some implementations
             short-circuit messages, bypassing DMARC policy application, when
             the domain name extracted by the receiver (from the RFC5322.From)
             is on the public suffix list used by the receiver.  This
             negates the capability being created by this specification.
             Therefore, the following paragraph is appended to Section 6.6.1
             of DMARC:
         </t>
         <t> Note that domain names that appear on a public suffix list are
             not exempt from DMARC policy application and reporting.
         </t>
     </section>
     <section anchor="poldis" title='Changes in Section 6.6.3 "Policy Discovery"'>
         <t>A new step between step 3 and 4 is added:</t>
         <t><list style="hanging">
               <t hangText="3A.">If the set is now empty and the <xref
                   target="lpsd">longest PSD</xref> of the  Organizational
                   Domain is one that the receiver has determined is acceptable
		           for PSD DMARC (discussed in the [this document] <xref
                   target="experiment">experiment description</xref>), the Mail
                   Receiver MUST query the DNS for a DMARC TXT record at the DNS
                   domain matching the [this document] <xref target="lpsd">
                   longest PSD</xref> in
                   place of the RFC5322.From domain in the message (if
                   different).  A possibly empty set of records is returned.
               </t>
         </list> </t>
         <t>As an example, for a message with the Organizational Domain of
             "example.compute.cloudcompany.com.example", the query for PSD DMARC
             would use "compute.cloudcompany.com.example" as the [this document]
             <xref
             target="lpsd">longest PSD</xref>.  The receiver would check to see
             if that PSD is listed in the DMARC PSD Registry, and if so, perform
             the policy lookup at "_dmarc.compute.cloudcompany.com.example".
         </t>
         <t>Note: Because the PSD policy query comes after the Organizational
             Domain policy query, PSD policy is not used for Organizational
             domains that have published a DMARC policy.  Specifically, this
             is not a mechanism to provide feedback addresses (RUA/RUF) when
             an Organizational Domain has declined to do so.
         </t>
     </section>
     <section title='Changes in Section 7 "DMARC Feedback"'>
         <t>If this experiment is successful, this paragraph is added to this section.</t>
         <t> Operational note for PSD DMARC: For PSOs, feedback for non-existent
	     domains is desirable and useful, just as it is for org-level
	     DMARC operators.  See <xref target="privacy"/> of [this document] for
             discussion of Privacy Considerations for PSD DMARC.
         </t>
     </section>
   </section>

   <section anchor="privacy" title="Privacy Considerations">
      <t>These privacy considerations are developed based on the requirements of
          <xref target="RFC6973"/>.
          Additionally, the Privacy Considerations of <xref target="RFC7489"/>
          apply to the mechanisms described by this document.
          If this experiment is successful, this section should be
          incorporated into the Privacy Considerations section as "Feedback leakage".
      </t>
          <t>Providing feedback reporting to PSOs can, in some cases, cause
           information to leak out of an organization to the PSO.
	      This leakage could potentially be utilized as part of a program
	      of pervasive surveillance (See <xref target="RFC7624"/>).  There
	      are roughly three cases to consider:
          </t>
          <t><list style="symbols">
                  <t>Single Organization PSDs (e.g., ".google"), RUA and RUF
		      reports based on PSD DMARC have the potential to contain
		      information about emails related to entities managed by
		      the organization.  Since both the PSO and the
                      Organizational Domain owners are common, there is no
                      additional privacy risk for either normal or non-existent
		      Domain reporting due to PSD DMARC.
                  </t>
                  <t>Multi-organization PSDs that require DMARC usage (e.g.,
                      ".bank"):  PSD DMARC based reports will only be generated
                      for domains that do not publish a DMARC policy at the
                      organizational or host level.  For domains that do publish
                      the required DMARC policy records, the feedback reporting
                      addresses (RUA and RUF) of the organization (or hosts)
                      will be used.  The only direct feedback leakage risk for
		      these PSDs are for Organizational Domains that are out of
		      compliance with PSD policy.  Data on non-existent cousin
		      domains would be sent to the PSO.
                  </t>
                  <t>Multi-organization PSDs (e.g., ".com") that do not mandate
                      DMARC usage:  Privacy risks for Organizational Domains
                      that have not deployed DMARC within such PSDs are
		      significant.  For non-DMARC Organizational Domains, all
		      DMARC feedback will be directed to the PSO.  PSD DMARC is
		      opt-out (by publishing a DMARC record at the
		      Organizational Domain level) instead of opt-in, which would be
		      the more desirable characteristic.  This means that any
		      non-DMARC organizational domain would have its feedback
		      reports redirected to the PSO.  The content of such
		      reports, particularly for existing domains, is privacy
		      sensitive.
                  </t>
          </list></t>
          <t>PSOs will receive feedback on non-existent domains, which may be
              similar to existing Organizational Domains.  Feedback related to
              such cousin domains have a small risk of carrying information
              related to an actual Organizational Domain.  To minimize
              this potential concern, PSD DMARC feedback MUST be limited
              to Aggregate Reports. Feedback Reports carry more detailed
              information and present a greater risk.
          </t>
	  <t>Due to the inherent Privacy and Security risks associated with
	      PSD DMARC for Organizational Domains in multi-organization PSDs
        that do not participate in DMARC, any Feedback Reporting
        related to multi-organizational PSDs MUST be limited
        to non-existent domains
        except in cases where the reporter knows that PSO
	      requires use of DMARC (by checking the DMARC PSD Registry).
	  </t>
   </section>

   <section title="Security Considerations">
      <t> This document does not change the Security Considerations of
          <xref target="RFC7489"/> and <xref target="RFC7960"/>.
      </t>
      <t> The risks of the issues identified in <xref target="RFC7489"/>,
	  Section 12.3, DNS Security, are amplified by PSD DMARC.  In
	  particular, DNS cache poisoning (or Name Chaining), see <xref
	  target="RFC3833"/> for details, consequences are increased because a
	  successful attack would potentially have a much wider scope.
      </t>
      <t> The risks of the issues identified in <xref target="RFC7489"/>,
	  Section 12.5, External Reporting Addresses, are amplified by PSD
	  DMARC.  By design, PSD DMARC causes unrequested reporting of feedback
	  to entities external to the Organizational Domain.  This is discussed
	  in more detail in <xref target="privacy"/>.
      </t>
   </section>

   <section anchor="iana" title="IANA Considerations">
       <t>This section describes actions requested to be completed by IANA.</t>

       <section anchor="iana1" title="Subdomain Policy Tag">
           <t>IANA is requested to add a new tag to DMARC Tag Registry in the Domain-based Message Authentication,
               Reporting, and Conformance (DMARC) Parameters Registry. The "Status" column is
               defined in <xref target="RFC7489"/>Section 11.4.
           </t>
           <t>The entry is as follows:
            <figure><artwork>
+----------+-----------+---------+-------------------------------+
| Tag Name | Reference | Status  | Description                   |
+----------+-----------+---------+-------------------------------+
| np       | this      | current | Requested handling policy for |
|          | document  |         | non-existent subdomains       |
+----------+-----------+---------+-------------------------------+
            </artwork> </figure>
  [RFC EDITOR: Please replace "This document" with the RFC number of this document.]
           </t>
       </section>
   </section>
 </middle>

 <back>
   <references title="Normative References">
      <?rfc include="reference.RFC.2119" ?>
      <?rfc include="reference.RFC.7489" ?>
      <?rfc include="reference.RFC.8174" ?>
   </references>

   <references title="Informative References">
      <?rfc include="reference.RFC.3833" ?>
      <?rfc include="reference.RFC.8126" ?>
      <?rfc include="reference.RFC.5598" ?>
      <?rfc include="reference.RFC.6973" ?>
      <?rfc include="reference.RFC.7624" ?>
      <?rfc include="reference.RFC.7960" ?>
      <?rfc include="reference.RFC.8020" ?>
      <reference anchor="psddmarc.org" target="https://psddmarc.org/">
         <front>
            <title>PSD DMARC Web Site</title>
            <author>
               <organization>multiple</organization>
            </author>
            <date month="April" year="2019" />
         </front>
      </reference>

   </references>

   <section anchor="experiment"
    title="PSD DMARC Privacy Concern Mitigation Experiment">

<t>The experiment being performed has three different questions which are
looking to be addressed in this document. </t>
    <t><list style="symbols">

    <t>Section 3.2 modifies policy discovery to add an additional DNS lookup.
    To determine if this lookup is useful, PSDs will add additional DMARC records
    in place, and will analyze the DMARC reports.  Success will be determined
    if a consensus of PSDs that publish DMARC records are able to collect useful data.</t>
    <t>Section 3.2 adds the "np" tag for non-existent subdomains (DNS NXDOMAIN).
    PSOs wishing to test this will add this flag to their DMARC record, and will
    analyze DMARC reports for deployment.  Success will be determined if
    organizations find explicitly blocking non-existent subdomains domains
    desirable and provide added value. </t>
    <t> Section 4.1 discusses three cases where providing feedback could cause
    information to leak out of an organization.   This experiment will analyze
    the feedback reports generated for each case to determine if there is
    information leakage.</t>
</list></t>

   </section>
   <section anchor="registry" title="DMARC PSD Registry Examples">
	   <t> To facilitate experimentation around data leakage mitigation, samples
	       of the DNS based and IANA like registries are available at
	       <xref target="psddmarc.org"/>.
           </t>
	<section anchor="dnsregistry" title="DMARC PSD DNS Query Service">
	   <t> A sample stand-alone DNS query service is available at <xref
	       target="psddmarc.org"/>.  It was developed based on the contents
	       suggested for an IANA registry in an earlier revision of this draft.
	       Usage of the service is described on the web site.
           </t>
        </section>
        <section anchor="iana2" title="DMARC Public Suffix Domain (PSD) Registry">
	   <t> <xref target="psddmarc.org"/> provides an IANA like DMARC Public
	       Suffix Domain (PSD) Registry as a stand-alone DNS query service.  It
	       follows the contents and structure described below.  There is a Comma
	       Separated Value (CSV) version of the listed PSD domains which is
	       suitable for use in build updates for PSD DMARC capable software.
           </t>
           <t>PSDs that are deploying DMARC and are participating in PSD DMARC
            must register their public suffix domain in this
	       new registry.   The requirement has to be documented in a
	       manner that satisfies the terms of Expert Review, per <xref
	       target="RFC8126"/>.  The Designated Expert needs to confirm that
	       provided documentation adequately describes PSD policy to require
	       domain owners to use DMARC or that all domain owners are part of
	       a single organization with the PSO.
           </t>
           <t>The initial set of entries in this registry is as follows:
            <figure><artwork>
+-------------+---------------+
|    PSD      | Status        |
+-------------+---------------+
| .bank       | current       |
+-------------+---------------+
| .insurance  | current       |
+-------------+---------------+
| .gov.uk     | current       |
+-------------+---------------+
| .mil        | current       |
+-------------+---------------+
            </artwork> </figure>
           </t>
        </section>
        <section anchor="pslplus" title="DMARC PSD PSL Extension">
           <t> <xref target="psddmarc.org"/> provides a file formatted like the
               Public Suffix List (PSL) in order to
               facilitate identification of PSD DMARC participants.  Contents are
               functionally identical to the IANA like registry, but presented in
               a different format.
           </t>
	   <t> When using this approach, the input domain of the extension lookup
               is supposed to be the output domain of the regular PSL lookup, i.e.,
               the organizational domain.  This alternative data approach is
               potentially useful since DMARC implementations already need to be
               able to parse the data format, so it should be easier to implement.
           </t>
        </section>
   </section>

   <section anchor="implementations" title="Implementations">
      <t> There are two known implementations of PSD DMARC available for testing.
      </t>
      <section title="Authheaders Module">
	 <t>The authheaders Python module and command line tool is available
	    for download or installation from Pypi (Python Packaging Index).
         </t>
	 <t>It supports both use of the DNS based query service and download
	    of the CSV registry file from <xref target="psddmarc.org"/>.
         </t>
      </section>
      <section title="Zdkimfilter Module">
	 <t>The zdkimfilter module is a separately available add-on to
            Courier-MTA.
	 </t>
	 <t>Mostly used for DKIM signing, it can be configured to also verify,
            apply DMARC policies, and send aggregate reports.  For PSD DMARC
            it uses the PSL extension list approach, which is available
            from <xref target="psddmarc.org"/>
         </t>
      </section>
   </section>
   <section anchor="thanks" title="Acknowledgements" numbered="no">
      <t> Thanks to the following individuals for their contributions (both
	  public and private) to improving this document.  Special shout out to
	  Dave Crocker for naming the beast.</t>
      <t> Kurt Andersen, Seth Blank, Dave Crocker, Heather Diaz, Tim Draegen,
	  Zeke Hendrickson, Andrew Kennedy, John Levine, Dr Ian Levy, Craig
	  Schwartz, Alessandro Vesely, and Tim Wicinski</t>
    </section>
 </back>
</rfc>