Firstly, just a nit, but section 4.1 introduces a new abbreviation in the last bullet point: "PSDo". I suspect that this should be PSO for consistency.
More substantively, in Appendix A, the case is being advanced for "concerns associated with Multi-organization PSDs that do not mandate DMARC usage". I'm not sure why "multi-organization" is an appropriate qualifier, nor as to what mandated DMARC usage has to do with any of the privacy concerns. Neglected DMARC usage is what leads to the spillage up to the PSD level. Even within a single organization there may be serious privacy walls which need to be respected between different sub-portions of the org - which may or may not be represented in a DNS hierarchy. I've read through the breakdown in section 4.1, but I think that it is incomplete - largely on the terms mentioned above. Also, the claim that reports on cousin domains would be sent to the [right] PSO ignores the risk of the PSD itself being the cousin attack point. After all if a domain doesn't exist, one may as well start from the top :-) I think it would be more effective to add an anti-RUF requirement to the implementation of this spec - such that no RUF reports would be sent, regardless of the record which is published by the PSD. Since very few providers even support RUF at all, this does not seem to be a big ask, although it does require some additional logic. The privacy risk is primarily related to RUF, not RUA reports so blocking RUF could (IMO) effectively mitigate the perceived risk of the PSD records while still allowing the DMARC validation protection. --Kurt
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
