Thanks for responding. on (c) The idea of multiple inheritance points had some appeal for me, but I have given up on the idea because of the compatibility problems it would create. We MUST find the correct organizational domain to correctly apply relaxed alignment. Having done that, we can also replicate the existing inheritance rules.
on (a) Non-existent organizations and non-existent FROM domains are very different tests. Relaxed alignment allows for the FROM domain to be non-existent on legitimate messages, and mailers take advantage of that feature. This distinction was part of my long-running fixation on changing the NP clause of the PSD experiment. I think if you check your message logs, you will be able to confirm this situation. Since the PSD experiment was rolled out without the "psd=y" term, making a clear distinction between NP and NX solves two problems. Doug On Tue, Feb 22, 2022 at 3:57 AM Alessandro Vesely <[email protected]> wrote: > On Mon 21/Feb/2022 23:55:56 +0100 Douglas Foster wrote: > > To accurately identify PSD policies, we have two choices: > > - assume that PSDs will add the "psd=y" flag to their policies prior to > publication, or > > - declare that the "NP" clause is the PSD indicator, meaning > > (a) it indicates that the first child domain without an NP term is an > > organizational domain, and that organization must pass an existence test > to > > verify registration. > > > I don't see why an org domain, or any domain, cannot specify NP. To me, a > non > existing From: domain is such an obvious abuse indicator that could have > been > the default (as it actually has been, IIRC.) Also, I see no meaningful NP > but > np=reject. > > > > (b) that the organizational domain is an upper bound for alignment. > > > Yes. > > > > (c) that the SP clause of the PSD's DMARC record applies to the > organization. > > > To complicate, or perhaps to incentivize, the tree walk, we could consider > inheritance rules. For example, a From: subdomain could have a backward > incompatible record like so: > > _dmarc.sub.example.com IN TXT "v=DMARC1; rua+=mailto:[email protected] > ;" > > > 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
