On Thu, Jan 14, 2021 at 1:22 AM Steven M Jones <[email protected]> wrote:
> 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. > I'm asking the question in response to an actual use case. Granted it's an isolated case so far, but it comes from a not-insignificant organization that probably handles a substantial email load, so at least for their side this is already happening, or could happen, at scale. 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? > I believe that's exactly what I was asking for. > 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? > I don't see a reason why we need a different method for each report type. The case in hand is forensic reports, but that's just part of the specific incident to which I'm responding. > > 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... > I can't imagine one, but I'm running on little sleep at the moment. 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? > Sure, those are all things to consider. "Doing final delivery of that report" -- is that sufficient? Or, "any > entity processing the report and potentially generating a report in > response?" > I think you could put the check in either place. Also fodder for discussion of a solution. > 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? > I don't particularly care for the idea of standardizing a Subject header field value, or part of one, as a way of doing loop detection anyway, but I thought I'd throw it in there just to round out the list. > 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... > I'm also not a fan of the idea of treating different bounce messages in different ways. That seems like avoidable complexity. Do we want to ever send back a forensic report for something from the null sender, irrespective of what's in it? -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
