I also lean towards Seth's perspective. Additional comments in-line.
On Mon, May 20, 2019 at 1:32 AM Murray S. Kucherawy <[email protected]> wrote: > 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 agree with avoiding MUST NOT in this case for the reasons given (policy vs interoperability). I think SHOULD NOT with explanation of why might be acceptable. > > 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. > > > Michael Hammer
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
