On Thu, May 9, 2019 at 3:03 PM Scott Kitterman <[email protected]> wrote:
> If there's no MUST NOT, then any entity that does failure reporting needs > to > consider if they should do it for PSDs and if so, which ones. That's a > question that, at best, has a squishy answer. > I don't agree. It's up to the PSO, not the system generating reports, to determine which type of reports are wanted. The proposed registry is the control of who can even make a decision like this. If there were no registry and PSD functionality were open to all, then this would be a more concerning case. But the entire point of DMARC is that a receiving system doesn't need to guess - it's up to the domain owner to publish their policy. This flips that distinction on its head and says it's no longer up to the domain owner. To reiterate: This normative MUST NOT is a mistake from many different angles, as it: 1) codifies a policy decision that doesn't affect interoperability 2) adds complexity because reporting against the third lookup is now different than reporting for the other lookups 3) doesn't apply for all use cases (specifically, it would prevent .com from gathering RUF data, but also prevents .google from operating in the same manner as google.com) 4) reverses a key value of DMARC: giving control of policy to domain owners I strongly agree that RUF is potentially problematic here, and it would be better off if no one got it, but I really believe that's a policy decision for a domain owner / PSO (and a policy decision for who is allowed in a registry of PSOs), not something that should be normative in the spec. Seth
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
