Re: [dmarc-ietf] Forensic report loops are a problem

Steven M Jones <> Thu, 28 January 2021 03:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 67DC73A10CF for <>; Wed, 27 Jan 2021 19:17:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-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 6-rO4PgAVsFM for <>; Wed, 27 Jan 2021 19:17:19 -0800 (PST)
Received: from ( [IPv6:2001:470:1:1e9::4415]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EFC643A119B for <>; Wed, 27 Jan 2021 19:17:18 -0800 (PST)
Received: from ( []) (authenticated bits=0) by (8.15.2/8.15.2/cci-colo-1.7) with ESMTPSA id 10S3H6Ax069709 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <>; Thu, 28 Jan 2021 03:17:14 GMT (envelope-from
DKIM-Filter: OpenDKIM Filter v2.10.3 10S3H6Ax069709
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=201506-2k; t=1611803836; bh=58KUvoVREoMAfcutyimwxMta+rktYloA+fw5cANlOLQ=; h=Subject:To:References:From:Date:In-Reply-To; b=DAeKbf1xHbV++UoFGUc2PtP3qHCkVqgHdr8C2UeWX6exuM/79VdQ2LHMEj7h136U3 RukkK4ZyyuMskWXqfpIHN2QDaxGixvnsu9VUgUChpwhlrq9DH78L+WNwkRVaCayc9y tHvOZ1nNHofjj5ALr5bDGDAIFuC16YqBrUuM5Qfu7HEppfgLE8HUhaKBWAjYai8seK ve5Po/vL2TKe8vslurD9a1pEH1da6KrWaMknXsBfCeXiuzIb/lKl2uhUGJvMvpPiCC SQLJG9f/pW4mTo1RYL2MeO+QsZaLo/NioKSTMqKDNhQrOg268oUhs5msUlRfefQKNH Efqgg6JQvU+cg==
X-Authentication-Warning: Host [] claimed to be
References: <> <20210127203714.007C86CDB9CA@ary.qy> <>
From: Steven M Jones <>
Message-ID: <>
Date: Wed, 27 Jan 2021 19:17:06 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:78.0) Gecko/20100101 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------A536FB636D3C75D0D25CA65E"
Content-Language: en-US
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 ( []); Thu, 28 Jan 2021 03:17:14 +0000 (UTC)
Archived-At: <>
Subject: Re: [dmarc-ietf] Forensic report loops are a problem
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, 28 Jan 2021 03:17:20 -0000

On 1/27/21 12:47, Murray S. Kucherawy wrote:
> On Wed, Jan 27, 2021 at 12:37 PM John Levine <
> <>> wrote:
>     I still don't understand why failure reports about messages that
>     happen to be failure reports are in any way special.
> Loop detection in RFC 5321 is a normative MUST because of the obvious
> operational problems it creates.  Maybe I'm being thick, but right now
> I don't see how this is different, apart from the fact that each
> message is distinct; you're still causing a problem by turning this on
> without a care in the world about whether two verifiers start spamming
> each other.

There's coverage in 7489 Section 7.2 that a domain owner can
inadvertently DDoS themselves via failure reports. And that still
surprised many implementers, even though it seemed obvious to them in

This case is even less obvious, and we still have questions coming in
about it from new implementers.

I don't think it's a security consideration because it doesn't scale up
the way "ruf" can, so it deserves a brief mention here. But I would
rephrase Ale's last sentence:

3.3.  Transport

   Email streams carrying DMARC failure reports MUST conform to the
   DMARC mechanism, thereby resulting in an aligned "pass".  Special
   care must be taken for authentication, as failure to authenticate
   failure reports may result in mail loops.  These loops can be mitigated
   by sending reports from a domain or subdomain that doesn't request
   reports, or by performing rate limiting for report receiving mailboxes.