Re: [dmarc-ietf] Clarification about data integrity within Aggregate Reports (Ticket #40)

Alessandro Vesely <vesely@tana.it> Thu, 31 December 2020 15:27 UTC

Return-Path: <vesely@tana.it>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51AA23A0D06 for <dmarc@ietfa.amsl.com>; Thu, 31 Dec 2020 07:27:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_kIvBHR0Y20 for <dmarc@ietfa.amsl.com>; Thu, 31 Dec 2020 07:27:23 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 897373A0D05 for <dmarc@ietf.org>; Thu, 31 Dec 2020 07:27:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1609428441; bh=n1q1eml+HkoREYW7256o+FJppNn9ApBVUDrni4Ohosc=; l=1735; h=To:References:From:Date:In-Reply-To; b=DXCf+hyDoTMGOvpiKFAUhMlcgkjNbbLjJcDYWVqTK73xC+115LebKdiQtUHDm0ee8 SU9Q6kao/7/VJpFsdQL44KJoqZ/n9wBYJbjBQm6R0sHMUa27zXH5Z5/DnwoqCpAkSL NdKmiqbataawrGy0EKJqffFzBJjtSSbTUjoG6IuAXSst4oWOjWf0JIC1azxts
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC026.000000005FEDEDD9.00001711; Thu, 31 Dec 2020 16:27:21 +0100
To: dmarc@ietf.org
References: <MN2PR11MB435151665586B5A40D101103F7D70@MN2PR11MB4351.namprd11.prod.outlook.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <59d0e09e-9296-c16e-94b1-8f344faf88d2@tana.it>
Date: Thu, 31 Dec 2020 16:27:20 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <MN2PR11MB435151665586B5A40D101103F7D70@MN2PR11MB4351.namprd11.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/-m9HhpcEOPUd2Pfoerd5iSrk784>
Subject: Re: [dmarc-ietf] Clarification about data integrity within Aggregate Reports (Ticket #40)
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Dec 2020 15:27:25 -0000

On Wed 30/Dec/2020 23:18:35 +0100 Brotman, Alex wrote:
> Hello folks,
> 
> There's an open ticket (https://trac.ietf.org/trac/dmarc/ticket/40) noting that we should clarify what constitutes valid data in a report. For example, the report cannot state that DMARC-DKIM was a "pass" when DKIM itself was a failure.  See the original thread here:
> 
> https://mailarchive.ietf.org/arch/msg/dmarc/Ii_dLXFzBNnRP361F922ty789I8/
> 
> It seems like the gist is that within the report it should never happen that DKIM or SPF are noted to have passed in the context of DMARC if they have not passed on their own.  It should also be properly noted by the reporter if they override with local policy.  Not by overriding the SPF/DKIM failures (and showing them as incorrectly passing), but instead by noting that local policy overrides properly (regardless of whether that override is higher or lower).
> 
> Does that seem properly summarized?


If the aggregate report content, Section 2.2, was well explained, the above 
text would be redundant.  The point is that Section 2.2 looks like a high level 
list of features.  It is completely useless for implementing a report producer, 
let alone a consumer.  We have to rewrite that section, possibly trying to 
re-use the same wording and the same order of appearance of concepts, so as to 
minimize readers' confusion, but strictly matching the content of Appendix A 
(was Appendix C).

The consistency checks above can be useful for building verification tools.

Let me take this occasion to recall that there are XML syntax check tools that 
can be used to automatically verify the syntax based on the schema.  We should 
write a more compliant XML in order to use them.


Best
Ale
--