Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-03.txt

Matthäus Wander <> Fri, 27 August 2021 10:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E06A73A2ADF for <>; Fri, 27 Aug 2021 03:10:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Status: No, score=-2.101 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, 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 qe4oGcZDz41d for <>; Fri, 27 Aug 2021 03:09:56 -0700 (PDT)
Received: from ( [IPv6:2a01:4f8:13b:2048::113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 64EF73A2ADB for <>; Fri, 27 Aug 2021 03:09:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=cathay; h=Subject:Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Sender:Reply-To: Cc:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ymcbjF6p/sDa0uqH4fJg9sY+yDYhUDb5MFsvznmTHyM=; b=Bp/TBDbzBA1OpuTNMp6ZbnM4VT dpQJ4XJG+qO4aiz4RkNsbCTU6fcvu5SrykJHSHJJI1pXtU5VIljO44TdSnEH64GlPgy3+3nRrLH/v wiqNAJiJ98yFYzpj+stMmGhR1/zz8jXaYIfNw/SygR/RqEqKWcey5naIjlh+zOY2uIPBe1/T9DlZt yPDMDG/Eg8yqvlh8+AxD+ZXMm9u3TjxUq7oRVLU5sjoMTvwX6XlsYso+aVlC7ZyiZV6mpjDkd4mqI b3DMW/0EUCbUJ+Wg6nV1yuVOfDj/vqMqqRZLVmyKDZXrciL8UyvIjBuL3PKaVqTlGk98lmB15eRdK gX2M7EfA==;
Received: from ([2a01:c22:bca4:bb00:cd81:5841:c1e3:9e5]) by with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <>) id 1mJYo4-000zgq-2w for; Fri, 27 Aug 2021 12:09:52 +0200
References: <> <> <> <> <>
From: =?UTF-8?Q?Matth=c3=a4us_Wander?= <>
Message-ID: <>
Date: Fri, 27 Aug 2021 12:09:51 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 2a01:c22:bca4:bb00:cd81:5841:c1e3:9e5
X-SA-Exim-Version: 4.2.1 (built Sat, 13 Feb 2021 17:57:42 +0000)
X-SA-Exim-Scanned: Yes (on
Archived-At: <>
Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-03.txt
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, 27 Aug 2021 10:10:02 -0000

Scott Kitterman wrote on 2021-08-26 17:41:
> Why would a report be sent more than once?

Happens regularly with Google as reporter. Seems to be a design choice.

> Other than error cases, the only thing I can immediately think of is the case where the report was sent, but the SMTP session doesn't properly terminate so it's unknown if they entire report was received.
> Which leaves me wondering what the receive side processing should be?

> Should partial reports be discarded? (draft is silent on this)

CRC would break with compressed files in this case, i.e. the report 
would be clearly invalid.

If the reporter generates a partial report but with valid syntax, then 
the report consumer will have no way to detect it. Re-sending the full 
report may fix the issue (if the consumer implements an overwrite logic) 
or make it worse (if the consumer doesn't deduplicate).

> If a complete message has been received, then I think deduplicating based on the Report-ID makes sense (don't have to open up the MIME parts to do it).


> It's not clear to me from skimming the draft if one message can have multiple XML files or not (I'm less familiar with the details of the feedback part of DMARC).  If there can be only one, that's probably sufficient.  If there can be more than one, then there may be a case where one file was successfully received and stored, but another wasn't.  In this case, you would need to examine the MIME parts, so filename consistency would be important.

The definition of one Report-ID in the subject line implies that a 
message carries no more than one report. This could be clarified in the 
RFC, though.