Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56)

"Brotman, Alex" <Alex_Brotman@comcast.com> Mon, 25 January 2021 19:53 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 772C13A1850 for <dmarc@ietfa.amsl.com>; Mon, 25 Jan 2021 11:53:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.109
X-Spam-Level: *
X-Spam-Status: No, score=1.109 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MISSING_HEADERS=1.207, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 1EaE9chuoHJM for <dmarc@ietfa.amsl.com>; Mon, 25 Jan 2021 11:53:21 -0800 (PST)
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 023CC3A184F for <dmarc@ietf.org>; Mon, 25 Jan 2021 11:53:20 -0800 (PST)
Received: from pps.filterd (m0156891.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 10PJjpWs019272 for <dmarc@ietf.org>; Mon, 25 Jan 2021 14:53:20 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=20190412; bh=qbU2cPwiJLpaQhYUOsvPkE1EIU+jNfqXEIqvMK2MKGk=; b=T+7yhMqz1R2g1UnEbOYAmkFNyeHdTgW2M57NR/nTKxMGnq7wo9idVfrmaaM7Qxde8kV5 6ptAM/WyILwgtWMevHi9zkdVTyQWX+6FWrPcvLUKad0Wi0YLn5dSu9I1JSX8FV19dtq+ VMW8Ozt2Lszoh55EoDymEd9EHpstqmsP3S7ltQ9VEudikpVDC8+WZwufkpBqx3j+UP+6 R/eQ0JFmY9H0eTqt1+32u7Dq/MJeHsef39pM2kbGC443svwjc+PyfG2kCp1ZdzRjHdrl ZqD2Pau6jtHENIdD/9sRi+7YaH7+8UrvlGMH9Tno2ZWLVAXGrjHCI8GPTSErOYzjOH/R 4A==
Received: from copdcexc35.cable.comcast.com (dlppfpt-po-1p.slb.comcast.com [96.99.226.137]) by mx0a-00143702.pphosted.com with ESMTP id 368hh0cjxp-8 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for <dmarc@ietf.org>; Mon, 25 Jan 2021 14:53:20 -0500
Received: from copdcexc33.cable.comcast.com (147.191.125.132) by COPDCEXC35.cable.comcast.com (147.191.125.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 25 Jan 2021 12:53:08 -0700
Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by copdcexc33.cable.comcast.com (147.191.125.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5 via Frontend Transport; Mon, 25 Jan 2021 12:53:08 -0700
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.102) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 25 Jan 2021 14:53:10 -0500
Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by BL0PR11MB3506.namprd11.prod.outlook.com (2603:10b6:208:31::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.13; Mon, 25 Jan 2021 19:52:43 +0000
Received: from MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::7ca6:b482:a6b0:4d42]) by MN2PR11MB4351.namprd11.prod.outlook.com ([fe80::7ca6:b482:a6b0:4d42%7]) with mapi id 15.20.3784.017; Mon, 25 Jan 2021 19:52:43 +0000
From: "Brotman, Alex" <Alex_Brotman@comcast.com>
CC: DMARC IETF <dmarc@ietf.org>
Thread-Topic: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56)
Thread-Index: AdbI4+CbIMDOrFacSCuqUWajtLQ8TwAgvwMAAA97pBAAAfRzAADOhtAAAC42nxAC8UhBgAAllgIABlXaiUA=
Date: Mon, 25 Jan 2021 19:52:43 +0000
Message-ID: <MN2PR11MB43511F9FDADE0A6779870620F7BD9@MN2PR11MB4351.namprd11.prod.outlook.com>
References: <MN2PR11MB43512A1BB729A717B6E688DFF7F30@MN2PR11MB4351.namprd11.prod.outlook.com> <d14f03ef-f4fd-1b7a-699c-c670dcd9631c@tana.it> <MN2PR11MB4351A6BF2052A98DF95EA2C6F7F20@MN2PR11MB4351.namprd11.prod.outlook.com> <b00d374d-392c-5383-a4a1-31dc26d8e484@tana.it> <caa661e5-dead-493b-ad27-8fef74b5499f@beta.fastmail.com> <MN2PR11MB43511AD9A2B8C6CF1356491DF7CD0@MN2PR11MB4351.namprd11.prod.outlook.com> <CABZJ8knMmn-DmAQ_5TuDO13Rsu8=f9R2=XG3GFvpL=Uqy5RMJw@mail.gmail.com> <MN2PR11MB43518DB46CF9F6C5A6080C65F7D70@MN2PR11MB4351.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB43518DB46CF9F6C5A6080C65F7D70@MN2PR11MB4351.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=comcast.com;
x-originating-ip: [2601:43:101:380:a15b:1edf:6851:816e]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c2daaba5-4d85-4a32-e6be-08d8c16ac789
x-ms-traffictypediagnostic: BL0PR11MB3506:
x-microsoft-antispam-prvs: <BL0PR11MB350667456116A9AC6B945B82F7BD9@BL0PR11MB3506.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: FVsCIkNeWHm4h67h+pT+Hrns6AZHPXaCuUeUPa1gH5X3lz/F7J/w4N5WDFrxpBmi18RQaJxo2vE7b22mfN6N5Eo2es1wsjTlmET4Vyf6jfSaSILqKxPbcJSP1yFLTyvToYrzRvjAhMhzMevMZ3RWXHFyCU5b1p/F9IBM3gQc7w/8tixZ51m/FsBV+IVq5cMOcJaP+7ljlMV1/ML2xGy1/2P4Cvmq50NtmT6rWW7jSUFuZ//RtiVcwzHeqFnior+nrs42z19IhlmYJt0T/upewa7oPFEr7p5TewszGHZLAwR8KOWIB6ayPDQmUgqOxva9VLM9CUBNk03AWxAQhkafqL4xVJxkjaOYhp9nugIxZrIIayc0rlOzcIVOGzGev4nXGjm7+EVxATxwlCmXj/KzelyNdgRP7DXZPsKxOx9MVMQhkiAfg0VCEORJCXIzzUZ3yIOR2uEXag+iV3DsIgYoFw==
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)(366004)(376002)(346002)(396003)(136003)(39860400002)(66556008)(53546011)(64756008)(66616009)(33656002)(7696005)(66946007)(76116006)(66476007)(99936003)(8676002)(66446008)(186003)(83380400001)(52536014)(6506007)(86362001)(71200400001)(5660300002)(2906002)(166002)(478600001)(4326008)(9686003)(109986005)(966005)(316002)(8936002)(55016002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?TXRsd1VkdE5zU0FZTXVyS1N0c1gzNUI1dHZlWEF4dFVaZjVvdVFTaVdlV003?= =?utf-8?B?K0JsYTZsNU9TSWpEdytrdS9VWTlmSnRnSVlvaTlMTXdXWWY3cUswc21Zd1Uw?= =?utf-8?B?dXp3WFBoUnMzMkRaLy9MU1MzSDBRQVNUMEsxZ2NJakc5TmJJVTRxMnRTdUl1?= =?utf-8?B?L29hQXB0d2JDeW5NNTY5eU94VUh0UXdlRzFpMm1CWjA4dk45dkNVeTNGTlY0?= =?utf-8?B?clpyMjVQZHhuUUFQRUlEZk5KWFcwcktCZlJvYjNmM2VZS0FsN1Vna3owYlBS?= =?utf-8?B?cXZ1cXZDMHFSZnNvQzJKRzZTdDJnaHAxV29GcHFHV2NlZE9LcHRzUHBZMmFr?= =?utf-8?B?NG95WWVpbzdYQWdtY08xZXFrNVB2TWRpQ3pMRlV0djZacFNpTWV5OXBYZCtw?= =?utf-8?B?cVI3MEVEOWF3WTBvd0t3ZWp3M2NCY3FTUWdpUmsxT0ZhVW9BaDFDSGhwMnBa?= =?utf-8?B?Rmd1cWVyK2RMZS9LaXZ4UUlNQk5HWnc3K2FKL0NZZzNhRkVBaWpWaXRGOTZl?= =?utf-8?B?Y1hQdTI5N3o5U1dOWUF2Z01pbVJRa3ExOWFnUzA2VVdTQ0dyZkp6bGlZWndF?= =?utf-8?B?NmJEQmpqZGtLSXl2NXVIMEJIM2lXRzVoam9jd2hZbWs0ajlzdWRSNXYxUVpL?= =?utf-8?B?TWlNK0VxZS9VOXVrUTJMSUtTOUx6QVpOVXMvRjM4bGIxQVJWZlhMSE5vQi9U?= =?utf-8?B?T2poUEZ3cU5mZlRPdUZSZytNM3FrY3FLOGh5dVp0emhQME5TT0dHOXBlN1k0?= =?utf-8?B?UkJXZ3BkdktXYlNiTEtBSGRORGZ3NUR1bnRlSUh4VUthU2hPMk1ub3lLRzVv?= =?utf-8?B?cmJzcXNoOFVVZ3hWbTRWQUk0UXFtcjdOeHBWZEEzekZKSzF2QVhYMzRuUDUr?= =?utf-8?B?L3ovcUYyNzE3SFg2WlR2OGgzZ2ZudTIyclhycmJFTUhwblBnRDliY2JmYVNy?= =?utf-8?B?RHRGQkFRTU1mYVZ1Y0d3cGJvNXB5ZXFmRDZkWHZpdjdKU21EQURoNmhsVVE2?= =?utf-8?B?Z0JCUWtwNHlUYkphL1B0VmlYRGhwUkJaNkJab2tGWllGWWo1eTdRMEk4Zklo?= =?utf-8?B?UW0vejFLWngxc1FrcFlVWWdRaWpsQUYxMHZtTk44L25Qc3VTK0lpRytwRmQw?= =?utf-8?B?ZFNDbHErSmhBTEVDTktpOUlPd0ZlUGszRnYvbE1KUDNuUnR6RXJtZVlaL3Bk?= =?utf-8?B?bU00Y2s5ajFzQlFZT0lKeVBON3pKYnExdW9Va2JzQkhONTFybWd2SFFDQTFI?= =?utf-8?B?MG5sWXBlbWgzSWsxZ1NJZ2o2bDZFNWdFSDBPS0cxbU9XZG1nZUFpbzZxYXBZ?= =?utf-8?B?MkFXVkJZd2gwNEhGN1lGM3QwUlhNZld2ajFzbzJtMGFDRHBXTk9ubzF4OFBZ?= =?utf-8?B?ckhIOXhCYlRpVkQ0NlNOTzhsS0JzdXFxYUc0bkNMWldYOVBNT09IdXBFbm9z?= =?utf-8?B?bG9KNmlqQnd0Z3U4ZE0vRGQ4clBWRmVMTVgyRXdsTEVIMUpOYzJ2c2hpSUYy?= =?utf-8?Q?j92VSxZUlxWU0fia3eGfvnPX9rT?=
x-ms-exchange-transport-forked: True
arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YsM8jPF9R7lGHlvTpS+BKBLHkOchSC+8TvJMISQmGPV0/nOzIOQcE6mwXI8GJ4XTrkas4tWIwNTZ9QQBx5XkjI3ZPxHYnHmF1lz+Erxj27LiufbJ4821qR119L86sztdgFx66WxrZAc0oPmwg/mvBlH7hgN6MDl0XKouLfn0NvMfkmHg0eA5GivCq7b3AILEqsUuGFdfy+Y/+TFPZtD8pBij65dgiw82g/zd7iLc5jMgcI/O1gULB2j84SGtFtjdG/Z25AgasRXgHRgDhXRwwKm2EsyHuFgii2QrPUnOnu+bvnkWItNTDNl4a+rsYc3jdYRq36T8s5H3kUWyZvw0qA==
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=RI+mpvA2vXS8bIkdwXqfUkm7dq0yo/PT3ltNXe8u6zE=; b=m8HZfAvP1ZaD5m0QrL2mcwOq+LRdPPfZQ5wMPpzSNcR6++xL+Xp/edrZwX6i67Quo/IS+gOXPxxcM6lSp2/8G1nLi/ChEJOnqNC1z1RqRUF6A7ffEGrkE/LfHeRY8O1iFDEnt2N5ItEgL5PLWYqJ4qmJIZpj0WbUr7d25Wljo9XMWM8lXxn88zNIUN2b3S4LwAzf659qKmELj5RGGCuNZhv+drlsnm1/Jf4y1aHtjs+4e0hwRSc+NLp189z3eDekdoLATVJ4u9+MPC5sHmYHvy3HxPq15TvMi/Ewwo5pxY+3jHodg0owP/fh5gVZRjI88g6GRn/vxNBTlPQ0oRvmIg==
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: c2daaba5-4d85-4a32-e6be-08d8c16ac789
x-ms-exchange-crosstenant-originalarrivaltime: 25 Jan 2021 19:52:43.0913 (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: qSk5F1uxAWOPPHYPR+QNhH2cao4LLSHhC8zm6dnTKuWy62B7KsimBmN4ZbJM2BalxJyaMqQNLDCpMT6zAZga/jEEh9BkTA0q4Q59UIC5opA=
x-ms-exchange-transport-crosstenantheadersstamped: BL0PR11MB3506
x-originatororg: comcast.com
Content-Type: multipart/related; boundary="_004_MN2PR11MB43511F9FDADE0A6779870620F7BD9MN2PR11MB4351namp_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Forward AAETWA
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-25_08:2021-01-25, 2021-01-25 signatures=0
X-Proofpoint-Spam-Reason: safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/QjPXfjKX1eO7MEcpxzjnaUHXDAw>
Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56)
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: Mon, 25 Jan 2021 19:53:23 -0000

This thread tailed off over the holidays.  For the moment, I’ve included a small section in the draft that allows for an optional “extensions” element in the aggregate draft, being optional for both report creation/ingestion.   I’d be happy to work with someone who has an idea of what an ARC report should look like if it were to be a self-contained piece of XML within the main DMARC report.  That could help drive this section as we move forward.

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

From: dmarc <dmarc-bounces@ietf.org> On Behalf Of Brotman, Alex
Sent: Wednesday, December 30, 2020 4:49 PM
To: Emil Gustafsson <emgu=40google.com@dmarc.ietf.org>
Cc: Marc Bradshaw <marc@marcbradshaw.net>et>; DMARC IETF <dmarc@ietf.org>
Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56)


