Subject: Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 18 Jan 2021 22:43:01 -0800

In the interests of getting this document on its way, I'd like to suggest
the following edits in response to Dale's most recent message.  If the
working group concurs, we can finally get this out to Last Call.

My goal as an AD here is just to get the GenART feedback addressed, but the
text is being submitted as a WG contribution for discussion and consensus
consideration, not as a demand.   Please process accordingly; I believe the
agreement is to do another WGLC on the document before it goes on its way,
so the sooner consensus is reached on all of this, the sooner it goes.

First, a suggestion of my own that I think I saw elsewhere, but it's not in
Dale's reply: In several places there's a reference to "DMARC [RFC7489]".
That's appropriate the first time the reference is made, but I think after
that you can just say "DMARC" when referring to the protocol generally, or
to "RFC 7489" when you need to make a specific section or text reference.
They don't need to appear together everywhere.

I think Dave's original feedback has been addressed -- good stuff -- so
here are my suggestions around what's left:

On Mon, Nov 16, 2020 at 7:16 PM Dale R. Worley <[email-masked]> wrote:

> My apologies for not tending to this promptly.
>
> In regard to the description of the experiments, the result criteria are
> rather subjective, but I don't see that as a problem.  It does seem to
> me that the title "PSD DMARC Privacy Concern Mitigation Experiment" is
> too narrow, as only the 3rd experiment seems to be about privacy
> issues.  A title as generic as "PSD DMARC Experiments" would be fine.
>

That's OK with me, or "DMARC PSD Experiments" or "DMARC PSD Experiment" if
we want to treat it all as one common thing.

> Although I note that even the -09 does not define "PSD", only "longest
> PSD", even though "PSD" is used in section 2.5.  I suspect that PSD is
> equal to "PSO Controlled Domain Name", though, or rather to some related
> set of them.  That needs to be cleaned up in some way.
>

PSD appears to be well defined in Section 2.2.

In section 3.5 and later there is the phrase "[this document] longest
> PSD".  I'm not sure, but I think this is supposed to be "longest PSD
> ([this document] section NN.NN)".
>

Agreed.

I believe that my strongest critique was that section 1 is difficult to
> understand if one does not already understand DMARC, and it does not
> seem that the section has been revised.  Re-reading it, I notice that it
> says "DMARC leverages public suffix lists to determine which domains are
> organizational domains."  Ignoring that I dislike this use of
> "leverage", a critical point is that it takes the existence of public
> suffix lists a priori -- indeed, this use of "leverage" generally means
> that the leveraged thing already exists and one is now extracting
> additional benefit from that.  Whereas I've never heard of public suffix
> lists and would naively expect that they are difficult to create and
> maintain.  It might be better to say "DMARC uses public suffix lists to
> determine which domains are organizational domains.  Public suffix lists
> are obtained/maintained/distributed by ..."
>

