Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

Ken O'Driscoll <ken@wemonitoremail.com> Fri, 04 December 2020 19:23 UTC

Return-Path: <ken@wemonitoremail.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 EBF7C3A0EDE for <dmarc@ietfa.amsl.com>; Fri, 4 Dec 2020 11:23:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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_H2=-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=wemonitoremail.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 3ZniO4jhkFvN for <dmarc@ietfa.amsl.com>; Fri, 4 Dec 2020 11:23:40 -0800 (PST)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20115.outbound.protection.outlook.com [40.107.2.115]) (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 AFE603A0EDB for <dmarc@ietf.org>; Fri, 4 Dec 2020 11:23:39 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Jv47qKn/kgPcYOus83P3QPL/bAHYN2dmnGcTogyfz7TdW+vbPzf2eZKKgHOACGh6OAP/5J4cew+UjzYMtr1VlTihZvMY6KKQAIOpqUFdMZXsQ8yDdEf/i3Z2lVbbWrems+b0rcx1UhWoAZgykUijIdX+n0+VUEUMCTCRAHEoqt1ahEdLSyl+G8080KIIIpnRJvVx4+zGjRwRYtokTuGbAnoYkJMOKe0wKR/a4d2ksAKvaiRZuwyQCOQpW2naIgkPVPTm6pHQUes8Noes/cbockWETjW9fYSqQQDz6yrCxDurIatgPueYLQ5GEwFd2XuRF/9WVKm0juON6h6Jkby/OQ==
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=je58wtNJCA+wF4+xrugbH+EK3dHd10SJ6jpoM3yQTFI=; b=eGT7YaMdevUGY/Jq2a4FKInx/16b/E2sIXmQgxG/xBRAkY1pqfZ76oASop4Fjqh75y++L6eWkRIPGcBtyOHIqZ/EpHLJuKp1TMHkvYWfKp7r72wK9b0MMYekzPEfeVOFV3cfJ8r6768u7KZ/eN9gjMqptD8dHa5bDKtgNWSut81KSjXOSAUz+RzsFt8S+w/SzTdaG9e8aUl5XQvDGJI+Lg9ph63IzvHZkn9c3T9qdfN5pN0YqwVID0KQWcrPbV3X5GRu+/Mfy1bZofzBGbG3dNbo5HC83NpwB0BjtZ9JIKq56w2JX7tdzC95PvNRzZ/VvmNrk4x9O+gPPUVpaRkYEg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wemonitoremail.com; dmarc=pass action=none header.from=wemonitoremail.com; dkim=pass header.d=wemonitoremail.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemonitoremail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=je58wtNJCA+wF4+xrugbH+EK3dHd10SJ6jpoM3yQTFI=; b=pNsee24vy6En5rF5Rs5oP648EQTwnbFgPJ2CDLNRCzFDVaKQPCjUdxRTTswzJvsTjmprswy0gOIXnXtTr1bPjdkrEurJ/XngmjbjMea+OM2eIUtLyeFeT+bGITIQYtkurW+WojOSObdYOATUfIl2eL4OgC3w9lp/OAAlx8yLhjZprCY2cdo/bjLhMP77NEYxV4ITxCUzqrq8npbZqmG7VtlLQfr9d99IDtCB/RJpax9e/UzsCZeDAVwbqnS5q9avQmcPSQukL5xdcUpQE4zv76Kp/ycAAPGotx4/6A4ixMczHoUvbSG4RUrE+VJfjN4mDlrLe3+LipWT11eCx2HeTw==
Received: from VI1PR01MB7053.eurprd01.prod.exchangelabs.com (2603:10a6:800:19a::9) by VI1PR01MB6559.eurprd01.prod.exchangelabs.com (2603:10a6:800:180::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.18; Fri, 4 Dec 2020 19:23:34 +0000
Received: from VI1PR01MB7053.eurprd01.prod.exchangelabs.com ([fe80::4839:b26:a604:336d]) by VI1PR01MB7053.eurprd01.prod.exchangelabs.com ([fe80::4839:b26:a604:336d%5]) with mapi id 15.20.3632.017; Fri, 4 Dec 2020 19:23:34 +0000
From: Ken O'Driscoll <ken@wemonitoremail.com>
To: "dmarc@ietf.org" <dmarc@ietf.org>
Thread-Topic: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality
Thread-Index: AQHWyDBplg5u91qkckS1PWHOZHF+jKnjmUSAgADdugCAANtLgIAAS0YAgAAniQCAAAaggIAA0N0AgACnoICAAATa4A==
Date: Fri, 4 Dec 2020 19:23:34 +0000
Message-ID: <VI1PR01MB7053612B81C981C468606901C7F10@VI1PR01MB7053.eurprd01.prod.exchangelabs.com>
References: <20201202233432.D45FB28E1943@ary.qy> <f719b86d-9a7d-f865-3e16-10eaf35e0de0@tana.it> <479cfb50-b98e-fbbe-e7ce-375557cd624@taugh.com> <f406f70b-3f98-a8fd-db9d-956c000f5c68@tana.it> <a4c256c2-d0a3-1fc1-b585-7b8659cd6a4@taugh.com> <0a650f5d-c53d-ab45-4125-6491c413f70b@tana.it> <a7bd1f7-66e0-1051-5cb5-e4efcb13cdb0@taugh.com>
In-Reply-To: <a7bd1f7-66e0-1051-5cb5-e4efcb13cdb0@taugh.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=wemonitoremail.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a65cc92a-948c-4743-209b-08d8988a17f4
x-ms-traffictypediagnostic: VI1PR01MB6559:
x-microsoft-antispam-prvs: <VI1PR01MB6559259595AE11114964801EC7F10@VI1PR01MB6559.eurprd01.prod.exchangelabs.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: xHUG3DbJ79b4N8W8VAx0FgeWa8bmyxmW7pJK9xlTWXzZAgqYHtdRML0j+/V2iaGhYOHMSq6qk2YPKtT32lL2F1Qhcwe+By2lJMy2QOZaWylGazu2XYCGnsbQ8uTWB35EIDD3YjWlCNVujg4DiebGfLfHhcHvdkkkjSDB1zckew5J/JR+mK0TuszGXgZ2iVTiK6+1KdmJksuPaLtQ2OMm+UiLE6792abYTp9mieR225HEw1dAG30ToqDAU/fp1X+wsgBhOAGuSzp1cA4RNhPy6BOEx7b9aO63x3oXOlFi7YC9QQ6nSsvWOxuEUzeiX7ZA4WXWvBaNi3ymmrs3bGl9mA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR01MB7053.eurprd01.prod.exchangelabs.com; PTR:; CAT:NONE; SFS:(366004)(39830400003)(376002)(396003)(136003)(346002)(9686003)(2906002)(316002)(8676002)(55016002)(7696005)(478600001)(71200400001)(53546011)(83380400001)(8936002)(33656002)(6916009)(66556008)(52536014)(5660300002)(76116006)(66476007)(6506007)(66946007)(64756008)(66446008)(26005)(86362001)(186003); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?NDMxaTB0ZDU4YzVuNGVjd2hqS1lrVzFwanhVNHQ5YTdZQkxJSkkxVFJKbzdV?= =?utf-8?B?U1VPcVEwakZJcGoyQkd0ZEZ2VjBmRXFvd3Y2OGZyOWovbFpGaGdSRDRwR0Ex?= =?utf-8?B?Y3JzVXZ2VmJWU0JWc1YrQ01vQ042K01sZnZYclZJVTE4UDlBd1pEeGxOUEhH?= =?utf-8?B?Q3VsRzBOMm16RG5hYWcrc2dMNDhsWmJERHBRUExXOHBZNlpOd1VxT1o2WXRT?= =?utf-8?B?L1lTYXh4M2lQdVpTVTU1OW5PNmVKMW4wR3gxUkZIUnJJOTR3QXEyUytKMXJR?= =?utf-8?B?bG5NYXZXM0RIWDlQbEh0TVFqS0hCWEEzVStjR0NoVTJPalQ2WjJwVUJHNVRS?= =?utf-8?B?cVByYkNERTV6alNTK2ZoWGdOT1hLclhHSUxZd09NbnNUMERjeHNkUjkxRytL?= =?utf-8?B?TUM4MTlJZXVCR285S2tlSTcySGZiaTBzK1p6UzhZdk5JWi80N3ByOE0xSEwz?= =?utf-8?B?UTE1Ynh2bHJIMzFyd2J1Sjc3R01ZY2V1K3JyR1U4T2RWeVgyODBHbHhDZkhK?= =?utf-8?B?N21QQ2V5SDJyVjRYSElJdThaVEFHcGxuQ20wRSt1ZmJJdWhGU2VFQ1RUT3JK?= =?utf-8?B?YTRSWVZOYXp6NEZaZERrZDhYTHN3Q1FOV0ZxcVBQc0ttL0VuNEhzQVNVSW9s?= =?utf-8?B?dnhYTTROOGNoSHg1MUlXVzRnNVJkYUo2R1JkRDJjYUl2UFBVUzVaQ3ZnY09S?= =?utf-8?B?QWRZOVUwaE8rLzBBcnRhdHJsdnZ0MDRsTERMTWRpN3hjZEJralNneVU2S0dH?= =?utf-8?B?cGtOY3JCSCs1cWlZcWp5c3AyL0lZRE5TSW93T0FmVDRBaFBTbTRvaEt0eUti?= =?utf-8?B?clNZNytxN1JUaWtuVTUySGxEMFJzQ0tSVFFwendaRkNhQWVoVTViendsRUlq?= =?utf-8?B?RGVsYTMrOWcrRnlLWldMb0JyelRhVlJtN2M1RzlXR1J0Vm9mNWZWbHgvdC9D?= =?utf-8?B?VmtPNWNFTU1HZzFFVEE0WU5Md3dDdThUUWsrS0VZNXhSKzE2bXF6SDhMb0s5?= =?utf-8?B?S0I3dG1CbU1haXNrZUdjaVZxemZWVmxrVHBCdlNnVW5TZzg0OE0xWXo3MXUw?= =?utf-8?B?YjMzUkkwaW93MkpIOFpnaGtUS2YwQi9PNlZ5WkEvSEo4alZ3RStvVXFLckp6?= =?utf-8?B?WnhHOUxLcmwwYkgvNFpyL3BBTko0KzF5WUMxK1ZwSWtMc0dKOG5pVVc0WHdF?= =?utf-8?B?aG9jZGhaQVpjWUxTUjRtTkM4T1dSc0xJK2dyK0c0L3pYYmpHeTc4Tm1kODFv?= =?utf-8?B?K0hlandFUjdyS0ZNVDl4c3I1YVE0R2c4M05zM2NsRUpJeDM1WjJXUXd2K0Nz?= =?utf-8?Q?896tZM3aQI9zc=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: wemonitoremail.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: VI1PR01MB7053.eurprd01.prod.exchangelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a65cc92a-948c-4743-209b-08d8988a17f4
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2020 19:23:34.7300 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a2b1d6fe-fc8b-4b7c-b9f1-d7b1ab3d23b3
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: j9d87vmia/kO0CfZrjkhF4qY89AM0wLE/RbQ6/3xOr7rgVNRzth+1oBfOg5kTLtv0jMtqjN287LJv89xPOmNUw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR01MB6559
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/ja8aziKyrTXgLuj4zgH4ii6NHig>
Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality
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, 04 Dec 2020 19:23:42 -0000

> -----Original Message-----
> From: dmarc <dmarc-bounces@ietf.org> On Behalf Of John R Levine
> Sent: Friday 4 December 2020 18:22
> To: Alessandro Vesely <vesely@tana.it>it>; John R Levine <johnl@taugh.com>om>;
> dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI
> functionality
> 
> >> I meant "at the same time" as in during the same reporting run.  As
> >> Dave noted, if you sent any particular report by https, there's no
> >> need to send it again by mail.
> >
> > Got it.  However, the spec says it's a list of addresses to which
> > aggregate feedback is to be sent.  When there are multiple entries, up
> > to now, reports are sent to each.
> 
> Hm, we might want to revisit that.  If a domain wants mail sent to three
> places, it's not like it's hard to arrange for forwarding.  My intention
> is that if you send the report by https, you're done.

In many circumstances, mail forwarding may be quite difficult to arrange.

Many organisations use an external service to handle their reports. Currently, if such an organisation wishes to add another report receiver, they are in control of that process by modifying their DNS zone.

However, if they can only specify one report receiver then it is that report receiver who must handle any forwarding in the case of multiple parties.

The pre and post acceptance filtering that most mailbox providers implement can make them unreliable for delivering DMARC reports to user mailboxes. So, an organisation would likely have to set up a separate mail infrastructure should they wish to retain control of what parties receive their DMARC reports.

Of course, third party report processing services could also add support for such forwarding. But, given that such a feature could facilitate a competitor, I'm sceptical it would make business sense to many of them. On top of that, it's easier to receive than send so there is an ongoing cost in providing email forwarding.

As to the utility of having more than one report destination, I regularly receive client DMARC reports on top of their existing service as part of consultancy engagements. It is also the only way for an organisation without their own email infrastructure to simultaneously evaluate more than one report processing service. So I believe there is utility there.

Ken.