On Friday, July 12, 2019 6:35:31 PM EDT Kurt Andersen (b) wrote: > Please note that I did not review Tim's comments in detail so some of the > following points may have been covered by him previously. > > *Page 2 contains the following paragraph:* > > This memo provides a simple extension to DMARC [RFC7489 > <https://tools.ietf.org/html/rfc7489>] to allow > operators of Public Suffix Domains (PSDs) to express policy for > groups of subdomains, extends the DMARC [RFC7489 > <https://tools.ietf.org/html/rfc7489>] policy query > functionality to detect and process such a policy, describes receiver > feedback for such policies, and provides controls to mitigate > potential privacy considerations associated with this extension. > > This extension does not really allow PSDs to express policy for > "groups of subdomains" unless you take the perspective that "all or > none" are groups. Perhaps altering the language to say "...to express > policy that would apply to subdomains..."?
I think the changes I just pushed in response to Tim's comments address this. > *The very end of section 1 says:* > > DMARC [RFC7489 <https://tools.ietf.org/html/rfc7489>], by design, > does not support usage by PSOs. For PSDs > that require use of DMARC [RFC7489 > <https://tools.ietf.org/html/rfc7489>], an extension of DMARC > reporting > and enforcement capability is needed for PSO to effectively manage > and monitor implementation of PSD requirements. > > I still fail to see how this proposal is necessary (or, potentially > even useful) for the PSO to perform enforcement of their policies. I'd > recommend either deleting the entire paragraph or refocusing the > second sentence around the brand protective role that this proposal > brings for abuse of non-existent subdomains below the PSD. Agreed. Deleted. > *Section 2.2* "PSD DMARC includes all public domains..." --> suggest > "PSD DMARC applies to all public domains..." Incorporated. > *Section 2.6* "...that a receiver is willing to accept" seems like it > opens up a wide area if one applies considerations like > DNSSEC/DANE/MTA-STS/etc. There is a separate conversation on this > topic so I'll defer to that thread. This went away due to that discussion. > *Section 3* should include the new "np" keyword as an update to the DMARC > spec. Added based on the no existent domain sub-thread. > *Section 3.5* This call-out makes it seem like information about > non-existent domains is not desirable and useful for org-level DMARC. > Can we modify the language to remove that implication? Perhaps "...is > desirable and useful, just as it is for org-level DMARC operators." Incorporated. > *Section 4* Neglects the privacy implications of broken "receiver is > willing to accept" conditions that may lead to additional leakage. > Also in the third bullet point, "it's feedback" should not have an > apostrophe. OBE, related text is removed. Typo got fixed somewhere along the way. Thanks, Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
