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

Douglas Foster <> Sat, 16 January 2021 13:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4CC193A0C7C for <>; Sat, 16 Jan 2021 05:22:11 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 JkWnS2-CWTI0 for <>; Sat, 16 Jan 2021 05:22:09 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::932]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8CEE73A0C70 for <>; Sat, 16 Jan 2021 05:22:09 -0800 (PST)
Received: by with SMTP id u27so425928uaa.13 for <>; Sat, 16 Jan 2021 05:22:09 -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=Wih4KIYmLqGtP8fYSRnq1KrRYefkUnmLSsF2Xzhu4HQ=; b=hW8oVzz8Go7kLRfrXYlEvy+ArV+xd/zBSKGZJMOgfMRaM/N0SKHlWB9pkohVrZNL2/ fHFwEoyZzttwZVkz11VNInejriK+sdxwpRVaQVlUAiOT/vzV65ENS3tOF/KvM0joubHn gikOhp9eq94ZjRhHaH9QjOuaWXMSvtwgFMuUyg9Jrp0CZpQieTnXqqZi3y4Wltrmuevp 1YL8owKGFgOdRu+0hpUKzjGR/Pv6Q70RLBIkRPoprtnEKkXaTnVirgNRqq3FnxnS8XJI qnhVDIiS7s/Psqtq1WVE15nPrAFpFAB9OIs10t3QErnzhJFHlc2xO6wgYmD0nBRmAFep ooxQ==
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=Wih4KIYmLqGtP8fYSRnq1KrRYefkUnmLSsF2Xzhu4HQ=; b=af8pXwZpidkGXm9kWSrP/uYHH/KEjLIftvcUDni/88JydIbz8w93jv1JgsQb0N5N8k kUbOwdBI+tOsbMShip5fI7WenC7lMueEzqfrRbfshRJnSA9L/8kyH0AJ0G92YrcdwqBc ATtAau8wpmjXiLBAWJObjA10nOln6HvjlVXwpEGS9t4r6oDUOWWrfPDjpVjDKrkF2LY7 DmIKILvc3KahZPeMjXcMzpfeFLXltXXnUwagkrWAMOku+Lflc/nG0SrYM1Cps6hXLtF+ NGqbz4DMyNjizCes76oeDBRjofrtNtLSeubpMHEUerPcemkgqtxQ6Anf6AXeyuc3WkWF G0dA==
X-Gm-Message-State: AOAM532YgIyo0WdFE3xaehtOpj39dWa2Jt/Ltbl5rnCMs75fceefEEWP IZ9WbsYPCGyoBBNhhOB22oGr5gX0cIQM1R0xgCI=
X-Google-Smtp-Source: ABdhPJzz8ERZYmVO3LwznU+t8jVjA3z6sRGIEgG1qyXsapD3jwu+6QtLFQGQKGIeoEFO97feR/7zy48vxfg00/GP3cY=
X-Received: by 2002:ab0:770d:: with SMTP id z13mr13679891uaq.110.1610803328476; Sat, 16 Jan 2021 05:22:08 -0800 (PST)
MIME-Version: 1.0
References: <> <20210116034026.5C93F6AC0428@ary.qy>
In-Reply-To: <20210116034026.5C93F6AC0428@ary.qy>
From: Douglas Foster <>
Date: Sat, 16 Jan 2021 08:21:57 -0500
Message-ID: <>
To: John Levine <>
Cc: IETF DMARC WG <>, "Murray S. Kucherawy" <>
Content-Type: multipart/alternative; boundary="000000000000326b1b05b90460d2"
Archived-At: <>
Subject: Re: [dmarc-ietf] Forensic report loops are not 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: Sat, 16 Jan 2021 13:22:11 -0000

1) Because loop prevention is easily defined.
2) Because loop prevention is easier and simpler and less stressful to
implement than loop correction.
3) Because changing DNS to fix a loop is too slow.
4) Because a loop could be triggered by a malicious spammer, and the
feedback becomes backscatter.
5) Because DMARC reports are courtesy messages for the benefit of the
sender.   The sender has no significant interest in whether the message is
accepted or not.
6) Because loops cause congestion that affect other traffic
7) Because we have reports from the wild which indicate that loops have
actually occurred

Is that enough?

On Fri, Jan 15, 2021 at 10:40 PM John Levine <> wrote:

> In article <CAL0qLwaZx97cztehz_o=
>> you write:
> >-=-=-=-=-=-
> >
> >How are implementers dealing with forensic report loops?
> >
> >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.
> If the reports are unaligned and their domain is requesting failure
> reports, sending reports about the failure is exactly the right thing
> to do.
> I still don't understand why anyone thinks there is a problem to be
> fixed. If you don't want reports, don't ask for them. If you think the
> mail you send shouldn't be provoking DMARC failure reports, adjust
> whatever is sending the mail the mail is aligned, or get rid of the
> ruf= that asks for the reports. What am I missing here?
> _______________________________________________
> dmarc mailing list