On Tuesday, August 9, 2022 11:57:53 PM EDT Murray S. Kucherawy wrote: > On Tue, Aug 9, 2022 at 7:54 AM Dotzero <[email protected]> wrote: > > When "we" (dmarc.org team) originally came up with DMARC, the goal was to > > take what was in essence a private club to an open standard that anyone > > could benefit from. My personal take is that validators choose not to > > provide failure reporting for various reasons other than "it's a noise > > generator". It requires extra effort and resources that some validators > > choose not to undertake because it doesn't benefit them (from their > > perspective). Another reason some validators don't implement is fear of > > potential liability under GDPR or similar regimes. There are a number of > > validators that provide failure reports through private channels but only > > where a direct or indirect contractual relationship exists. This seems to > > primarily through intermediaries that provide email authentication > > services. > My recollection is similar. When DKIM was young, it was very valuable to > be able to get two implementations to cooperate when debugging validation > failures. Specifically, to debug a failed signature, you need the blobs of > data that were fed to each of the hashes from both the signer and the > verifier so they can be compared. That means the verifier has to keep > those things around, and when something fails to verify, it needs to dig > them up and send them back to the signer. RFC 6651 is the published > version of something that originally appeared as a private feature of > OpenDKIM, whose roots go all the way back to the first interoperability > event (~2005) where the ability to close these loops was hugely impactful > at working out the kinks. In essence, it allows you to include a signal in > your DKIM signatures that you want this data to be sent back to you if the > receiver is willing to participate. This same technique was useful when > developing and testing an open source ARC implementation. > > I don't think there was widespread implementation of what that RFC > describes, but it is an early version of the theme that led to the forensic > reports in DMARC. For DMARC, the intent was similar: If my mail is landing > someplace and failing to validate, I would love to know why, and maybe > you're willing to help me out by providing me with that information without > me having to ask you to scrape logs and/or do other local sleuthing to find > the problem. > > For an operator just experimenting with it to gauge potential impact of > turning it on fully, or to shake out the bugs in a new implementation, it's > quite valuable. But yes, it risks revealing all kinds of stuff and > ultimately shouldn't be left "on" once the thing is fully in production. > Back then we were more interested in getting DKIM and eventually DMARC > working, and privacy wasn't as much of a consideration as it is now. > (Note, for example, that both versions of DKIM and RFC 6651 pre-date RFC > 6973, wherein the IETF formalized the idea of a Privacy Considerations > section.) > > I agree with John, I think, that the amount of time we should spend > improving failure reporting should be proportional to how much it's used, > or how much the community is asking us to do so. If the consensus is to > drop it, then we should say, probably in an appendix, that original DMARC > had this, but nobody used it and it's a PII nightmare, so it's no longer > supported in the Standards Track version.
I think it would be useful to review RFC 6973 and see if we think feedback reports as currently defined are consistent with it, but I don't think we should spend a lot of time on revisions. I would guess there are, in general terms, only three answers: 1. It's fine, no worries. 2. It's not fine, but can be made fine with tweaks. 4. It's not fine and needs a major overhaul, so maybe we dump it. Given RFC 6973, I think we owe the IESG spending a little time to assess if there is an issue or not. It would be useful, I think, for the shepherd write up to be able to say that since the input specification was pre-RFC 6973, we did an assessment in the working group and documented the appropriate privacy considerations/made some tweaks as a result. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
