On Fri 10/May/2019 01:16:58 +0200 Seth Blank wrote: > > 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 <http://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.
In part I agree. However, RUF is potentially problematic in general. Whether and how to honor RUF requests deserves a better discussion in the DMARC specification. I certainly wouldn't send a non-redacted failure report to an unknown domain. That said, I agree that control of PSDs should be given to PSOs, by the same logic of bullet (4) above. On Thu 09/May/2019 18:39:13 +0200 Scott Kitterman wrote: > > I disagree. That puts the (potential) fox in charge of the hen house. > It is true that we cannot trust the generic domain owner. However, PSOs are somewhat more constrained by policies and contracts. In addition, their public DNS records are quite easy to check. Perhaps we could concede a little bit of trust to those foxes? In addition to Seth's "if you're a PSD, don't ask for RUF", I'd propose that multi-organization PSDs (e.g., ".com") that do not mandate DMARC usage SHOULD publish a blank DMARC record, that is policy=none, no ruf, no rua. PSOs that violate those recommendations would not do so in a concealed or unanticipated way, but as an integral part of their legalities. Best Ale -- _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