We’ve already mentioned ARC.  Could it also be extended to allow for Domain Reputation reporting back to the sender?  Instead of a central access point, the data is sent periodically to the domain holder, and they can then utilize the data as they see fit.  I could also see a use case for BIMI reporting.  I’m sure others could think of other use cases.

If we prefer it to exist outside of the main body of data, it may result in duplication of data, but also allows for more flexibility. This allows the original DMARC Aggregate data to remain consistent as well.  On the other hand, allowing it to exist within the record elements would allow it to be more easily correlated with the existing data.  I think my (slight) preference (as a report handler) is to have it outside of the main body of the report, but I could be swayed.


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

From: Emil Gustafsson <emgu=40google.com@dmarc.ietf.org<mailto:emgu=40google.com@dmarc.ietf.org>>
Sent: Wednesday, December 23, 2020 2:49 PM
To: Brotman, Alex <Alex_Brotman@comcast.com<mailto:Alex_Brotman@comcast.com>>
Cc: Marc Bradshaw <marc@marcbradshaw.net<mailto:marc@marcbradshaw.net>>; DMARC IETF <dmarc@ietf.org<mailto:dmarc@ietf.org>>
Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56)

While the common format would be great as a consumer of reports, I'm wondering how many different reports there would be. New auth standards don't pop up that often, so what other reports are you thinking about? I can see two obvious candidates; the mailserver software and the spam/abuse prevention software. It would be interesting to support something like that too but shouldn't those just put the results inside the dkim/spf/arc auth_results?
/E

