Terms We can use "hybrid" organizations if you prefer, but I thought the public/private distinction matched the PSL list The important point is that any DNS tree can have more than one organizational boundary, so we need to worry about a possible boundary between the FROM domain and a child domain, as well as a possible boundary between a sibling domain and the substring where the sibling names converge. All of that makes the second tree walk necessary, and means that a walk in the upward direction is always preferable.
-- Relaxed Alignment and Second tree walk For relaxed alignment, the rule needs to be that two domains are in relaxed alignment, if the tree walk up, applied independently to each one, finds the same organization domain. This is all that the main body of the document needs to say. Because the tree walk can be relatively expensive, and because a message may have multiple domains to be tested for alignment, it is desirable to optimize the process. The words that you copied from my previous post were a first attempt at describing those optimizations, but it may not need to be completed. We could either develop an appendix which suggests a DNS-optimizing algorithm, or simply observe that DNS optimization should be performed, letting developers decide how it should be done. One of the optimizations is that the alignment test can exit as soon as one aligned domain is found. -- Does a "psd" indicator mean that mail is possible or not? We need to be careful about overloading assumptions into a single token. A public suffix domain will never be used for mail. A private registration domain may or may not be used for mail. Ideally, we want to entity publishing a DMARC "psd" record to clearly indicate whether the related domain sends mail or not. Announcing that a domain never sends mail will provide a stronger repudiation than the next-best option of DMARC fail with p=reject. -- Boundaries We may have three types of organization boundaries: A public registration, the boundary between a PSD and a registered organization. A private registratiion, the boundary between a publicly-registered organization and subdomains that are independent organizations. A partitioned subdomain, where a specific subdomain tree wishes to be treated as independent of the parent organization for alignment purposes, but sibling domains continue to be evaluated as part of the parent.. The first two configurations can be detected by a DMARC record published by the registrar, indicating an organization boundary below, or by the registered organization publishing a DMARC record indicating an organization boundary above. The last configuration can only be identified using a top-of-organization record indicating a boundary above. Defaults To repeat what has been stated previously, a single DMARC record can appear in several roles: - a subdomain-specific record which is not adjacent to an organization boundary - an organization domain record which has a boundary above and organization subdomains below - a registrar record which has an organization boundary below and does not accept mail itself - a private registrar record which has an organization boundary below, is not an organization domain so there is no boundary above, and accepts mail - a private registrar record which has an organization boundary above and below, and also accepts mail. When the record is not flagged, any of these roles are possible, so there is no default. The actual role must be assigned by heuristic. How does anyone propose to explain this complexity with clarity using only "psd=(y,n)"? The statement "psd=n is the default" assumes a simplicity that does not exist. This complexity occurs because not all organization boundaries are PSO registrations. Therefore the fixation on "psd" is inappropriate. We need to explain the different types of organization boundaries that can affect DMARC, and adopt neutral terminology that only refers to PSDs when we are talking about PSO registration points. Doug On Fri, Mar 18, 2022 at 5:40 AM Alessandro Vesely <[email protected]> wrote: > On Thu 17/Mar/2022 23:40:37 +0100 Douglas Foster wrote: > > In the general case, we allow for this possible configuration: > > public suffix domain segments > > <organization boundary> > > organization domain for public registration organization > > subdomains of the organization > > registration point for private registration clients > > <organization boundary> > > organization domain for private registration clients > > subdomains of the client organization > > > I think you mean hybrid cases like us.com, where X.us.com and Y.us.com > are > distinct organizations, and mail from [email protected] is also possible. > > > > If the candidate domain is a parent directly above the FROM organization > > domain, the names are not aligned and no tree walk is necessary. > > > > If the candidate MAILFROM or DKIM domain matches anything between the > FROM > > domain and its organization domain, they are aligned without a second > tree walk. > > > > If the candidate domain is a child directly below the FROM domain, then > a tree > > walk is necessary, to check for an organization boundary. > > > For example, From: [email protected], org=us.com, d=X.us.com should not be > aligned > because there is a boundary in between. Yet, we're unable to find that > boundary. Even using the PSL, us.com, like com alone, shouldn't be a > From: domain. > > Presumably, we should state that if the From: domain has psd=y, then > alignment > must be strict. > > > > Best > Ale > -- > > > > > > > >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