Replace all of Section 1 with this (ignore funny line wrapping):

   DMARC [RFC7489 <https://tools.ietf.org/html/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.

   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.

   DMARC as specified presumes that domain names present in a PSL are not
   organizational domains and thus not subject to DMARC processing; domains
   are either organizational domains, sub-domains of organizational
   domains, or listed on a PSL.  For domains listed in a
   PSL, i.e., TLDs and domains that exist between TLDs and
   organization level domains, policy can only be published for the
   exact domain.  No method is available for these domains to express
   policy or receive feedback reporting for sub-domains.  This missing
   method allows for the abuse of non-existent organizational-level
   domains and prevents identification of domain abuse in email.

   This document specifies experimental updates to the DMARC and PSL
algorithm cited
   above, in an attempt to mitigate this abuse.

Looking at the second paragraph of section 1, I notice that despite all
> the special terms for classifying domain names in section 2, the example
> in this section does not describe which of the domain names that it
> mentions fall into which of these classes.  E.g. "tax.gov.example" is
> said to be registered, but it looks like it is also the organizational
> domain, and "gov.example" is its longest PSD.  It would also help to
> mention that "tax.gov.example" is "registered at" "gov.example" to
> introduce the details of the usage "registered at".
>
>     Suppose there exists a domain "tax.gov.example" (registered at
>     "gov.example") ...
>

Introduce a new Section 1.1: "Example" with this:

   As an example, imagine a country code TLD (ccTLD) which has public
   subdomains for government and commercial use (".gov.example" and
   ".com.example").  A PSL whose maintainer is aware of this country's
domain structure
   would include entries for both of these in the PSL, indicating that they are
   PSDs below which registrations can occur.  Suppose further that
there exists a domain
   "tax.gov.example", registered within ".gov.example", that is
   responsible for taxation in this imagined
   country.

   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.

   Within the
   ".gov.example" public suffix, use of DMARC has been mandated, so
   "gov.example" publishes the following DMARC DNS record:

   [remainder of -09's page 3, the example, unchanged]
Introduce a new Section 1.2: "Discussion" comprising the remainder of
-09's Section 1.  In the first paragraph, between "simple" and
"extension", add "experimental".

A suggestion for 2.4:

NEW:

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.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 19 Jan 2021 11:30:38 +0100

On Tue 19/Jan/2021 07:43:01 +0100 Murray S. Kucherawy wrote:
> [...]

+1

> PSD appears to be well defined in Section 2.2.

+1

>> ([this document] section NN.NN)".

I guess "[this document]" refers to the RFC number to be.  I think it's useless 
and can be safely removed, all of the five occurrences of it.

It is clearer and more useful to specify the referred document when it is /not/ 
this document.  For example:

     Changes in Section 6.5 of RFC 7489 "Domain Owner Actions"

The above is going to be rendered with the correct anchor in the htmlized 
version of the document.  It can be expressed in xml as:

     <xref target="RFC7489" sectionFormat="of" section="6.5"/>

so as to generate correct links whenever possible.

>> organizational domains."  [...]

In fact, those are the two terms appearing in the title.  BTW, I'd change the 
title to:

     Domain-based Message Authentication, Reporting, and Conformance (DMARC)
     Extension For Public Suffix Domains (PSDs)

Anyway, I agree it is correct to introduce /both/ terms.

>     and their sub-domains within a single organization.

+1 to break the paragraph here.

>     The process for doing this can be found in Section 3.2 of the DMARC

Couldn't we skip that kind of functional intro and say something general, such 
as anticipating Section 2.2:

     Public Suffix Domains (PSDs) are domain names publicly accessible for
     domain registration.  As explained in Section 2.2, they include all top
     level domains and some more.  The way delegations occur on the global
     Internet makes it difficult to establish whether a domain is a PSD.  A
     community maintained Public Suffix List (PSL) exists for that purpose.

Thinking twice, perhaps we don't need to introduce the PSL until Section 3.4. 
In that case, strike the last two sentences of the above paragraph.

>     exact domain.

That's still overly specific for an introduction.  It only serves to present 
the concept that there are domains that are not actually organizational domains 
but are characterized by a sort of organizational flavor.  The "these domains" 
of the following sentence.  We don't need seven lines of text for that.

>     No method is available for these domains to express
>     algorithm cited above, in an attempt to mitigate this abuse.

If the PSL is not yet introduced:

     This document specifies experimental updates to DMARC and its policy
     discovery, in an attempt to mitigate this abuse.

> Introduce a new Section 1.1: "Example" with this:

I don't fully agree.  The example only lasts until the end of page 3.  From 
page 4 on, the text describes the core of the experiment, so it shouldn't be 
under an "Example" heading.  If we skip the PSL, the example remains quite 
compact even after adding those "registered at".

> It names the immediate parent node of the Organizational Domain in the

s/one/the leftmost/

Best
Ale
--

---

From: Douglas Foster <[email-masked]>
Date: Tue, 19 Jan 2021 07:34:14 -0500

I raised objections to the definition of "non-existent", which never
received an adequate response before the discussion went silent.

DMARC checks the From  header address, which may exist only as an
identifier used for mass mailings.   These mailings are often sent by an
ESP using an unrelated SMTP address.    As such, the From address need not
be associated with any A, AAAA, or MX record.    I assert that the only
viable definition of non-existent is "not registered", as evidenced by
absence of an NS record.

I don't believe the proposed definition of "non-existent" is reliably true
even in the special case of interest for this document, impersonation fraud
occurring at the top of an organizational structure.   Example.PSD may
legitimately use mail.Example.PSD for email and www.example.psd for web.
 If the proposed condition MUST always be true, I have not seen that fact
demonstrated.   Since the document raises a general concern about
fraudulent use of non-existent domains, the definition used should be one
that can be generalized.,

Doug Foster

On Tue, Jan 19, 2021 at 1:43 AM Murray S. Kucherawy <[email-masked]>
wrote:

> My goal as an AD here is just to get the GenART feedback addressed, but
> the text is being submitted as a WG contribution for discussion and
> consensus consideration, not as a demand.   Please process accordingly; I
> believe the agreement is to do another WGLC on the document before it goes
> on its way, so the sooner consensus is reached on all of this, the sooner
> it goes.
>
> First, a suggestion of my own that I think I saw elsewhere, but it's not
> in Dale's reply: In several places there's a reference to "DMARC
> [RFC7489]".  That's appropriate the first time the reference is made, but I
> think after that you can just say "DMARC" when referring to the protocol
> generally, or to "RFC 7489" when you need to make a specific section or
> text reference.  They don't need to appear together everywhere.
>
>    DMARC [RFC7489 <https://tools.ietf.org/html/rfc7489>] provides a mechanism for publishing organizational
>    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.
>
>    This document specifies experimental updates to the DMARC and PSL algorithm cited
>    ".com.example").  A PSL whose maintainer is aware of this country's domain structure
>    PSDs below which registrations can occur.  Suppose further that there exists a domain
> Introduce a new Section 1.2: "Discussion" comprising the remainder of -09's Section 1.  In the first paragraph, between "simple" and "extension", add "experimental".
>
> A suggestion for 2.4:
>
> NEW:
>
> 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.
>
> -MSK
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 19 Jan 2021 06:19:11 -0800

> and can be safely removed, all of the five occurrences of it.

That's fine too.

> Anyway, I agree it is correct to introduce /both/ terms.

I think that's needlessly verbose.  A compromise:

"Experimental DMARC Extension for Public Suffix Domains"

> In that case, strike the last two sentences of the above paragraph.

It's not obvious to me that this is better, but sure, let's discuss it.

> of the following sentence.  We don't need seven lines of text for that.

This is text in -09, not something I'm adding.  Apparently this context was
valuable before.

> compact even after adding those "registered at".

I don't think you read my suggestion correctly.  I proposed a new Section
1.2 to contain the text you're talking about.  You cited it below but
appear to have missed it.

> > It names the immediate parent node of the Organizational Domain in the

Sure.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 19 Jan 2021 06:23:42 -0800

> viable definition of non-existent is "not registered", as evidenced by

This is a discussion of DMARC, not of PSD, right?  DMARC defines this test
in an Appendix, and then makes it non-mandatory.  PSD says to apply that
test for domains that request it.

Hooking this test up to registration requires introducing RDAP or something
similar.  Is that what we're talking about here?

> that can be generalized.,

This sounds like something that should be solved in DMARC, not PSD, but
naturally consensus wins here, so have at it.

-MSK

---

From: Douglas Foster <[email-masked]>
Date: Tue, 19 Jan 2021 17:11:04 -0500

No Murray, I was speaking to the PSD document.

PSD's entire purpose is to detect abuse of non-existent organizational
domains, so the definition of non-existent is crucial to its success.    I
believe the current language will produce false positives, albeit probably
a small number.    The current language is also more resource-intensive
than mine, although that is not my concern.

I believe this is also a general problem that full DMARC should address.
 If a domain exists but does not have a policy, we interpret this to mean
that the domain owner has not chosen to publish a policy, which is his
right.    If a domain does not exist, then there is no domain owner to
publish a policy and no reason to believe that the use of the domain is
legitimate.   In fact, use of an unregistered domain is a violation of IETF
policy and the entire name registration infrastructure.    Consequently, I
believe that SPF and DMARC SHOULD differentiate between "policy not
specified" and NXDOMAIN.   But to put this topic into play for DMARC, I
need to create a ticket, right?

I also want PSD to use a correct definition of non-existent because it will
establish a precedent for any generalization done as part of the full DMARC
effort.

Doug Foster

On Tue, Jan 19, 2021 at 9:23 AM Murray S. Kucherawy <[email-masked]>
wrote:

> Hooking this test up to registration requires introducing RDAP or
> something similar.  Is that what we're talking about here?
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 19 Jan 2021 15:23:40 -0800

> than mine, although that is not my concern.

What I mean is: If we say PSD experiment participants evaluate the notion
of "non-existent" differently than vanilla DMARC implementations, we have
to account for that when interpreting the results of the experiment.  But
the experiment as crafted is just to determine if the PSD algorithm as
proposed is a useful improvement.  It seems to me that changing the nature
of that test at the same time is scope creep that muddies the waters.

-MSK

---

From: Douglas Foster <[email-masked]>
Date: Wed, 20 Jan 2021 09:39:04 -0500

I am happy to postpone the topic in the interest of moving the experiment
forward.
Ticket 97 has been created to discuss it later.

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 22 Jan 2021 15:34:55 -0500

>    above, in an attempt to mitigate this abuse.
Done

>    [remainder of -09's page 3, the example, unchanged]
done

> 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.
Done

I also changed the title to "Experimental DMARC Extension for Public Suffix
Domains"

I need to go over the next batch.

I have the XML in my repo:
https://github.com/moonshiner/draft-ietf-dmarc-psd/
and will send a pull request when i've gone back over things.

I do attach the rfcdiff I created locally for folks.  that may help

big thanks Murray

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 22 Jan 2021 17:35:56 -0500

> so as to generate correct links whenever possible.

two things:  1) to be accurate I would want to target the section anchor.
But actually the real answer is 2) the RFC editor owns the final XML and I
believe
they perform a bunch of this work during the AUTH48 process.

Now saying that, someone will politely explain how wrong I am.

In fact, those are the two terms appearing in the title.  BTW, I'd change
> the

I went with the Murray;s "Experimental DMARC Extension For Public Suffix
Domains"

And Murray restructured the Intro and it feels much cleaner.

tim

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 22 Jan 2021 18:05:44 -0500

On Tue, Jan 19, 2021 at 9:19 AM Murray S. Kucherawy <[email-masked]>
wrote:

>> Here's the paragraph in question

     <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.</t>

The more I look at this, you need it near the top because that is where the
discussion
of the policy.  But also open to be convinced.

tim

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 22 Jan 2021 15:25:41 -0800

On Fri, Jan 22, 2021 at 3:05 PM Tim Wicinski <[email-masked]> wrote:

>         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.</t>
>
>
>
> The more I look at this, you need it near the top because that is where
> the discussion

Looks good to me where it is.  I would add "(PSL)", introducing the
acronym, right after its first use if we decide to leave it there.

A formatting thing to take care of at some point: Anyplace you refer to
DMARC, the protocol, just have it as "DMARC" (e.g., "not exempt from DMARC
policy"); anyplace you refer to DMARC, the specification (e.g., "Section
a.b.c of DMARC" or similar), it should be the <xref target="..."> ...
</xref> sorta deal so that it pops out as a reference.

-MSK, hatless

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 22 Jan 2021 18:28:32 -0500

> acronym, right after its first use if we decide to leave it there.

Will do

> </xref> sorta deal so that it pops out as a reference.
Argh yes - I was removing the RFC7489 references which had the XML  bits.
 oh let me do that fix up

tim

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 22 Jan 2021 16:55:05 -0800

>         List. The process for doing this can be found in Section 3.2 of

The concern that I have with this wording is that it is (potentially)
misleading. "How" DMARC determines the org domain does not matter at all to
this spec. The important point is that we go to "org-1" in the tree for
this extra lookup.

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 22 Jan 2021 16:57:00 -0800

> this spec. The important point is that we go to "org-1" in the tree for

This is just establishing context for why we're doing what the rest of the
document says (i.e., what problem we're solving).  Leaving this out seems
to me to paint an incomplete picture; Section 3 basically describes a
delta, but a delta to what?

-MSK

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 22 Jan 2021 16:58:22 -0800

On Fri, Jan 22, 2021 at 4:57 PM Murray S. Kucherawy <[email-masked]>
wrote:

>>>         and thus where to look for a policy statement, DMARC makes use
>>> of a Public Suffix

And if DMARC changes how it determines the org domain, where does that
leave this spec?

--Kurt

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 22 Jan 2021 20:01:41 -0500

Kurt

Since this is an experiment, Appendix A discusses the updates that happen.
we don't actually say explicitly "if the experiment is a success, the
following changes will be made" and perhaps I should add some wording like
that.

On Fri, Jan 22, 2021 at 7:58 PM Kurt Andersen (b) <[email-masked]> wrote:

>> This is just establishing context for why we're doing what the rest of
>> the document says (i.e., what problem we're solving).  Leaving this out
>> seems to me to paint an incomplete picture; Section 3 basically describes a

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 22 Jan 2021 17:33:13 -0800

> And if DMARC changes how it determines the org domain, where does that

Do we need more than the reference(s) to RFC 7489?

-MSK

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 22 Jan 2021 21:44:05 -0500

(this is really for Murray)

> </xref> sorta deal so that it pops out as a reference.
So the xref for RFC7489 were created of this form:

<xref target="RFC7489">DMARC</xref>

and submitted into the submission system, the HTML document will have this look:

DMARC [RFC7489]   (Link is mapped to [RFC7489])

and the HTML is

[<a href="./rfc7489" title="&quot;Domain-based Message Authentication,
Reporting, and Conformance (DMARC)&quot;">RFC7489</a>]However, when I
run xml2rfc (v3.5.0) locally the

However, when I run xml2rfc (v3.5.0) locally, the HTML shows the text
"DMARC" as a link

and the HTML is

<a href="#RFC7489" class="xref">DMARC</a>

So this makes my brain hurt. I'm going to revisit this in the morning.

tim

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 22 Jan 2021 20:13:03 -0800

On Fri, Jan 22, 2021 at 6:44 PM Tim Wicinski <[email-masked]> wrote:

> [<a href="./rfc7489" title="&quot;Domain-based Message Authentication, Reporting, and Conformance (DMARC)&quot;">RFC7489</a>]However, when I run xml2rfc (v3.5.0) locally the
>
>
> However, when I run xml2rfc (v3.5.0) locally, the HTML shows the text "DMARC" as a link
>
> and the HTML is
>

For the ones that should actually be document references, try just <xref
target="RFC7489"/>.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 23 Jan 2021 12:28:45 +0100

On Sat 23/Jan/2021 01:55:05 +0100 Kurt Andersen (b) wrote:
>>      <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.</t>
>>
> 

+1.  If we don't assume that readers already know what the PSL is, trying to 
establish that context in the Introduction is only a complication.  Later on, 
when Section 3 explains technicalities, the PSL has full citizenship.

jm2c
Ale
--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 23 Jan 2021 16:48:55 -0800

> when Section 3 explains technicalities, the PSL has full citizenship.

In the interest of getting this done finally, could you or Kurt please
propose specific changes, maybe in OLD/NEW form, that you think fixes the
problem?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 28 Jan 2021 22:44:19 -0800

On Fri, Jan 22, 2021 at 5:01 PM Tim Wicinski <[email-masked]> wrote:

> Since this is an experiment, Appendix A discusses the updates that
> happen.  we don't actually say explicitly "if the experiment is a success,
> the following changes will be made" and perhaps I should add some wording
> like that.
>

Something like this, perhaps?

"A standards track update to [RFC7489] will take into account the results
of this experiment."

... somewhere in Section 1.

-MSK

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 29 Jan 2021 09:52:31 -0500

I suggest adding it to this paragraph:

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 29 Jan 2021 08:21:19 -0800

>    algorithm cited above, in an attempt to mitigate this abuse.

update to DMARC = yes; update to PSL = no

>> ... somewhere in Section 1.
A normative dependency from an experimental spec imposed upon a standards
track spec seems like a bad idea to me. At the very least it would impose a
timing constraint that DMARCbis could not be "completed" until after the
PSD experiment is "completed", analyzed and consensus achieved.

--Kurt

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 29 Jan 2021 19:11:56 +0100

> update to DMARC = yes; update to PSL = no

It is difficult to propose changes in OLD:/NEW: format.  I attach a patch.  It 
defers mentioning a PSL until Section 3.  That way it may address part of 
Dave's objections as well.

> PSD experiment is "completed", analyzed and consensus achieved.

This could be weakened by saying "*may* take into account".  However, it's not 
needed, as the sentence doesn't say *the next* standards track update...

Best
Ale
-- 

--- draft-ietf-dmarc-psd-tim.xml	2021-01-24 18:50:28.355829817 +0100
+++ draft-ietf-dmarc-psd-ale.xml	2021-01-29 18:58:35.349494946 +0100
@@ -42,14 +42,14 @@
    <keyword>TLD</keyword>
 
    <abstract>
-      <t>DMARC (Domain-based Message Authentication, Reporting, and
-         Conformance) is a scalable mechanism by which a mail-originating
+      <t>Domain-based Message Authentication, Reporting, and
+         Conformance (DMARC) 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
+         organization can use to improve mail handling.</t>
+       <t>Internet domain names can be represented by a tree.  There are nodes below
+         which registrations occur, and nodes where registrations have occurred.
+         DMARC 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.</t>
@@ -57,7 +57,7 @@
          Suffix Domains (PSDs).  This document describes an extension to DMARC
          to enable DMARC functionality for PSDs.</t>
       <t>This document also seeks to address implementations that consider a
-         domain on a public Suffix list to be ineligible for DMARC
+         Public Suffix Domain to be ineligible for DMARC
          enforcement.</t>
    </abstract>
  </front>
@@ -68,42 +68,47 @@
         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.</t>
-     <t>DMARC as specified presumes that domain names present in a PSL are not
+     <t>Representing Internet domain names in a tree, Public Suffix Domains (PSD)
+        are those right below or near to the top of the tree, which is the root.
+        DMARC allows Organizational Domains, which are those right below a PSD,
+        to publish a policy.  Subdomains can publish their policy too,
+        overriding the policy of their Organizational Domain.  However,
+        PSD currently cannot.  In other words,
+        DMARC as specified presumes that PSDs are not
         organizational domains and thus not subject to DMARC processing; domains
         are either organizational domains, sub-domains of organizational
-        domains, or listed on a PSL.  For domains listed in a
-        PSL, i.e., TLDs and domains that exist between TLDs and
+        domains, or PSDs.  For a
+        PSD, i.e., TLDs and domains that exist between TLDs and
         organization level domains, policy can only be published for the
         exact domain.  No method is available for these domains to express
         policy or receive feedback reporting for sub-domains.  This missing
         method allows for the abuse of non-existent organizational-level
         domains and prevents identification of domain abuse in email.</t>
-     <t>This document specifies experimental updates to the DMARC and PSL
-        algorithm cited above, in an attempt to mitigate this abuse.</t>
+     <t>This document specifies experimental updates to DMARC and to the
+        algorithm to locate Organizational Domains, in an attempt to mitigate this abuse.
+        A standards track update to <xref target="RFC7489"/> will take
+        into account the results of this experiment.</t>
    <section anchor="example" title="Example">
      <t>As an example, imagine a country code TLD (ccTLD) which has public
         subdomains for government and commercial use (".gov.example" and
-        ".com.example").  A PSL whose maintainer is aware of this country's
-        domain structurewould include entries for both of these in the PSL, indicating that they are PSDs below which registrations can occur.
+        ".com.example").
         Suppose further that there exists a domain "tax.gov.example",
         registered within ".gov.example", that is responsible for taxation
         in this imagined country.</t>
-     <t>However, by exploiting the typically unauthenticated nature
+     <t>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:
+     <t>The domain "gov.example" is a PSD, albeit presumably only qualified
+        organizations can register domains under it.  Use of DMARC has
+        been mandated for domains published under it.
+        so "tax.gov.example" publishes the following DMARC DNS record:
          <figure><artwork>
 _dmarc.gov.example. IN TXT ( "v=DMARC1; p=reject; "
                              "rua=mailto:[email-masked]" )
         </artwork></figure>
          This DMARC record provides policy and a reporting destination for
-         mail sent from @gov.example. However, due to DMARC's current method
+         mail sent from @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.
@@ -111,7 +116,7 @@
      <t> Defensively registering all variants of "tax" is obviously not a scalable
          strategy.  The intent of this specification, therefore, is to enhance the
          DMARC algorithm by enabling an agent receiving such a message to be able to
-         determine that a relevant policy is present at "gov.example", which is
+         determine whether a relevant policy is present at "gov.example", which is
          precluded by the current DMARC algorithm.
      </t>
    </section>
@@ -153,7 +158,7 @@
                       effectively Organizational Domains as discussed in <xref
                       target="RFC7489">DMARC</xref>.  They control all
                       subdomains of the tree.  These are effectively private
-                      domains, but listed in the Public Suffix List.  They are
+                      domains, but formally they are PSDs, so they are
                       treated as Public for DMARC
                       purposes.  They require the same protections as DMARC
                       Organizational Domains, but are currently unable to
@@ -245,6 +250,11 @@
 
    <section title="PSD DMARC Updates to DMARC Requirements">
 
+     <t>The algorithm DMARC uses to find the Organizational Domain of a
+        given domain hinges on a Public Suffix List (PSL), which is a list
+        of PSDs, possibly making use of wildcards.  The process is described
+        in Section 3.2 of the DMARC specification.</t>
+
      <t>This document updates DMARC as follows:</t>
 
      <section title="General Updates">

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 29 Jan 2021 19:14:41 +0100

On Fri 29/Jan/2021 19:11:56 +0100 I wrote:
> I attach a patch.

P.S.  It also changed the example slightly.  It sounds wrong as is now.  Pls 
look at that...

Best
Ale
--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 29 Jan 2021 12:03:14 -0800

> update to DMARC = yes; update to PSL = no

Why?

>>> "A standards track update to [RFC7489] will take into account the
>>> results of this experiment."
>>>

I thought that was exactly the intent here.

-MSK