It is helpful to understand how these reports can be useful. Given that those who use this feature are not present, I see no reason for people who don't use it to clarify or improve it for people who may not need clarification or improvement.. So #1 seems out of scope because we do not have standing.
#2 and #3 seem pretty similar to me, but the point of #3 is that most new implementations need not offer the feature because novice installations should not ask for or send these reports. Private clubs are predicated on conditional reporting, based on remote identity. This is something that probably has value for all reporting, but one that the group thought unimportant when it was mentioned. Private clubs can do as they wish, as RFC7489 exists forever and all installations are required to ignore policy terms that they don't recognize. The ruf token should remain reserved forever, so that it is never given an incompatible interpretation. I think you can find language that deprecates the feature for general use while acknowledging successful use in controlled settings under contract Doug On Wed, Mar 19, 2025, 9:25 PM Dotzero <[email protected]> wrote: > Responses in-line. > > On Wed, Mar 19, 2025 at 7:03 PM Murray S. Kucherawy <[email protected]> > wrote: > >> On Wed, Mar 19, 2025 at 7:03 PM Dotzero <[email protected]> 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? >> > > Of course abandoning an effort is generally less expensive than engaging > in the effort. I don't know of anyone publicly providing failure reports > but I'm aware of various organizations providing them privately based on > contractual relationships. Beyond that I'm not in a position to say more > given that they are contractual relationships. IANAL and I have no > intention of engaging one to see what more I might publicly disclose. > >> >> 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? >> > > I can give you an example of the value which can be derived from such > reporting. Understand that my focus in the context of DMARC has always been > on the transactional email space. This example is a real world > implementation. Assuming an organization has control over its > (transactional) mail streams, if the URLs in its legitimately emitted mail > streams are used to remove (legitimate) emails in the failure report, all > that remains is direct domain abuse. That is, unauthorized use of the > domain. One can then apply logic to automate generation of DMCA notices > (copyrighted images), submission to block lists, etc.Being able to automate > these sorts of actions significantly reduces cycle times for addressing > such abuse creates significant value for the abused domai as well as for > the ecosystem at large. But it depends on the feedback loop provided by > failure reporting. This is not a hypothetical implementation. We also found > with this implementation a false positive rate of zero. So there is value > beyond simple debugging. > > >> 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). >> > > The problem I see with (3) is that it closes a door, locks it and throws > away the key. While I realize that (2) closes the door, at least it doesn't > lock it and throw away the key. > > Michael Hammer > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
