Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-psd-06.txt

From: [email-masked]
Date: Fri, 09 Aug 2019 23:47:36 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF.

        Title           : DMARC (Domain-based Message Authentication, Reporting, and Conformance) Extension For PSDs (Public Suffix Domains)
        Author          : Scott Kitterman
	Filename        : draft-ietf-dmarc-psd-06.txt
	Pages           : 14
	Date            : 2019-08-09

Abstract:
   DMARC (Domain-based Message Authentication, Reporting, and
   Conformance) is a scalable mechanism by which a mail-originating
   organization can express domain-level policies and preferences for
   message validation, disposition, and reporting, that a mail-receiving
   organization can use to improve mail handling.  The design of DMARC
   presumes that domain names represent either nodes in the tree below
   which registrations occur, or nodes where registrations have
   occurred; it does not permit a domain name to have both of these
   properties simultaneously.  Since its deployment in 2015, use of
   DMARC has shown a clear need for the ability to express policy for
   these domains as well.

   Domains at which registrations can occur are referred to as Public
   Suffix Domains (PSDs).  This document describes an extension to DMARC
   to enable DMARC functionality for PSDs.

   This document also seeks to address implementations that consider a
   domain on a public Suffix list to be ineligible for DMARC
   enforcement.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dmarc-psd-06
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-psd-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-psd-06

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 10 Aug 2019 02:49:29 -0400

On Saturday, August 10, 2019 2:47:36 AM EDT [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Domain-based Message
> Authentication, Reporting & Conformance WG of the IETF.
> 
>         Title           : DMARC (Domain-based Message Authentication,
> Reporting, and Conformance) Extension For PSDs (Public Suffix Domains)
> Author          : Scott Kitterman

Note the updated abstract and please review the changes to the first part of 
the introduction as I had to write new text there and not just incorporate 
msk's comments.  This covers all the pending work of which I am aware.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 10 Aug 2019 12:36:36 +0200

> msk's comments.  This covers all the pending work of which I am aware.

The intro looks smooth.  Perhaps, for maximum clearness, you could add a sentence after the first one of the second paragraph:

   As an example, imagine a country code TLD (ccTLD) which has public
   subdomains for government and commercial use (.gov.example and
   .com.example).  They are both on the public suffix list, although
   gov.example is not really available for public registrations, domains
   under it belong to different branches of the government.  Suppose
   there exists a registered domain "tax.gov.example" that is responsible
   for taxation in this imagined country.  [...]

Excuse me, but I hadn't noted the following in Murray's message of Aug 1st:

   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 [RFC7489]:

   Note that domain names that appear on a public suffix list are not
   exempt from DMARC policy application and reporting.

First, it's not easy to read, as the concept of PSL "used by the receiver", albeit obvious, is new.  The whole idea is better expressed by the last three lines in the abstract.

Second, Section 6.6.1 of RFC 7489 deals with the uniqueness of the From: domain.  The idea of a PSL is brought forward in a subsequent section (policy discovery).  If the note has to go there, I'd rather insert it between the first and the second paragraphs of that section.  The last paragraph there seems to conflict with the second bullet, and adding the note above after it is not going to make things clearer.

The next section has:

   As an example, for a message with the Organizational Domain of
   "example.compute.cloudcompany.com.example", the query for PSD DMARC
   would use "compute.cloudcompany.com.example" as the longest PSD
   (Section 2.3).  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".

It is not natural to spot which is the organizational domain, because the names are misleading.  Cloudcompany looks like a name registered under the com.example PSD; how come compute.cloudcompany.com.example is the longest PSD?  I'd stick with the gov.example introduced earlier.

jm2c
Ale
--