IETF Logo Mail Archive

Re: [dmarc-ietf] understanding section 7.2

Alessandro Vesely <vesely@tana.it> Thu, 28 January 2021 12:24 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 701D13A10A9 for <dmarc@ietfa.amsl.com>; Thu, 28 Jan 2021 04:24:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
X-Spam-Status: No, score=-2.121 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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 i2OKKVAST0cX for <dmarc@ietfa.amsl.com>; Thu, 28 Jan 2021 04:24:17 -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 F379B3A109C for <dmarc@ietf.org>; Thu, 28 Jan 2021 04:24:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1611836654; bh=urD5LxM0w5ERqL0SeZwSnzXM6ctWg5Whd6P8xstPn9M=; l=908; h=To:References:From:Date:In-Reply-To; b=B8ROO5jzqJox2Z4KqkIQlG76iVTvqKmqPDSHVQX3eVvq7XtXJn16DSjvDuZssWfdr xcq6p+xNb2yrGA8DOAIuUUUydiRkpAxpQhQcazjX4dYQ3QEb57vnfSGL1/Wlh1CvD0 Ls8T1kPFtfa5aiJ95H+bJoMzwSn3aEfT/66fOnD01obamwvPhxymGG3dXSEKL
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 00000000005DC09F.000000006012ACEE.000001F3; Thu, 28 Jan 2021 13:24:14 +0100
To: Michael Thomas <mike@mtcc.com>, "Murray S. Kucherawy" <superuser@gmail.com>, "dmarc@ietf.org" <dmarc@ietf.org>
References: <2aaebb6b-6518-19cd-d32d-8370c0adb6d6@mtcc.com> <CAL0qLwbJcUCR6DykMQVe5d6rvdgiF=+cA+r65thx-Bub3qPZ7w@mail.gmail.com> <204a52fc-92ef-bc3c-2870-12e14911ae11@mtcc.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <07ab4ba5-d06e-576e-405f-d80121847788@tana.it>
Date: Thu, 28 Jan 2021 13:24:12 +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: <204a52fc-92ef-bc3c-2870-12e14911ae11@mtcc.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/o5IjmyBHqGKEoUMdL8Fsv0VQrEI>
Subject: Re: [dmarc-ietf] understanding section 7.2
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, 28 Jan 2021 12:24:18 -0000

On Wed 27/Jan/2021 21:18:50 +0100 Michael Thomas wrote:
> On 1/27/21 12:14 PM, Murray S. Kucherawy wrote:
>> The schema's already pretty large, and probably has to be, but maybe a 
>> trivial example report would be reasonable to craft and include?
> 
> Yeah, that might do too.


+1.  It can be produced starting from a real report and replacing IPs and 
domain names with exemplifying ones.


> I think it's important that it be in section 7.2 though because you should
> be able to read that section and understand what the report is and isn't.

The full report should go in an appendix, because it is too long to make sense 
in the middle of text.  Section 7.2 may show the corresponding tabular form[*], 
which provides for a visual summary of fields, and reference the appendix.


Best
Ale
-- 

[*] A tabular form is showed here:
https://en.wikipedia.org/wiki/DMARC#Aggregate_reports

v2.23.0 | Report a Bug | By Email