On Wed 04/Apr/2018 20:19:20 +0200 Peter M. Goldstein wrote: > > 1. *A domain which contains two public suffixes* - i.e. abc.gov.uk, which > contains the public suffixes .gov.uk, .uk. In the proposed lookup scheme > we'd be assuming that the manager of the registry for the "last" > organizational domain represented a controlling authority that should be > able to impose DMARC policy on and view data for all subdomains. Just to clarify, I have:
$ psl --print-reg-domain mail.abc.gov.uk mail.abc.gov.uk: abc.gov.uk and $ psl --print-reg-domain mail.sub.qld.gov.au mail.sub.qld.gov.au: sub.qld.gov.au The method https://tools.ietf.org/html/rfc7489#section-3.2 defines just one Organizational Domain, so using the term "last" above is pleonastic. I reckon psl --print-reg-domain (at least in the above cases) matches that method well. If that's correct, I don't see how the txt record at _dmarc.qld.gov.au could ever have a chance of being discovered. > 3. *New gTLDs* [...] It may make sense to allow those gTLDs to define a > DMARC record on the TLD itself or on some 'default' domain - both for > administrative simplification and to ensure against abuse. I strongly disagree. If a domain owner --the target of a delegation, i.e. the one who controls the relevant subtree-- has to submit to a parent domain policy which provides for yielding reports about their private mail, then the parent domain is not a public registry, not in the commonly accepted meaning of the term "public". DMARC policies are not akin to abuse mailboxes, are they? Ale -- _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
