All Alessandro had some very good suggestions, but I was looking at the document, there were a few other mentions of PSL and I wanted to think it through.
I have some suggested text I'd like to hear some feedback on. First though, in going over the document again, I also found where the word "from" was repeated twice in Appendix C.2, and I updated the reference to RFC5226 with RFC8126 --- In the Introduction, the suggested change is OLD 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. NEW 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 http://publicsuffix.org [1]. The document never points to the current PSL, only to 7489. What I'm adding is more informative to assist folks reading this who are not immersed in DMARC. OLD This document specifies experimental updates to the DMARC and PSL algorithm cited above, in an attempt to mitigate this abuse. NEW This document specifies experimental updates to the DMARC specification cited above, in an attempt to mitigate this abuse. In Section 1.1 "Example" OLD 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 precluded by the current DMARC algorithm. NEW Defensively registering all variants of "tax" is obviously 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. In section 1.2 "Discussion", this will change. OLD o Branded PSDs (e.g., ".google"): These domains are effectively Organizational Domains as discussed in [RFC7489]. They control all subdomains of the tree. These are effectively private domains, but listed in the Public Suffix List. They are treated as Public for DMARC purposes. NEW o Branded PSDs (e.g., ".google"): These domains are effectively Organizational Domains as discussed in [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. In Appendix B.3, the "PSD Extension" is slightly changed. OLD [psddmarc.org] provides a PSL like file to facilitate identification of PSD DMARC participants. Contents are functionally identical to the IANA like registry, but presented in a different format. NEW [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. ---- Welcome feedback thanks tim On Sat, Mar 20, 2021 at 7:41 AM Alessandro Vesely <[email protected]> wrote: > On Sat 20/Mar/2021 01:38:40 +0100 Tim Wicinski wrote: > >> NEW > >> o Branded PSDs (e.g., ".google"): These domains are effectively > >> Organizational Domains as discussed in [RFC7489]. They control > >> all subdomains. These are effectively private > >> domains, but listed in the 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. > >> > > Hmm, "Public Suffix List" is in this paragraph. Needs rethinking. > > > Oops, I missed a couple of those "Public Suffix List" entries. That term > was > where the conundrum stemmed from, possibly because we're unsure how much > we > want to bind DMARC to the only PSL implementation we know. That's why we > want > to avoid that term. > > OTOH, the term "Public Suffix Domain" (PSD), seems to be sound. It is > often > defined as "a domain under which multiple parties that are unaffiliated > with > the owner of the public suffix domain may register subdomains." We can > say > that a domain "formally is a PSD" rather than it "is listed in the PSL". > The > faint semantic difference between the two phrases is the source of the > conundrum. > > Being a PSD refers to a kind of contract. ICANN mentions the above > definition > in a Policy Update issue[*], referring it to an expired IETF draft. > Should our > I-D include such a definition? > > > Best > Ale > -- > > [*] > ICANN Policy Update | Volume 15, Issue 5 | Pre-ICANN53, June 2015 > https://www.icann.org/resources/newsletter/policy-update-2015-06-16-en > > > > > > > > > > > > > > > > > > >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