On Tue, Dec 8, 2020 at 12:29 PM Brotman, Alex <Alex_Brotman=40comcast.com@dmarc.ietf.org<mailto:40comcast.com@dmarc.ietf.org>> wrote:
I feel (as a receiver of reports) as though another reason to have these as a single report is so that the receiver of the report is able to more easily correlate the data/times.  I should be able to believe that all reports (without a specified ri) will be 0000-2359, though things happen, and systems break down.

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

From: dmarc <dmarc-bounces@ietf.org<mailto:dmarc-bounces@ietf.org>> On Behalf Of Marc Bradshaw
Sent: Monday, December 7, 2020 5:17 PM
To: DMARC IETF <dmarc@ietf.org<mailto:dmarc@ietf.org>>
Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56)


There is value in including these in one report, especially where the extended property being reported on influences how DMARC is evaluated.

Using ARC as the example, when a p=reject policy was overriden by the receiver because of an ARC evaluation, when that data is included in the report the indirect mail flow can be clearly seen, which would not be the case if ARC were included as a separate report.

This could be included in an <extension> element, or could be included directly in the auth_results section of the report, based on an assumption that the things being reported SHOULD have an authentication results entry in processed mail.

<auth_results>
<dkim>...</dkim>
<spf>...</spf>
<arc> (as defined in arc standard) </arc>
<foo> (as defined in foo standard) </foo>
</auth_results>

