Re: [dmarc-ietf] Forensic report loops

"Murray S. Kucherawy" <> Thu, 14 January 2021 15:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DDCFA3A14C0 for <>; Thu, 14 Jan 2021 07:24:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9E7qLx-AWxqz for <>; Thu, 14 Jan 2021 07:24:46 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0CE2A3A14BF for <>; Thu, 14 Jan 2021 07:24:46 -0800 (PST)
Received: by with SMTP id e15so3291954vsa.0 for <>; Thu, 14 Jan 2021 07:24:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M6rFbiZ/J8GKkK9g0o2E92dp3g6FwlacOQ2x8vOI3Fw=; b=WWmPZWgKU0502FunFjxAdLhymz22z8T4qUZgn3jQtxipV8YIERGzdq+Ez12GHwR6qH jw9cpFjbMstxjRtFgYEfhIAPE1a4Zrzh53rU3YmHIow70PcZfzJytuBwNkGIugTn75eE EPxQneREyumEYE24+O368t0RzqSSRMFOIFawyWIwd2fQoGXjmTx2opyUVB9UV7zudM+M 9p3/2zHMhlz8zITHzMxR6mNvG00oV8tDcEb3nIq5r/idJUsMToyFq8nVia/HYAzRxvj1 fbKVfV1IMxoyYE0Up5qDO+PMAXbzMLjrMH0g1ufCzcHoEieaXORa2hZiYmm8mhRYUg+N livQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M6rFbiZ/J8GKkK9g0o2E92dp3g6FwlacOQ2x8vOI3Fw=; b=ZzQRLymndkjwT4ssZdtnyJKD37f18xGE71yaIldjS5EGSN0mfZSk1RhzlrEeZTfstU NQHfaHfs71DA6HQsGUU2Px3D96AE4/oVPv5I+yKRXMKCjupZh52K/f1N9Df3oKsFlj6M Hz8Tyquaem7J1E3WB3Yux0RgUaoestkbFsAs2ySogcVxwdq0FwyFntgXoCznjojWIGWu dVJhQb5pPWYdc/BgC1TfNHp2tbcR09jwdDv+cQ5lo9iCHtt2nOomHOeel+HQS8J7hK+a t1dAiD+eZunOe3v/oPPV6atJV2EahDt3Mgs5ljOdj+bGeNuxk10vSJySJkIMitYiKxQH 8nIg==
X-Gm-Message-State: AOAM533rENRwNLSZHS1fMo2nNIZ+inbERSkdX4K5LYJ0v5QEwXIvVuxF EIMr3U5fhFF+8ms3/TFFmip8n3NRlv2IncOQklU=
X-Google-Smtp-Source: ABdhPJzLoTtgmZR3ho0qPkjZY1AD01E2gHLi+MK/9Ew/92qH4Biq0VCbyBdxPTA1WCYVfQoDnPnBoMmcGNjILGbmZyo=
X-Received: by 2002:a67:fb46:: with SMTP id e6mr7266746vsr.40.1610637884726; Thu, 14 Jan 2021 07:24:44 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: "Murray S. Kucherawy" <>
Date: Thu, 14 Jan 2021 07:24:33 -0800
Message-ID: <>
To: Steven M Jones <>
Content-Type: multipart/alternative; boundary="000000000000fb23e805b8dddaeb"
Archived-At: <>
Subject: Re: [dmarc-ietf] Forensic report loops
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Jan 2021 15:24:48 -0000

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