On Thu, May 9, 2019 at 9:39 AM Scott Kitterman <[email protected]> wrote:
> In theory, I agree, but in practice, I think the new MUST NOT is a great > change to promote implementation simplicity. This increases complexity. With this normative requirement, we're adding a third lookup that behaves differently than the previous two. This complicates the experiment and solidifies a (good) policy consideration normatively. > > Speaking of which, with the normative MUST NOT that's been added, now 4.1 > > no longer makes any sense. > > Only if you assume that there are no privacy risks associated with > aggregate > reports, which I don't believe is accurate. I certainly wrote 4.1 on the > assumption that it was mostly about aggregate reports, since failure > reports > are not commonly sent. > The first bullet of 4.1 is incorrect if RUF is MUST NOT for PSD. I thought I'd done that in Appendix A. Please review and provide specific > recommendations as I don't really know how to address this general comment. > You're absolutely right, you did. I do, however, think there's more to the PSD experiment than just deciding where a PSD list should live - the crucial bit is if this actually addresses and demonstrates value (i.e. stops spoofed email) for the use cases discussed in Section 1.
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