These would be defined in a registry with reference to each standard, and parsers would ignore any sections they did not understand.

On Fri, 4 Dec 2020, at 6:43 AM, Alessandro Vesely wrote:
On Thu 03/Dec/2020 19:54:51 +0100 Brotman, Alex wrote:
>
>> -----Original Message-----
>> From: dmarc <dmarc-bounces@ietf.org<mailto:dmarc-bounces@ietf.org>> On Behalf Of Alessandro Vesely
>> Sent: Thursday, December 3, 2020 6:24 AM
>> To: dmarc@ietf.org<mailto:dmarc@ietf.org>
>> Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56)
>>
>> On Wed 02/Dec/2020 20:46:54 +0100 Brotman, Alex wrote:
>>>
>>> While this ticket/enhancement specifically mentions ARC, I could
>>> perhaps see the usefulness in other places.  It seems like it would be
>>> more beneficial to create a method by which other documents could
>>> provide XML- based "extensions" to the report.  This would allow
>>> mechanisms relying on DMARC to independently define their reporting
>>> schema to be included in DMARC aggregate reports.  Alternately, we could
>>> focus specifically on ARC, and work to include that in the base XML.
>>> This means that any later reporting requirements could again require
>>> changes to the core drafts.>>>
>>
>>
>> Another possibility is for ARC to define its own report format.  Hijacking
>> rua= targets to send a different kind of report should be allowed.
>> Otherwise, we could define a new tag, e.g. rue= (e for Extension).>>
>> In either case, as we're introduce variations in aggregate report content,
>> we have to devise a method for determining what version/kind of report is
>> attached to a given message.>>
>
> We could add an element called "<extensions>", and we allow ARC or whatever
> it may be to exist under that element.  The Aggregate Reporting document
> needs to specify that any extensions are expected to be proper XML, and if
> there are no extensions, an empty element is sufficient.  We could create a
> bit more structure as a requirement if we wanted:>
> <extensions>
>    <extension name="arc" standard="ARC_DMARC_REPORTING_EXTENSION_DEFINITION">
>      ... (as defined in referenced standard)
>    </extension>
> </extensions>
>
> If a report parser doesn't know what ARC is (or any of the extensions), it could skip the processing.  I do understand this means that <extensions> element may break existing parsers, even when empty, though, I expect many of the things we're proposing may fracture the expected XML.


