Re: [dmarc-ietf] Forensic report loops

["Murray S. Kucherawy" <[e-mail]>]

On Thu, Jan 14, 2021 at 1:22 AM Steven M Jones <[e-mail]> 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