Re: [dmarc-ietf] Forensic report loops

Дилян Палаузов <> Thu, 14 January 2021 11:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD5CC3A098C for <>; Thu, 14 Jan 2021 03:12:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (4096-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t2Ly-DOBE80C for <>; Thu, 14 Jan 2021 03:12:27 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 946B73A08B0 for <>; Thu, 14 Jan 2021 03:12:26 -0800 (PST)
Authentication-Results:; auth=pass (LOGIN)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=k4096; t=1610622742;; bh=t50xDqO4qgWk3BSdclsrC9Wb8zkijilAr8MMdSGz1UM=; h=Subject:From:To:Date:In-Reply-To:References; b=lQBVYGknYkLdiQT9EVLh59vK/i5pKb6c0US0FnyxVTka3+HDbtF1vGG1QiqlE//zC RBJJTjK0mmzwKDi1XM77i7FU52yjqpzJCMHQGO7j1KoDt3aurj0VKQ8N21UDRcTBPd XhIjfqgsJ0UBf35i/9fXU5y76W3aeAfttERMIbUmrfO8LvQ/j0x/Uf39O5+gR/fcXF i/eSBHRUroP1nknDcYQOXRHK9zNbicIz5YFF+z0FFb2h73ecteaftDKknc0ZfPk6le ySssJUMJ4Ic7vs7YaOE4j9bZ9098I0U+v2Ovs4LPiwACzlhoul7OA4w7n2FItTTPkW /DJC/ITaegjzo96XMwKT65e6QGpA0S4flpP1oghoE0uTKPBhfVVYPxtPYeNe74ik+K 1a5I5L98zmz8XjC2D1jNeDiXpLNPe3O2i4Y90ypQLdwXIucr2yDDG/XRbmNRdj93sJ /0oVpGjT+kN4VfJRQARGG1Is/Q+LYL2hXsipzqwFkgMBP3+0Q/HNZ6bio9sUjI0MT4 WmzwOs1MztSskXb4mjQCZTBbB3JgwdHEL/nH5L2VDD8cjvhVNIvv59Z0Ji9nh8FsaQ GKdyZb7viMaQP02GoeUU3fToKzEN28x6jJCamC7YClKo97yABZpHVzkbEuSZLHxZmn sXtBLR5gdDV/nyVcbnDr1Qpc=
Authentication-Results:; dkim=none
Received: from [] ( [] (may be forged)) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id 10EBCMYL3939648 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for <>; Thu, 14 Jan 2021 11:12:22 GMT
Message-ID: <>
From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= <>
Date: Thu, 14 Jan 2021 13:12:21 +0200
In-Reply-To: <>
References: <> <>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.39.2
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
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 11:12:30 -0000


Am Donnerstag, dem 14.01.2021 um 01:22 -0800 schrieb Steven M Jones:
> 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.

Imagine a case, where two sites sending forensic reports on failures
exchange messages and the one site is misconfigured: on each received
forensic report it sends a bounce, which bounce does not DMARC-align. 
This the same problem as with a misconfigured site sending Aggregate
reports, but does happen once a second, not once a day.  By sending
reports with return-path:<> you prevent the misconfigured recipient of
the report to generate a bounce, which bounce must DMARC-align, but
does not DMARC-align.

I want to remind on real-world cases addressed on this mailing list
• On 25 May 2019 with Subject “Is there any recommendation to send
DMARC message-specific failure reports FROM:<>”?
• On 31 May 2019 with Subject “Endless Email Loops with Aggregate
• On 4 JUne 2019 with Subject “Endless Loops with DKIM reports” which
addresses reporting per “RFC 6651  Extensions to DKIM for Failure
Reporting” - this is not much different than forensic reports

that lead to “Endless Email
Loops with Aggregate Reports”.

I have not read the thread “Ticket #28 - Failure report mail loops”.

A possible approach is not to send failure reports for messages
received on the address for accepting aggregate/forensic reports. 
These messages shall just be excluded from all calculations.

Does anybody compare the number of messages sent from her host1 to the
host2 of somebody else, with the number of reported messages in the
aggregate report?  If the numbers do not match, does somebody apply
negative spam weights for host2?