On Saturday, January 29, 2022 3:48:46 PM EST John R Levine wrote: > >> Since a PSD can't be an organizational domain, I don't think that's going > >> to work. > > > > Please provide the foundation to this assertion, because I believe the > > text > > I've offered makes your premise wrong. > > Then it's lucky we caught this mistake now, isn't it? > > See RFC 9091, section 1.
Or even RFC 7489. On the topic of if the process for discovering the organizational domain goes into DMARCbis or into a separate draft, I care far more that the chairs tell us what we're doing and we quit arguing about it than what the actual answer is. I have a slight preference for a separate document (which I would be happy to edit if that's the direction go), but I can see arguments either way. Independent of where it's documented, I think the text of both RFC 7489 and RFC 9091 makes it clear that the "PSD" domains are not organizational domains. Let's start with RFC 7489: In section 3, there is a textual definition: > Organizational Domain: The domain that was registered with a domain > name registrar. In the absence of more accurate methods, > heuristics are used to determine this, since it is not always the > case that the registered domain name is simply a top-level DNS > domain plus one component (e.g., "example.com", where "com" is a > top-level domain). The Organizational Domain is determined by > applying the algorithm found in Section 3.2. In section 3.2, there is a definition of how to determine if something is an organizational domain: > 3.2. Organizational Domain > > The Organizational Domain is determined using the following > algorithm: > > 1. Acquire a "public suffix" list, i.e., a list of DNS domain names > reserved for registrations. Some country Top-Level Domains > (TLDs) make specific registration requirements, e.g., the United > Kingdom places company registrations under ".co.uk"; other TLDs > such as ".com" appear in the IANA registry of top-level DNS > domains. A public suffix list is the union of all of these. > Appendix A.6.1 contains some discussion about obtaining a public > suffix list. > > 2. Break the subject DNS domain name into a set of "n" ordered > labels. Number these labels from right to left; e.g., for > "example.com", "com" would be label 1 and "example" would be > label 2. > > 3. Search the public suffix list for the name that matches the > largest number of labels found in the subject DNS domain. Let > that number be "x". > > 4. Construct a new DNS domain name using the name that matched from > the public suffix list and prefixing to it the "x+1"th label from > the subject domain. This new name is the Organizational Domain. > > Thus, since "com" is an IANA-registered TLD, a subject domain of > "a.b.c.d.example.com" would have an Organizational Domain of > "example.com". > > The process of determining a suffix is currently a heuristic one. No > list is guaranteed to be accurate or current. Based on those rules, a PSD is not an organizational domain. In fact, this is in section 3.1.1: > However, a DKIM signature bearing a value of "d=com" would never > allow an "in alignment" result, as "com" should appear on all public > suffix lists (see Appendix A.6.1) and therefore cannot be an > Organizational Domain. Based on both the definitions and the specific statement, I think it's clear that what we later defines as PSDs are not organizational domains according to RFC 7489. Did RFC 9091 experimentally change this? As John suggested, the introduction to RFC 9091 explicitly addresses this question: > 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, subdomains of Organizational Domains, or PSDs. A PSD can > only publish DMARC policy for itself and not for any subdomains 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. Here is the RFC 9091 definition of organizational domain: > 2.3. Organizational Domain > > The term "Organizational Domain" is defined in Section 3.2 of > [RFC7489]. I don't find anything in RFC 9091 that suggests anything different. So going back to Dave's proposed text that started the thread: On Saturday, January 29, 2022 1:11:29 PM EST Dave Crocker wrote: > Here is some alternative phrasing: > For DMARC, an Organizational Domain can contain a DMARC record, to > be used as the default DMARC record for subordinate domains that do > not have a DMARC record of their own, and for subordinate domains > that do not exist. I don't think that is consistent with either RFC 7489 or RFC 9091. I don't think what is in the current draft is great either. RFC 7489 distinguished between the definition of organizational domain and how you find the organizational domain. I think that distinction is useful. I think the DMARCbis draft would be improved by going back to the RFC 7489 definition and there being a separate discussion on how on determines an organizational domain either in a separate draft or in DMARCbis [chairs: please tell us what you want]. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
