I don't see that the text reflects Ale's understanding either, and I think he has been arguing that a design based on that understanding is unsupportable. UK.COM is not part of any organization, so relaxed alignment cannot be a consideration.
Section 4.6 item 7 says that the walk ends on PSD=Y or PSD=N, without any apparent exclusion for the same-domain policy. We need consensus on what is intended as well as consensus that what is written for To help determine design implications, iIt would be useful to analyze the PSL to build a complete list of entries whose parent domain is not in the registry. For public registries, an unlisted parent domain would imply an error in the list. For private registries, an unlisted parent domain would indicate a domain where relaxed alignment might be desired by the registry operator. Doug On Mon, Jul 25, 2022, 9:27 AM Alessandro Vesely <[email protected]> wrote: > On Mon 25/Jul/2022 12:56:02 +0200 Douglas Foster wrote: > > We had a discussion about domains that need to set both PSD=Y and > > PSD=N. It highlighted one of the problems with using a tag which > > implies mutual exclusivity when exclusivity does not apply. > > > > The stated solution was that when PSD=Y is found on the same-domain > > policy, then PSD=N is also assumed, which implies that strict > > alignment is also applied. This seemed like a reasonable solution. > > > > However, I cannot find any reference to this principle in the > > specification. What happened? > > > To impose strict alignment to PSDs which send mail was hypothesized in > March. Afterwards, the algorithm was changed by disregarding psd=y at > step 2; that is, on the domain input to the algorithm. Therefore, a > sending (or signing) PSD operates as part of its org domain. > > In an example I posted, I showed that mail.psd.org.example cannot work > to authenticate From: [email protected]. However, a sibling like > signing.org.example would be in relaxed alignment. > > I still think an example like this is clarifying, albeit unreal. > > > Best > Ale > -- > > > > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
