Re: [dmarc-ietf] Versioning and XML namespaces in aggregate reports (#33, #70)

"Brotman, Alex" <Alex_Brotman@comcast.com> Fri, 14 May 2021 13:43 UTC

Return-Path: <Alex_Brotman@comcast.com>
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 E49613A3353; Fri, 14 May 2021 06:43:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.com
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 8EIxyzMrj-VR; Fri, 14 May 2021 06:43:18 -0700 (PDT)
Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (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 1C6863A334F; Fri, 14 May 2021 06:43:17 -0700 (PDT)
Received: from pps.filterd (m0156893.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 14EDevkP005073; Fri, 14 May 2021 09:43:17 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=20190412; bh=S6NseUHtKC1KKuzKll4N23J+ZZUTyrI9TqazkXNXPwg=; b=YfVt+wfDKFMFKHv3ER83+Be1WuxDygIDPMH/L4uydAydTniMN/XgfJtCkBabqD2ev/lY ftRKLvcIC0l2kBt8+J5BkTcyaas5+6GzKb4C99mTdHFdY6rNI1J2bb7jJ8txIPhvEwq8 DHNgvs/XaUDpzWeqMI2Sx/2PKDJAerQxsYJGsL6r4wYXhOd15kFU2m5gG3fqg+UYyNTr FbbC6OxFxYi922piojZjgoZmooBCZF7xwfiIVF58fH8qv+xEK2hRLY2+1NCX8HWwj975 Y/xjdCGdAg8fxlHwlGyeX4vgiJTkO5pC6wQv2Gve8upsa3BrkmtK+xihiMdkZTxL3jyR qg==
Received: from pacdcex52.cable.comcast.com (dlppfpt-wc-1p.slb.comcast.com [96.99.226.136]) by mx0a-00143702.pphosted.com with ESMTP id 38hc6wvgja-8 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 14 May 2021 09:43:16 -0400
Received: from PACDCEX49.cable.comcast.com (24.40.2.148) by PACDCEX52.cable.comcast.com (24.40.2.151) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Fri, 14 May 2021 09:42:58 -0400
Received: from pacdcexedge02.cable.comcast.com (68.87.38.198) by PACDCEX49.cable.comcast.com (24.40.2.148) with Microsoft SMTP Server (TLS) id 15.0.1497.18 via Frontend Transport; Fri, 14 May 2021 09:42:58 -0400
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.170) by webmail.comcast.com (68.87.38.198) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 14 May 2021 09:42:57 -0400
Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by MN2PR11MB4632.namprd11.prod.outlook.com (2603:10b6:208:24f::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.28; Fri, 14 May 2021 13:42:57 +0000
Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::1dc0:e771:def5:fde8]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::1dc0:e771:def5:fde8%3]) with mapi id 15.20.4129.028; Fri, 14 May 2021 13:42:57 +0000
From: "Brotman, Alex" <Alex_Brotman@comcast.com>
To: =?utf-8?B?TWF0dGjDpHVzIFdhbmRlcg==?= <mail=40wander.science@dmarc.ietf.org>, "dmarc@ietf.org" <dmarc@ietf.org>
Thread-Topic: [dmarc-ietf] Versioning and XML namespaces in aggregate reports (#33, #70)
Thread-Index: AQHXRaZZwVZRdVVDC0apP9O/3nrKB6rc1ukAgAARIICABQqlgIABDqUg
Date: Fri, 14 May 2021 13:42:56 +0000
Message-ID: <MN2PR11MB4351F2DDE26E28B76AF18AE4F7509@MN2PR11MB4351.namprd11.prod.outlook.com>
References: <bc3c25c0-2ec9-2e39-1dd6-1cc08521d03b@wander.science> <2bfed96b-9247-2af1-809c-4f8065ebf64c@gmail.com> <c49bc771-a95e-b78b-dc11-db0cb06ad688@tana.it> <44bdbe41-a43a-f6a4-9788-faaf67db6636@wander.science>
In-Reply-To: <44bdbe41-a43a-f6a4-9788-faaf67db6636@wander.science>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=comcast.com;
x-originating-ip: [2601:43:103:e60:6d93:f123:ddcc:8839]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4cce8ac9-6d4f-42ea-19e3-08d916de2ea7
x-ms-traffictypediagnostic: MN2PR11MB4632:
x-microsoft-antispam-prvs: <MN2PR11MB4632764F2178CAF14528C6CBF7509@MN2PR11MB4632.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: hDtWpVe5IMwR/yVy8QkoLjHh4GdlRt/nZ4EWQmaKTB1qluI+YXxq6DTOsF8+KNH3mDOehDzKozff4eZxPGBV+J8l7uJSzN4waLSk1vXHDtEJln8IJiypDcRXh7WFJDBbuAug4Cyap+B8PrXAqAAnZ1lUqGXLeOPax93UhLLawuQ2Airps+ne5UkUXx7vfraNyJ99b141SMgWE8c/CtG1E48djt5Cm1aJ+6waTXKOgqFVBTgWUlPnLbfgOs44g65BBvxB+j5qQ98mM3xG3i+PIeaf6Kb161LiqzqF7Q1RLDTyfkdBBs8D7bFOVLCQh/mSKiL/H2aGt8FTk++T9F4lP8rk/By4gvnkiVPyf+b1PIS7OjZp8QlMhR4upedc6j/LCdawHMoYnaE3Ui+qtxgxuo93QNA4lKy/MEz3WWajqyeZbjVCeO4UCFaxTkhnlNJG51SNdebBNMRaXEZwGgfkcYIOOiIGQnh1htzlqYj+KeyI76ccwM8/ZvDK3smAt5Ste3wjpwkFaOqQl8NjwHMWliZiTRTb8c+POdc5JuSsPsc1Qud/aKMhnaiHtmkNBY0P/w4dVAkGTa7N3/iJonhJHQVncljXpZK7gZ3vhL4s62zIQR6U25r04j27p9kSRJ4mXZ3zM5/eddfaGerCrZUcxQz22VKikI4ta+0hHk8gf6EyGEiOtYmItR1VtWphlchjwCPpeTYaHnfTj1m/Md0XUQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4351.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(39860400002)(366004)(136003)(376002)(396003)(38100700002)(66574015)(66476007)(83380400001)(66946007)(66446008)(66556008)(64756008)(7696005)(55016002)(86362001)(33656002)(9686003)(53546011)(76116006)(71200400001)(8676002)(186003)(966005)(8936002)(5660300002)(478600001)(2906002)(316002)(110136005)(122000001)(6506007)(52536014); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?ZWh0ZHArRFkxYTI5SG91Vkpqck9zem5qcTA3RCsvT05jM2lHdzFZZEV4ckpQ?= =?utf-8?B?d1R1RzRtbGdBZ01zQ2lITVZSam1mYXVTU0ltWmZvRGIrVjl2NEMxRmN6VW9k?= =?utf-8?B?L1RSNzRjRHZ2MXorYTRIeFdzOFBTWFRRT1F2eXBvQ28xNXZoeHVCaW9kREhY?= =?utf-8?B?ZUo1SFpYbWpxUTlHK1IzVFNOWWN2ZE5HSkd6OHhRazNJbjBJYUk0QUU2U0tG?= =?utf-8?B?bFRJZHE4NG9zK20zeFE2YWJCYnRYZlBHWmVNdCsyaHNmQ2h2WjBGNnN0c3ha?= =?utf-8?B?WjB2MTlaTDJNV2orMHdIdlM5cFJzcnFvRVlIOFdmMGRHOEpnM2ZlSFVFMWJk?= =?utf-8?B?aVVCdHFDTG0xbThWTXlIbDhMYWt0dk83dmUxZHJvWGRuTEl1RTZmVTl5VGFh?= =?utf-8?B?RDdLc2M1QnUyYVlmdTkxcjhsWFl0RGtRZjViRDh2Y09kb3A4NDNBd1MrRkZy?= =?utf-8?B?UW1UblVDTXBDT2JRWFBLRkwvd2RKMUVnVWhyZDR6bnd6TVJCUnR1STlTcThR?= =?utf-8?B?VG9TZW5wZWltbktxa2I4d29YbDlCalBpTHhVWi85TXNGb0NlcXVVZGFOSmFa?= =?utf-8?B?SCtDb0R5MjB1WVJGWjJnMkluRHZuVWViRS9rTGRTMmUxenJwNHZmNzR4ME1w?= =?utf-8?B?ci9lTVZTVWRSdDdrRVBZKzF1S0hYNjhRLytnUWxwa0RUWUhsL1ZCcFJBQnJF?= =?utf-8?B?ZXcxTVJpbGZIYVlDd3Y1cGdGTjNWSmNoNjdWc2lEbnJyQW5lV0E4RWplSC8x?= =?utf-8?B?SGVWRW0vTmpIYWN1TW9OTHNoQVBWZkZraTBIRHNwNTUyZW42d2hIRHRtbnhL?= =?utf-8?B?N2ljemNadjVRWXpWcHNTOFR6SjZPRlNRVGZ3cDJjVUxYQVBrWWZLeVlMclAz?= =?utf-8?B?VjBZNksvanhLTEphNlVsREdYUWk4YmlyTllzeVhOaUkyRjgxTitYTXhvdFR0?= =?utf-8?B?N1VyN0ZhTXA3bU5ZSmtqZVNwUkhnZS9JV2NpckhMQk9NWk9wcDhOSHprQk1v?= =?utf-8?B?dzVkdnJWZEppVU1oWjQwN0lGZ2hkVTBjWDRTakNhdVlBd0Exdzh3UXZwandL?= =?utf-8?B?ODRsUGtVRzI2ZkM3SjhJRHl2WmJiZzI2NmU4YitEeHVrbGFPbm5QM1JQZm91?= =?utf-8?B?TDlPQzNIamhYTk8vWUl5L2hqUEUvemVRekYyaGFYcUNsV2pHREVKV2VWM210?= =?utf-8?B?dlN0ZzNDMjd1NTVRandwZ0Z0TlN3LzI0bTQ4OVJJMXkwK2llQkpSOVkyTFRv?= =?utf-8?B?d0FsY1d0VXJOQ29nNnNZWWgwMUNtTFhxUGJZR29OZklqY04zMjZaK1lDemV3?= =?utf-8?B?MkJXVWRmRmphZVJtcGc1SVZNaThraU9tRkNCOXB1SXlnM0JxSGdyQXlEZlBm?= =?utf-8?B?MHUvZVhXV09MQWNTQVZ1VjBCUE16V05SOVJuZm1ycXdtSzQ4Z05DSmtFSkdv?= =?utf-8?B?eTZPZzJ3dEhUWlhRSTFwK1YyS29GczViNWg1azZkSUJLZ3pvS2dSYTJSR2ds?= =?utf-8?B?QnVvcTlnNU1KVmliY2xVajc5RmkvSlNObDJTSWFsYnpQdVFvY0I4MmxjUk05?= =?utf-8?B?cll3N0JZOXpTQVdRbFVoNmh5Z0JUNzQ0aVExUFl3bm43NzFLUE1IU0Z2QnNs?= =?utf-8?B?UjFJTHNOQ29kN0x0RmhYTjNjcWNycllvbktxcDYrTG83VnViUk9BUVlzbG55?= =?utf-8?B?RURDUlZpNHUrYVh4SERJY1dIQ3NZVEJzSGgrdksvblNjWTVsYkVGUU1SUStH?= =?utf-8?B?bzd6b0p5ajEyUVU1MHNGUXFKcHJ2Qk5seFg2aWMvbXl1cUM5MnBzTndsbHJy?= =?utf-8?Q?bKdpFZ+Li/llZh8qEYH9FfQ50iaBfZ2OWRkv8=3D?=
x-ms-exchange-transport-forked: True
arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UQcG4dm/RATFEPbvH6clQ2pNAyqFh5ojpNJaN7sh5KjIS+AwQv1h8kz9/d6xn0GhNoMbLethwi+BV2ISwOs4I5Wm/SoumRHtTvmJl2/K2O96XNWlp/J0J6UVL1xohdsyOk6XmxeL8eKjuj3us+CbAi5yI5WMhK2mIbQOFxI8uCdt9uECnNS6+G7W8OBhKQR3I0AtYMDtqcqbruvezSyBQC4/0OCwwhg3RGU8aZyuRbxZBUr2QXCL+JIDVbcoK1BJKox+btzt1gsv8xQcrvXfGNnhyEofz/1CdQbOadhDD/U7Kc7uHTd+Q63Ye5U6Zd5ogIjxzulil4JJw8SbOTM4HQ==
arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+eHZxKP0Er0sdVC3X4nJ33+M27sJFyOukeOMfFe/Kbk=; b=T8mUPeYGgIZETna8LLUHdQEe3AjdwcagFtcNll6v2xp9RN3gX3uBbKnMACuQixC2qOyEWDbskrHVBK5i//9uU/Nc39N0OUM/aCzCyj9RRpkXhTqFowsfA+HwXuPvgzT2VKpg+Sya3dr81G+SblVJioxxV23SwtdqsaLL8DJ66TZAT6sAcrxbBxD3w4bAcNkLoSn8qBXrR4/p1vgV3A1YG6W43NVECRj8Ih3XG3e5KZlil4iyUb1IeBLdjSLqQCkDG+jXm4ZZ10ltrhFqMtAJr5rSVdv/qa011/nhRQ3xR0XhnCsi8bcVMq91baAkJdH004HNaiNjB2wOnMwy28924Q==
arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=comcast.com; dmarc=pass action=none header.from=comcast.com; dkim=pass header.d=comcast.com; arc=none
x-ms-exchange-crosstenant-authas: Internal
x-ms-exchange-crosstenant-authsource: MN2PR11MB4351.namprd11.prod.outlook.com
x-ms-exchange-crosstenant-network-message-id: 4cce8ac9-6d4f-42ea-19e3-08d916de2ea7
x-ms-exchange-crosstenant-originalarrivaltime: 14 May 2021 13:42:56.8491 (UTC)
x-ms-exchange-crosstenant-fromentityheader: Hosted
x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa
x-ms-exchange-crosstenant-mailboxtype: HOSTED
x-ms-exchange-crosstenant-userprincipalname: 0juWv6YP8zg2Ck9JuUTE/9p4Dn1iddk4bT7ZEUyi9Bu9QfEQlyMsV032N7+3DOh+vA+eO6TY8QOoQFZDCd480WdHJkLyEc3ksvBuYFYDlHg=
x-ms-exchange-transport-crosstenantheadersstamped: MN2PR11MB4632
x-originatororg: comcast.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward AAETWS
X-Proofpoint-ORIG-GUID: 84f-gt_wxXqyd008S4NhKR0q3oaT6WUz
X-Proofpoint-GUID: 84f-gt_wxXqyd008S4NhKR0q3oaT6WUz
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-14_04:2021-05-12, 2021-05-14 signatures=0
X-Proofpoint-Spam-Reason: safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/Bfwun08oTIH6SiVUycfU8mQS2Zg>
Subject: Re: [dmarc-ietf] Versioning and XML namespaces in aggregate reports (#33, #70)
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: Fri, 14 May 2021 13:43:23 -0000

There are a few tickets that may break report ingestion systems due to structure and/or value changes.  Should we decide that's an implementation issue, or that we truly can't change the format of the reports?  I'm sure most ingestion systems are rather flexible given the number of reports that appear to not match what 7489 states/suggests.

If we are going to allow changes to the structure, and there is some concern about which version the receiver supports (or prefers?), should we put a flag into the DMARC record?  And of course, that may dependent on the receiver, if multiple are listed, so that would have to belong to each individual receiving address.

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

> -----Original Message-----
> From: dmarc <dmarc-bounces@ietf.org> On Behalf Of Matthäus Wander
> Sent: Thursday, May 13, 2021 5:29 PM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Versioning and XML namespaces in aggregate
> reports (#33, #70)
>
> Alessandro Vesely wrote on 2021-05-10 18:29:
> > On Mon 10/May/2021 17:28:20 +0200 Dave Crocker wrote:
> >> If an new spec merely /adds/ to a previous spec, then the presence of
> >> the new constructs is self-declaring.  The only requirement is to
> >> have the base specification declare that unrecognized constructs are
> >> to be ignored.  So, versioning adds the illusion of utility, but
> >> really only adds unnecessary complexity.
> >
> >
> > I think the format we'll end up with will be pretty compatible with
> > the existing practice, meaning that existing report consumers that use
> > a proper XML parser and ignore unknown tags can work unchanged.  I
> > don't think any consumer parses reports "by hands".
>
> Alright, introducing incompabilities is off the table and backward compability
> is a must. This brings #51 into question, which may affect backward
> compability.
> https://urldefense.com/v3/__https://trac.ietf.org/trac/dmarc/ticket/51__;!!
> CQl3mcHX2A!RCdb_46_lcqdxdM882JSzD-hjS-
> 66H5H0OL8qTxqEITjJ7dViYTApbhFoP1sF8sc-3FowsLllQ$
>
>
> Regarding the existing top-level <version> below <feedback>:
> Even if parsers don't require the version to function, it remains useful for
> measuring the adoption of the different DMARC specifications (as requested
> in #70). In fact, one implementation I looked at (parsedmarc) uses it for only
> this purpose. A missing <version> is logged as "draft"
> schema version.
>
>
> Regarding the XML namespace declaration:
> The XML schema serves not only as specification for developers, but can be
> also used for automatic syntax checks of reports -- provided that the
> namespace declaration is fixed. XSD validation is an immensely useful tool for
> testing the output of report generators. It helped me to discover two nasty
> bugs in an implementation, which appeared in 2 out of ~10k reports and
> would have gone unnoticed otherwise.
> A version number within the schema is not necessary for this use case.
>
> A different matter is whether automatic XSD validation on the report
> consumer side is a supported use case. There is some value in it: two lines of
> code suffice to perform input validation. However, the validation is strict and
> does not allow for being liberal in what you accept (might be handy for
> protocol police, though). Achieving upward compatibility is not trivial,
> because there is no general "ignore all unknown elements" statement in
> XSD. It is possible to define a <xs:any> placeholder in the schema, but this
> element must be inserted explicitly into each place where extensibility is
> desired. This would require careful foresight in the schema design.
>
> Regards,
> Matt
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc
> __;!!CQl3mcHX2A!RCdb_46_lcqdxdM882JSzD-hjS-
> 66H5H0OL8qTxqEITjJ7dViYTApbhFoP1sF8sc-3GZUejGJQ$