Re: [dmarc-ietf] Forensic report loops

[Steven M Jones <[e-mail]>]

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.