On Thursday, May 9, 2019 1:35:28 PM EDT Seth Blank wrote: > 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.
Either way there's a consideration. 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. If the MUST NOT is present, it's a straightforward processing change to not apply failure reporting if you got the result from a PSD lookup. Either way, entities that don't do failure reporting now, won't be affected (which is almost everyone). The changes to add PSD DMARC to an existing DMARC implementation are not complex, but they are required. A clean implementation requirement while you're updating related code it, IMO, much easier to deal with than vague policy guidance. > > > 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 agree a small change is needed. If we leave it the way it is (with the MUST NOT), then it would be appropriate to add that the MUST NOT requirement fully mitigates the privacy concern as it relates to RUF. > > 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. I don't think so. We know technically that it can do so. There is no technical question in that regard, so nothing to experiment over. Will people use it isn't really the proper basis for an IETF experiment. The IETF publishes non-experimental RFCs all the time without any particular data to suggest the RFC will get implemented and deployed. I think how to get the privacy issue mitigation correct is the only technical issue that needs experimentation, but I may have missed something. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
