Re: [dmarc-ietf] [EXTERNAL] Re: Clarification of Subdomain Reporting

Alessandro Vesely <vesely@tana.it> Tue, 15 December 2020 08:58 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 131153A0EA2 for <dmarc@ietfa.amsl.com>; Tue, 15 Dec 2020 00:58:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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 dNSHS1Bvb6Z2 for <dmarc@ietfa.amsl.com>; Tue, 15 Dec 2020 00:58:05 -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 5A3AF3A0E9F for <dmarc@ietf.org>; Tue, 15 Dec 2020 00:58:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608022680; bh=7ETuzV6fZkbsmu5rShwkGCEUChNM4u3kB0EHOEYrSfM=; l=2547; h=To:References:From:Date:In-Reply-To; b=BVIBygK1q259fZMsZ93EQ6ud8ETgswQggQac8ppxzwWahJrqXB2kGAvf5iZiFbv/B WfscSFCz2Kf5EWXWcqaZprKZJZAefx9/kMN4ZN7dZ09NbCVfoBbfzrcNy6qMds/5yV w1BSks9LQju2/2Q5L+Ajto3XYsvDxSoOAZ2K2W1yuC3WQ+U3qx31tM4dzCMkp
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.000000005FD87A98.0000475A; Tue, 15 Dec 2020 09:58:00 +0100
To: "Brotman, Alex" <Alex_Brotman@comcast.com>, John R Levine <johnl@taugh.com>, "dmarc@ietf.org" <dmarc@ietf.org>
References: <MN2PR11MB43510F27A700C9644F9BAED4F7CA0@MN2PR11MB4351.namprd11.prod.outlook.com> <20201211193845.63466297AE5D@ary.qy> <MN2PR11MB43518D41301988BB468B9D09F7CA0@MN2PR11MB4351.namprd11.prod.outlook.com> <a79f951b-683b-8271-9445-65f3633b30ed@taugh.com> <MN2PR11MB43512F98231121186E06B4B7F7C70@MN2PR11MB4351.namprd11.prod.outlook.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <089a1419-bc80-39b9-2825-c9ac8c4f9909@tana.it>
Date: Tue, 15 Dec 2020 09:58:00 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <MN2PR11MB43512F98231121186E06B4B7F7C70@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/UDrNbsTbRsezSLHltSXPxuKS9Ls>
Subject: Re: [dmarc-ietf] [EXTERNAL] Re: Clarification of Subdomain Reporting
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: Tue, 15 Dec 2020 08:58:08 -0000

On Mon 14/Dec/2020 16:57:53 +0100 Brotman, Alex wrote:
>> From: John R Levine <johnl@taugh.com>
>>>
>>> The goal was to clarify the language, without (to the best of our ability)
>>> changing the schema.  I'd welcome a other attempts at clarifications (if you
>>> believe mine introduces structural XML changes).
>>
>> So it'd say yeah, we know the XML lets you put multiple header_from
>> domains in the same report row, but please don't do that, send a separate
>> report row for each header_from?


I'm still not clear how could two From: domain fall in the same row.  Appendix 
C is very clear that there is a single IdentifierType for each row.  And each 
IdentifierType has exactly one "header_from".  I am appalled at the fact that 
such rule is not given in the text.  There has to be a better description in 
Section 2.2.  I'd propose something like:

     The bulk of a report consists of data for each message received during the
     reporting period, where each record aggregates messages having similar
     characteristics.  Relevant characteristics are:

Then follow with a revised bullet list.  It should be a descriptive equivalent 
of the grammar in Appendix C.  The current version doesn't match, obviously, 
since it confuses ourselves.  We cannot ship it as is.


> So it should be clarified as such:
> 
>     o  Data for each Domain Owner's subdomain separately from mail from
>        the sender's Organizational Domain, even if there is no explicit
>        subdomain policy
> 
> Perhaps changed to something more like:
> 
>    o A separate report should be generated for each 5322.From subdomain, regardless
>        of which policy domain was used during receipt of messages


That's excessive, IMHO.  If the recipient is the same, there's no reason to 
split that data into different reports.


> For the other thread with Ale, is there anything wrong with stating both minOccurs/maxOccurs set at "1" so that it's more clear that it must be once, and only once?


At the beginning of Appendix C there is a paragraph saying:

    NOTE: Per the definition of XML, unless otherwise specified in the
    schema below, the minOccurs and maxOccurs values for each element are
    set to 1.

It's hard to make it clearer than that.  Perhaps:

    NOTE: Per the definition of XML, each element can appear zero or more
    times, as specified by minOccurs and maxOccurs values.  When not
    explicitly specified, the default value for both attributes is 1.

After that, specifying the default might be more confusing than helpful.


Best
Ale
--