Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

Steven M Jones <> Mon, 25 January 2021 21:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 770423A18FE for <>; Mon, 25 Jan 2021 13:26:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[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 PoA8L6vN449E for <>; Mon, 25 Jan 2021 13:26:52 -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 120EC3A18FB for <>; Mon, 25 Jan 2021 13:26:51 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.15.2/cci-colo-1.7) with ESMTPSA id 10PLQbpr063604 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <>; Mon, 25 Jan 2021 21:26:47 GMT (envelope-from
DKIM-Filter: OpenDKIM Filter v2.10.3 10PLQbpr063604
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=201506-2k; t=1611610009; bh=uArxSRhtd98GICkt9hgN1eixM2hBDDZ1pSItvcyUGU8=; h=Subject:To:References:From:Date:In-Reply-To; b=ihtV3caqUGUT2Meh6tdQFtM4zg3e23rpsGGYK8UYMCW0qxjkFtVHSZAWge4NTPEfE FhbHqIP7XGx/5xiBM/15ODX8eA9DA8xoNBEaRygeK8v7FmFPp4wrU2GYSOkacqab4x o/9zNv3d1HQxTykeh3leOh7uW3RfNyDWOCFOIhpOoq83XhjF65HYMkaUQThCM5AL6h nbggdRuccSishsBeHpudz251FrrH8RlB9HDXbJ1oKXa9iH8YLuuqsxdvFYaNquwAOV k+M87T1eNcLlTvuHAkTQ7pxRFH4YKu0HIC0nSdj3k/YpmUaI4uMN68b3A45yd+zgFQ AtSatQ55Rllgg==
X-Authentication-Warning: Host [] claimed to be []
References: <20210125195231.E0DE16C13E26@ary.qy> <> <> <>
From: Steven M Jones <>
Message-ID: <>
Date: Mon, 25 Jan 2021 13:26:37 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------E3AEF1F3B410333A873C97E0"
Content-Language: en-US
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 ( []); Mon, 25 Jan 2021 21:26:47 +0000 (UTC)
Archived-At: <>
Subject: Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help
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: Mon, 25 Jan 2021 21:26:53 -0000

On 1/25/21 12:18 PM, Michael Thomas wrote:
> On 1/25/21 12:08 PM, Todd Herr wrote:
>> On Mon, Jan 25, 2021 at 2:56 PM Michael Thomas < 
>> <>> wrote:
>>     Sounds like a bug to me and an issue should be opened. Just
>>     because it's
>>     a 10 year old bug doesn't mean it's not a bug.
>> I disagree.
>> Authentication results should not differ at a given provider based 
>> solely on the destination domain, so there is no reason to report 
>> results separately for each destination domain. Further, there's no 
>> value to the report generators, especially at large sites like 
>> Google, to expend the resources necessary to generate and send X 
>> reports when one will do.
> So you're saying I should be free to spoof any domain I want because 
> Google might be inconvenienced?

If the language in that Seth cited is "working," then report 
generators are sending reports that pass DMARC and the report receivers 
are validating that before ingesting the attached reports. However this 
only provides some degree of attribution for the report itself...

We can certainly check with report receivers to confirm that they are 
doing that validation, and perhaps get some measure of how often they 
see reports that don't pass. What does that leave us with?

Assuming "works," reports that don't pass DMARC won't be 
processed, and won't cause the confusion and/or delayed implementation 
you cited as the potential harm.

That leaves reports that pass DMARC, sent from domains that haven't 
actually handled the sending domain's email. This sounds to me like 
reports that contain false data. Reports containing false data are 
identified as a security consideration in RFC7489 Section 12.2, without 
a reference to as the suggested mitigation.

I don't see where additional authentication of the report itself can 
address this concern, given the availability of disposable domains. That 
leaves report receivers with the need to track report senders' 
reputation, which might warrant a mention in the revised spec.

What did I miss?