On Thu, Sep 5, 2019 at 1:22 PM Dave Crocker <dcroc...@gmail.com> wrote:
> > 1. The change to DMARC should be limited to permitting the query for the > > organization domain to be anywhere in the DNS tree, including a TLD. > > Within DMARC this would not look like 'extra' mechanism. > > > > 2. The mechanism that processes that query should be cast strictly as a > > PSL enhancement, independent of DMARC. > > > Trying to refine things further: > > > DMARC does not care about the PSL. > > What DMARC cares about is the Organizational Domain (OD), as a > fallback when no DMARC record is found at the desired domain name. > > That is, PSL is literally outside the scope of DMARC. > > At the least, therefore, the DMARC specification should define a > distinct interface to the outside functionality that tells DMARC where > the OD is, which will return what suffix of the full domain name is the > OD -- eg, getOrgDomain(full-domain) -> org-domain-suffix > > The PSL-related side of that interface should be a separate > specification, so that changes to its behavior -- such as has been > happening with the introduction of ODs that are TLDs or are otherwise > 'above' where DMARC has been guessing the OD to be -- are isolated from > DMARC. > > The current problems are that DMARC has embedded too much detail > about the PSL world, yet DMARC has no involvement in that world. The > current proposal embeds assumptions of PSL knowledge further, rather > than separating PSL knowledge out. > We (the chairs) fully agree with all of this. What we -- I in particular -- have been struggling with is to find a path forward so the PSD experiment can still take place without being blocked by the need to first go back and overhaul RFC 7489 as you've described here, separating DMARC and the OD determination. Because that'll take months. We are perhaps in the fortuitous position in our charter now that our very next work item is to take up the task of reopening DMARC itself, and the separation of function Dave is espousing could be made into a reality during that work. Given this, we suggest that the PSD draft be allowed to proceed as Experimental, but with appropriate preamble text added to its Introduction explaining the deficiency Dave has identified. So the order of operations becomes: * add text to the PSD draft making it clear that what it's describing is an experiment whose outcome will be taken only as feedback to the revision of the standard (i.e., this is not intended to be the final form of anything), and it is not intended to be deployed outside of the experiment's participants; * publish the experiment with those cautions and allow the experiment to begin * while the experiment is running, spin up the work on two new standards track documents, in line with our charter: a) DMARC, with PSL references replaced by the abstract notion of the OD that's determined in some non-specific way, as Dave suggests b) a PSL document that satisfies the abstract notion of OD in the DMARC document, also as Dave suggests * when the experiment completes, either augment (b) if it's still in development, or publish a revision to it, based on what the experiment has revealed Can this be made to work? Honestly, the experiment could start anyway without an RFC published, but a formal record of the experiment and its caveats doesn't strike me as a wrong thing to do. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
