On July 17, 2019 10:23:11 PM UTC, "Flaim, Bobby" <[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 _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
