On Tue, Aug 9, 2022 at 7:54 AM Dotzero <dotz...@gmail.com> 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. -MSK, participating
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
