On Tuesday, May 7, 2019 10:30:25 PM EDT Seth Blank wrote: > Thanks, Scott! > > To me (as an individual) this seems ready for last call. > > A few items: > > 1. In the new paragraph in section 1 clarifying requirements, you have an > open parens that is never closed.
Fixed locally for the next revision. > 2. In Section 3.5, I'm concerned with the normative MUST NOT. This would > mean .example couldn't receive failure reports the way example.com does. > For something like .bank or .com, this is a feature. But for a .google, > this is a bug. I really think this MUST NOT is, while well advised, delving > into policy and not interop. In theory, I agree, but in practice, I think the new MUST NOT is a great change to promote implementation simplicity. Recall that the failure reports we are discussing are not commonly sent even for regular DMARC due to privacy concerns, so there's almost no loss of feedback as a practical matter defining it this way. Consider what implementers would have to do in the alternative. In order to treat failure reports differently for single and multi-organizational PSDs, one would need to know which is which. While some, like .google are relatively obvious, other are much less so. It is much better to give clear guidance than to be handwavy. > I really think the guidance in 4.1 is the best way to approach this. > > 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. > My recommendation would be to roll this change back, and perhaps replace it > with a reference to 4.1 and a "if you're a PSD, don't ask for RUF unless > you really really know what you're doing." I disagree. That puts the (potential) fox in charge of the hen house. > 3. psddmarc.org - I think we need a brief paragraph outlining the > experiment, and in it need to explicitly call out that a permanent solution > needs to be determined for answering the "what's a PSD" question - which > may or may not be psddmarc.org. 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. Other than the typo, I'm going to leave my local copy as is while we wait and see what others think. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
