On Monday, August 29, 2022 7:50:18 AM EDT Douglas Foster wrote: > Not strongly opinionated about location. > > For the first insertion: Since the definition of psd=n occurs in the > policy record, and after the tree walk, this seems to fit in with the psd=n > definition. > > Some organizations have subtrees within their DNS structure that represent > client sub-organizations, which are unaffiliated for purposes of relaxed > authentication. Before putting a PSD=N tag on an organizational domain > policy, the domain owner MUST ensure that all sub-organization boundaries > are properly identifiable. Identification can be accomplished by placing > a PSD=Y tag on the domain which is the parent of the sub-organizations, by > placing a PSD=Y tag on the organizational domain of every client > sub-organization, or both.
I do not support this. That's not at all how it works. Unless you are something like .gov or .us.com you don't need to use psd=y. I think this is likely to lead to confusion and mis-deployment. The only reason to use psd=n is if the entity above yours in the DNS tree has a DMARC record without psd=y and is an actual PSD. When we discussed this before, we concluded that while the current protocol definition does technically support embedded PSDs lower in the tree below DMARC organization domains, it's not something that actually happens. I think the draft, as written, adequately addresses PSDs and adding this kind of exposition, even if it were technically correct, would lead to confusion. > > For the second insertion: Also append it to the definition of psd=y. If > the tree walk description was more algorithmic, I would place the second > paragraph with the description of how the initial exact-match policy is > handled, but that is not an option. > > "Most registrar domains are self-contained, meaning that the parent domain > is a PSD and child domains are PSDs or unaffiliated organizations or PSDs. > When this is the case, the domain owner should publish PSD=Y as well as > askim=s and aspf=s. This ensures that the Tree Walk will terminate and > use the current domain policy as the default policy. > > When a registrar and its parent are in the same organization, and the > organization sends mail, DMARC policies using relaxed alignment may be > desired. When "psd=y" is encountered on the initial exact-match domain, > and relaxed alignment is specified, the "psd=y" term is ignored and the > Tree Walk is used to find the parent record which is the organizational > domain." I don't think this is a good idea either. We should not go down this path. It doesn't matter if a PSD (with psd=y) that sends mail specifies adkim/apsf=s. Given the current design, an exact match is all that will ever align. While I agree actually putting adkim/apsf=s in a PSD's DMARC record would be clearer for human interpretation, for the machines they don't matter. I don't believe there's any benefit to specifying them. Once again, PSD is an infinitesimal fraction of DMARC. It is currently correctly specified and putting too much emphasis on it will just create confusion. I've snipped the rest of the message to make the flow easier to follow. I don't think it's needed to support further discussion. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
