On 1/13/21 20:29, Murray S. Kucherawy wrote: > > How are implementers dealing with forensic report loops?
The question of whether such a thing is actually ever seen in the wild should be asked, if only to document that it was asked and answered. See prior "this is a vanishingly small number who cares" discussions. Channeling Dave, is it fair to just say the objective is: To ensure that forensic reports do not ever cause the recipient of a forensic report to generate another forensic report in response? Is that overly broad? Are there other goals or conditions? > Say I send a message from X to Y, whose DKIM signature fails. Y sends > me back a forensic report, whose DKIM signature also fails. X sends a > forensic report to Y, whose report fails, etc. We need a way to break > the loop. Is there a functional or operational difference between aggregate and forensic reports I'm not thinking of that would cause the solution for one case to be unsuitable for the other? Or can we hope for a mechanism that applies to all DMARC reports? > Off the top of my head, a few options: > > 1) a new header field indicating "This is a forensic report, don't > generate a forensic report about it." Is there a reason somebody might use this new header in an abusive way? Or include it in a forged forensic report to avoid exposure? Cue a 0.1% of 0.1% sidebar... Jumping ahead of those questions, would the new header have to be DKIM signed by the report generator, and the entity /doing final delivery of that report/ required to validate the DKIM signature(s) from the report generator, and only generate a forensic report in response if this new header is not present? Or if the signature didn't cover the new header? Or if the signature couldn't be validated? "Doing final delivery of that report" -- is that sufficient? Or, "any entity processing the report and potentially generating a report in response?" > 2) some kind of token that's always in the Subject field of a DMARC > forensic report. DMARC forensic report Subject: lines aren't uniform, but the last time I looked there was an awful lot of similarity. If that were tightened up a little more, would an explicit token really be necessary? > 3) always generate forensic reports as the null sender, and specify > that forensic reports should never be generated in response to the > null sender I suppose that would meet the goal, but what would be lost along the way? What keeps coming to mind is the advice I've seen to have your bounce messages authenticate with DMARC - if a sender does that or is in the process of implementing it, they might want whatever forensic reports they could potentially get... cf. https://www.validity.com/how-to-authenticate-your-bounce-messages-with-dmarc/ --S. _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
