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

"Murray S. Kucherawy" <> Fri, 29 January 2021 01:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 401473A0925 for <>; Thu, 28 Jan 2021 17:15:16 -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 qNKZHhcI7NcC for <>; Thu, 28 Jan 2021 17:15:14 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::a2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AFF9B3A091C for <>; Thu, 28 Jan 2021 17:15:14 -0800 (PST)
Received: by with SMTP id e1so1808165vkd.10 for <>; Thu, 28 Jan 2021 17:15:14 -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=L9sVRGaDN21l64bM39/PBLUZi6xK7Mh/nBIBmXgdkPw=; b=KC0XADpRffI73j+bcq7QE5eCB8jjWmUs5xwxpSBqG3E4MUJ7Z/40B4FSGukBGXYAJ+ 5YFZI1jKOCnnaulAPGcZixPaI1QP+qGQh8CYGhPydsKkF3fo8NN0RmKiYLu8rs38m77B yNDGwS/kOLoU/K3Ytpp9pTY8IU11vBTy9nQToRxqP/+iuujVevMTLKz0joIlpZhxOlPl +PxVkkZWfmWPaqivIOAQyokPzvZvJZfhNGz3tHhqkodvjEnI2/t220S+Rm7XAC7Gs40H su2coo4vkrSqprg70jmZd+q8i9EMUQeapb1wIAT9XnvaWjWVcr8JRlEEvqG/KAdbNjf2 uVYw==
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=L9sVRGaDN21l64bM39/PBLUZi6xK7Mh/nBIBmXgdkPw=; b=sGnxbHdjnv6xC8M+DZZEf+yUmd+PtHYS+hqzAyxGj/GXu0ZiQANVQGIUflb8i5WWR/ vIg9batlfh/3CRSZuzIvJkI4Ve0wkL36rnoPvM/oPSiNM15URMlPJZQ8gQjHCNlGh0Ar iGa+eTyuw9151yHZ0gvDn7rNWBRKBL1rfln3SRRHbKTX9OcNHMeqdPVqRA43whtjcmoY qxI42agQ3Z77eRuJXTF0eZ7s09PLdHJBktOk+wmsrNVmVA9oRsZrIq8o+fb4qGLXURwr DZZMrCXBSDAEbWquK+yhZ+062mRbAGU+dEdVm62yD5/5d4s/5cOr8A2KUSGk+VhnQkoR sJMA==
X-Gm-Message-State: AOAM533s5NvaHQDdiiKOvaIaO44UCrE4rFCi/53j5xp7PkgGQOVKaNwE YNic3xyNrhr+RBpr6GWANzWHRVY9FDiBV7mDH2qW9Yb5on4=
X-Google-Smtp-Source: ABdhPJwhQMb0idgg83y4ypHDidrNeiR9beRqllm6rzn0JhZMaGC9bjKILjulbdUNBjYEUIPqG3emWNa8lJ7prx0vBkI=
X-Received: by 2002:a1f:3889:: with SMTP id f131mr1641598vka.22.1611882913323; Thu, 28 Jan 2021 17:15:13 -0800 (PST)
MIME-Version: 1.0
References: <> <20210127203714.007C86CDB9CA@ary.qy> <> <> <> <>
In-Reply-To: <>
From: "Murray S. Kucherawy" <>
Date: Thu, 28 Jan 2021 17:15:01 -0800
Message-ID: <>
To: John R Levine <>
Content-Type: multipart/alternative; boundary="00000000000077de3305b9ffbc80"
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: Fri, 29 Jan 2021 01:15:16 -0000

On Thu, Jan 28, 2021 at 1:42 PM John R Levine <> wrote:

> > This to me is almost exactly the same thing as saying "Don't generate a
> > bounce about a bounce",
> Because these are not bounces.  They are not even a little bit like
> bounces.  Bounces are about invalid recipient addresses, but these have no
> relation to anything about the recipient address.

Yes, I realize the difference.  I was making an analogy.

They are fresh new messages sent from a system that presumably cares
> enough about DMARC to send reports about it, and presumably wants to send
> all of its mail with DMARC alignment.  If they are unaligned, that is
> because the sending system is broken, and if that systems publishes an
> ruf= tag, it is specifically asking to be inforned about exactly that
> breakage.

OK, let's hop into your example.  I care enough about DMARC to send reports
about it, and I want to send all of my mail aligned.  I send a test message
that ends up unaligned somehow, perhaps through a broken relay I don't own,
and I would ideally like to get one message back that tells me that.  If I
happen to send my test to a place that unintentionally sends an unaligned
report back to me, perhaps because of the same relay, I'm going to get
flooded, even though my local setup is verifiably correct.  And, probably,
so are they.

You're saying the only real answer here is that the two end operators in
this example need to fix their evidently-crappy setups, or change their DNS
records to remove the "ruf" value until they can get the guy in the middle
to fix whatever's broken?

Maybe I'm the dim one, but I can't see why it's manifestly absurd to think
we might somehow augment either the report or the message containing it by
adding just enough metadata someplace to signal one end or the other, or
both, to avert the flood.