Hatless: On Tue, May 7, 2019 at 7:30 PM Seth Blank <[email protected]> wrote:
> 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. > I've read Scott's replies to this as well. The question I have is whether we have consensus to include this change, but that's hard to gauge when there's been so few names offering comments. I'm partial to using MUST NOT only where it goes to interoperability, so I'm inclined to agree with Seth. However, I've been nudged away from that position on this in the past, i.e., that it can be used to encourage best practices and there's ample precedent for such. Still, given other replies on the topic, especially the presence of "unless you know what you're doing" in some of the dialog, I'm wondering why this isn't a SHOULD NOT with an explanation of why, and in what circumstances one would deviate from that advice. There are aspects of the discussion in this thread that would be valuable to implementers (summarized, of course). I'm also inclined to agree with Seth on his points of complexity, and on moving contrary to DMARC's tenets. Having said all of that, I'm not firmly resisting given that the plan is to send this up as Experimental, as its deployment and results could usefully inform our choices with respect to standards track DMARC. While you all stew on that, I owe the group a top-down review of it and the start of a shepherd write-up, so I'll do both this week. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
