On Mon, Nov 11, 2019 at 1:58 AM Tim Wicinski <[email protected]> wrote:
> Scott > > PSD DMARC does talk about organizational domains which from the original > DMARC spec (section 3.2) > does say 'Acquire a "public suffix" list' > > The addition of the preamble text shouldn't move the document in either > direction. > I do feel anything which helps focus us on moving forward on DMARC-bis is > a good thing. > The WG should be able to start writing the PSL document right away. > > Murray and I will be in Singapore if anyone wishes to speak their mind. > > thanks > Tim > > > > > On Mon, Nov 11, 2019 at 3:29 AM Scott Kitterman <[email protected]> > wrote: > >> >> >> On November 11, 2019 7:34:39 AM UTC, "Murray S. Kucherawy" < >> [email protected]> wrote: >> >On Thu, Sep 5, 2019 at 1:22 PM Dave Crocker <[email protected]> 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. >> >> The current revision of the PSD DMARC draft makes no reference to the PSL >> in the body of the draft (it only comes up in Appendix A and C). It >> seems like an odd choice to continue to insist PSD DMARC is specifically >> tied to the PSL when the text indicating so has been removed (Dave's email >> was two months ago and things have changed in the interim). >> >> I don't think the proposed note says anything the status of experimental >> shouldn't already communicate. Given the current state of the draft, I >> don't think it's necessary to have such a note. >> >> Scott K >> >> _______________________________________________ >> dmarc mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dmarc >> > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