We can do a better job at producing aggregate reports with an automatically verifiable content.  For example, prepending stuff like this:

<?xml version="1.0" encoding="UTF-8"?>
<dmarc:feedback xmlns:xs="http://www.w3.org/2001/XMLSchema-instance<https://urldefense.com/v3/__http:/www.w3.org/2001/XMLSchema-instance__;!!CQl3mcHX2A!W_xDXVx707gc61M5TAh1t1CL61wpj57BHndbtFxULnxLzggrXnZfXLDP5T6PCW5mqmCE$>"
xmlns:dmarc="http://dmarc.org/dmarc-xml/0.1<https://urldefense.com/v3/__http:/dmarc.org/dmarc-xml/0.1__;!!CQl3mcHX2A!W_xDXVx707gc61M5TAh1t1CL61wpj57BHndbtFxULnxLzggrXnZfXLDP5T6PCX_7HCv_$>"
xs:schemaLocation="http://dmarc.org/dmarc-xml/0.1<https://urldefense.com/v3/__http:/dmarc.org/dmarc-xml/0.1__;!!CQl3mcHX2A!W_xDXVx707gc61M5TAh1t1CL61wpj57BHndbtFxULnxLzggrXnZfXLDP5T6PCX_7HCv_$> rua.xsd">
<report_metadata>
        ...

(Perhaps something better than "http://dmarc.org/dmarc-xml/0.1<https://urldefense.com/v3/__http:/dmarc.org/dmarc-xml/0.1__;!!CQl3mcHX2A!W_xDXVx707gc61M5TAh1t1CL61wpj57BHndbtFxULnxLzggrXnZfXLDP5T6PCX_7HCv_$>" for the version)

But then, would the <extensions> imply dmarc-xml grammar should be upgraded every time ARC (or whatever) is upgraded?

Separate reports sounds simpler.


Best
Ale
--

















_______________________________________________
dmarc mailing list
dmarc@ietf.org<mailto:dmarc@ietf.org>
https://www.ietf.org/mailman/listinfo/dmarc<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;!!CQl3mcHX2A!W_xDXVx707gc61M5TAh1t1CL61wpj57BHndbtFxULnxLzggrXnZfXLDP5T6PCcp8JAZr$>


--
[Image removed by sender.]

  Marc Bradshaw
  marcbradshaw.net<https://urldefense.com/v3/__http:/marcbradshaw.net/__;!!CQl3mcHX2A!W_xDXVx707gc61M5TAh1t1CL61wpj57BHndbtFxULnxLzggrXnZfXLDP5T6PCcwnsT8Z$> | @marcbradshaw<https://urldefense.com/v3/__https:/twitter.com/marcbradshaw__;!!CQl3mcHX2A!W_xDXVx707gc61M5TAh1t1CL61wpj57BHndbtFxULnxLzggrXnZfXLDP5T6PCZsg4P4v$>



_______________________________________________
dmarc mailing list
dmarc@ietf.org<mailto:dmarc@ietf.org>
https://www.ietf.org/mailman/listinfo/dmarc<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;!!CQl3mcHX2A!Q0kR1p9xGxnWAG4hjlLpp_yisW1Dhd4n3mRHMlBTkjlfrs5zM_KuTd9MQUduk88mSBMFIwe3Ow$>