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


   $ 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?


dmarc mailing list

Reply via email to