On Wed, Jul 17, 2019 at 7:51 PM Scott Kitterman <[email protected]>
wrote:

>
>
> On July 17, 2019 10:23:11 PM UTC, "Flaim, Bobby" <flaim=
> [email protected]> wrote:
> >Amazon supports this draft and effort .
> >
> >This current DMARC extension (IETF DMARC PSD)
> >draft<https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/> would
> >make it easier for our direct customers (registrants) to setup a common
> >DMARC policy for all their subdomains. With this extension they can set
> >up the policy in one place, such as the SLD level (second level domain)
> >and it will apply to any subdomain they create.  However, since
> >feedback leakage can happen due to the nature of the IETF DMARC PSD
> >solution, the following proposed alternative could be employed to
> >address this issue.
> >
> >Is the DEMARC defined for dog.animals.com<http://dog.animals.com>?
> >
> >a.      Yes: then use it
> >
> >b.      No: then look for DMARC on animals.com<http://animals.com>
> >
> >Proposed Default Alternative:
> >a.      Is the DEMARC defined for
> >dog.animals.com<http://dog.animals.com>?
> >
> >a.      Yes: Then use it
> >
> >b.      No: Is using the PSD DMARC explicitly permitted by the
> >dog.animals.com<http://dog.animals.com> owner in some TXT record (means
> >“delegated explicitly to the PSD”)?
> >1.      Yes: then look for DMARC onanimals.com<http://animals.com>
> >1.      No: terminate
> >
> >The alternative proposal requires the registrant to explicitly set up
> >the default.
>
> How would that work for non-existent domains?
>
> Appendix B describes options to address the issues.  I like that your
> suggestion doesn't leave it in the hands of the PSO to self assert if PSD
> DMARC is appropriate, but I wonder why dog.animals.com doesn't just
> publish a DMARC record?
>
> Scott K
>
>
I have to wonder if the Amazon example is the general rule or the
exception? For example, .bank requires all domains to have P=reject. In
their case they wouldn't want the (sub) domain to be able to override the
..bank policy. I'm not sure that enabling a (sub) domain to disable the
DMARC policy up the tree is a good idea. As Scott points out, all the (sub)
domain has to do is publish their own DMARC record/policy and then it
simply becomes a contractual issue.

Michael Hammer
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to