On Wed, Mar 19, 2025 at 7:03 PM Dotzero <dotz...@gmail.com> wrote: > As one of the people who originally came up with DMARC, I strongly > disagree with approach 3. We could have kept DMARC a "private club" that > created value only for those invited to participate. Instead the > participants in the effort felt that the value created should be publicly > available to everyone through a public standards effort and that IETF was > the natural place for such an effort. Failure Reports are part of that > value proposition. They are currently being provided today but > privately.,as a result of privacy and liability concerns stemming from > various regulatory frameworks from governmental bodies. >
Doing (1) is pretty expensive relative to the other two, and we should be sure the value is there. Can you say more about who is providing or consuming them? It's one thing to say failure reports have value, but if that value in the real world is effectively vaporware, is it a good use of our time to preserve it? Anecdotally, standardized debugging tools don't seem to be something the community is interested in. During the development of DKIM, I found it enormously useful to be able to capture certain details about the message being verified, and make those available to the signer so we can see where things were breaking down. I implemented a way to do this that worked very well in my open source tool, but there was little (i.e., no) interest from other implementations. The DKIM WG wasn't interested in pursuing this. I managed to convince the MARF WG to publish this (as RFC 6651), but after all that time I think mine was the only implementation. Some aspects of that specification became failure reporting in DMARC. But if that was ultimately of only local value in DKIM, and if what Seth is saying about the dearth of uptake of the same idea for DMARC is true, then I don't know what value proposition we're seeking to preserve here. Another way to look at this: It seems more like implementers tend to develop their own private ways to debug things rather than embedding them in the base of whatever it is you're developing. You could call that a "private club", I guess, but maybe the lesson is rather that there's simply no appetite for interoperability here, which obviates the need to do standards work. While I prefer option 1, I can reluctantly accept option 2 as it allows " a > second bite of the apple" at a later point if the IETF email community > decides to take up the effort at a later point..We are so close. Let's > complete the journey we started. > I'll revise my position and say that I prefer (3), but I would also accept (2). -MSK
_______________________________________________ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
