Re: [dmarc-ietf] nits in draft-ietf-dmarc-aggregate-reporting-02

"Brotman, Alex" <Alex_Brotman@comcast.com> Fri, 07 May 2021 15:10 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 728A63A25D9 for <dmarc@ietfa.amsl.com>; Fri, 7 May 2021 08:10:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.117
X-Spam-Level:
X-Spam-Status: No, score=-2.117 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 NMJwg8tILQvq for <dmarc@ietfa.amsl.com>; Fri, 7 May 2021 08:10:30 -0700 (PDT)
Received: from mx0b-00143702.pphosted.com (mx0b-00143702.pphosted.com [148.163.141.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 0E2243A25F0 for <dmarc@ietf.org>; Fri, 7 May 2021 08:10:29 -0700 (PDT)
Received: from pps.filterd (m0184889.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 147F29g3018528; Fri, 7 May 2021 11:10:28 -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 : mime-version; s=20190412; bh=Vm0TLJSPxOpNFc9xMy+WPlRfg7rfAxEYGC537S+j3ik=; b=sSERtgESX084Czu51haXQ/GCObP2YdZ5qi8EqrPMV8r9wjqEiZqnQi2i0+vF8qIjXjsc lNv2kB8emwzD+n5rVDh0peCIXqSXlMsfMXxdVxZ/KnrlDYlj7DuKtHe/Y7ADarzPY5jl JL+6M3QTW+ySFSaxt8O8Ug42n+1YP7UaEbNO9QD2NLBggvYqSQqBIFFiIeHbYCz8WdAz uHZAUdYpHf5xzewxHelpHHH1zTD9nZj9v7QG6kzNqtk2x81iyP+2fY2zTsW93VF8WbwJ Qa0iAJSy2cCd6385jHqsp3rW/2UMMD3h8rt4mgrLdQ+gDXMXV97oW1cXHCHhP570rfBv hw==
Received: from pacdcex54.cable.comcast.com (dlppfpt-wc-1p.slb.comcast.com [96.99.226.136]) by mx0b-00143702.pphosted.com with ESMTP id 38cspvvhmy-8 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 07 May 2021 11:10:28 -0400
Received: from PACDCEX49.cable.comcast.com (24.40.2.148) by PACDCEX54.cable.comcast.com (24.40.2.153) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 7 May 2021 11:10:07 -0400
Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX49.cable.comcast.com (24.40.2.148) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 7 May 2021 11:10:07 -0400
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.106) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 7 May 2021 11:10:03 -0400
Received: from MN2PR11MB4351.namprd11.prod.outlook.com (2603:10b6:208:193::31) by BL1PR11MB5525.namprd11.prod.outlook.com (2603:10b6:208:31f::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.25; Fri, 7 May 2021 15:10:02 +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.4108.029; Fri, 7 May 2021 15:10:02 +0000
From: "Brotman, Alex" <Alex_Brotman@comcast.com>
To: Martin Kealey <martin@kurahaupo.gen.nz>, "dmarc@ietf.org" <dmarc@ietf.org>
Thread-Topic: [dmarc-ietf] nits in draft-ietf-dmarc-aggregate-reporting-02
Thread-Index: AQHXQy0+YQfvfz0W7USCDXekzw2TmarYGqUQ
Date: Fri, 7 May 2021 15:10:02 +0000
Message-ID: <MN2PR11MB4351736953B3058184CC7991F7579@MN2PR11MB4351.namprd11.prod.outlook.com>
References: <CAN_U6MUNfaaUPQ=u3NTkoSFSuMMxZ_2wKeUkid_vVu0sYZ+3LQ@mail.gmail.com>
In-Reply-To: <CAN_U6MUNfaaUPQ=u3NTkoSFSuMMxZ_2wKeUkid_vVu0sYZ+3LQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: kurahaupo.gen.nz; dkim=none (message not signed) header.d=none;kurahaupo.gen.nz; dmarc=none action=none header.from=comcast.com;
x-originating-ip: [2601:43:103:e60:30bf:55c0:b91:35d1]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f8947eb9-8d74-4b4c-6a49-08d9116a3073
x-ms-traffictypediagnostic: BL1PR11MB5525:
x-microsoft-antispam-prvs: <BL1PR11MB5525980065C89B9886D03089F7579@BL1PR11MB5525.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: 5rekThDOXHF/eJj1N4qVEow/DCFbwbFB/5vLplvSrLF7FoyerFT/qFoO2xA36vI4Wi0UKvZEByrK4H8Ux5QBS611rUCWu/ggBBpz5rGjgtEXmML480//8wjGGVmxMp/KbkYlkjoQb8dVVKXCP1uE3FJ4VFuSRRlXO4VMqhRnNqZhr02O1ip5S4lKyHBPaeroCzfExvdI/EYhyPtdw1Mka18fNvjnXQbVJGeL+XUFcPK8411Zi2cPXgS2dvtsZFbaFXXH7EEJ8RDe1oBjMn2YtyHqCWaDBxlI6MzjJvYkirMt915FayZB6aTcnBRpUErXolvLGeux4Mw5b3vnAq1Hg+ji1LtsiePc1tLzYCLzmckmoG8E6fWlh7OAFenXV0i5eT4eW6NM7NFYlIoaIhc3ok3QQttExnjADTTADLkZGDgfJeLHb/Uh8qejF31BNaPGwYKRIF7CuLw7vZ70EssGASGnfWUsmzo/at7cYzF9Xh5L5fUmif7dxamKr3U+KQqsl6KsAxlE+xXQWLCaoFfjzpBlRRwQvD6lsLx+QdqqC44JfwwD3mLMDuxLp5BlbW/cA1ZMtlDHdlwCPPXFslL1yvhp0CEHZTmt9T7qjQ+VpDN1oFEzAhkYmIlt6Qx8C8FZ2jiYDFYSgMU6zISdO6RJVbal0RJ+qVYqrgjFxvT0kHIqzv6XAe18j0nUn5UkenZv
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)(39860400002)(366004)(396003)(346002)(136003)(376002)(84050400001)(83380400001)(66946007)(86362001)(38100700002)(71200400001)(76116006)(122000001)(186003)(166002)(8676002)(8936002)(110136005)(52536014)(66476007)(478600001)(64756008)(2906002)(66556008)(66446008)(7696005)(33656002)(5660300002)(316002)(9686003)(53546011)(6506007)(55016002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?dGxqOHFoa2p5T2lYRWtEODJmKzUvVTdZd3VUM3d2RHZ1ZFp3MmttTkdsZE83?= =?utf-8?B?Umo0R08walQrZHNkVGxmRXozOVllZ0ZxcHI1NTduOEtjK1VIbTN3MkM5cjll?= =?utf-8?B?SU05Njc1Z1cvRklWaS8rRTkvZm5oZVR2QUYyZWNJeVBiVW9JMm9abTJiN1pw?= =?utf-8?B?WDhNa1dkOXphY0kyUWUvVXd3RFdxa3B2OFAzQ2d2QU54REEvaG1DQ1hkTm4y?= =?utf-8?B?VVNNbGJWdHFPOVdJYTVKa3BDVFF6Ym13dFpvem5ieTJUOGgvVGJFNjdxK2t0?= =?utf-8?B?SWJ5Z3QxVFhsZmZkN0ZLMWF4YVZiZWU0ZnlGZHJOeU8zM2dzaUdsVWx6Zm1p?= =?utf-8?B?bWNlQ2xCeE96MmViTzBQblkwZ0s4U3F5RmMwcWdyUlRkR3d3eHBCQ0lDakNO?= =?utf-8?B?Vkpqc09mbHNhb0ZZZnhqcGhKZmxNZG9iV2lnemUxR3NiRENEeDl0cFBhWUxI?= =?utf-8?B?djBhM3QwMUcrQS9ZTFBONXBJeXVCcEVVV3hPbTlWNkg5Kzh5eXYyclUyd3R4?= =?utf-8?B?OEhTYjRqSENWanI4Q3A4OERYZzYvY1E5QzNITVRiSXBPT0RzdVlhQ2dwbHJk?= =?utf-8?B?Kyt6MC9xTGlLZEtqWVNLOGNCV3ptMk40WVRzSG9PVXFUOVU3NWJrZWFGZlNI?= =?utf-8?B?RVVHbm1uTXh5cFV1K0JhRHljUzB2NThQdVFySS9UY3AvWk5LVlEzUUNkT0do?= =?utf-8?B?K3E5NHgvbFJ6RFFSMlNlMzc0TGVOS2FzbWllMU5CMWd5ZTNKM000REcxNTky?= =?utf-8?B?cmJMOHE0Z2xVUEp2UFhEOXNzY3BBRC9KNlJxejJ3bVU4TlFYa0RDcTF4eHpE?= =?utf-8?B?S3JwNWZWdHhtVnJ4ZGRwZGI5UG5oRThZTFd1YTM2ajBINFJqREUxNFkwQjRm?= =?utf-8?B?MmN5amJQOXhNRlV1L0VuVE5seWMwZTlJUXBNY3prbUVYU3gvSTN5WWZPUUxF?= =?utf-8?B?SmM1N2wwSk5KS25QQjVSOXRMcG9GalRkdFkraXVEczBybXNNUVJXMDdtTkVl?= =?utf-8?B?eEhsNWN1S2NFNXQvUndHOWV3TC9PUkpkc29zVlhab29xeXIzMlJkc1k4VnIy?= =?utf-8?B?c0Z5UmtUdlo2S3N0SVJ6TUpUeVBQNGU4QUZHd3FZV0k1WXZsbVg2UStCcS8r?= =?utf-8?B?dnlhUjhXMjlZTVBmWTNMMGhFN29WL25odFAyRG5YSFlWMGRIbnFjaFhjVWcz?= =?utf-8?B?WWpqSFVWN0lNMXVmZlc1SDVrR3o3Ui9meTE4KzBXdnpTY1lYZ2syUTQyK0NK?= =?utf-8?B?S09TdWZFOFhSZWJNU09jckJsQVNMdU4vb1k1QkJZc0pJL0FXa1lhZk9lUlB0?= =?utf-8?B?bUZpQ0tacDVONkU2YkFvME1wQjBVblZHajdjODR5ZWwzandiM2hwV0lFSkIz?= =?utf-8?B?ZGplUXIxWVUvWU56dTZDNm8vWnIxRFF5WHhrTWYvd3NrOExYV3h3bmFhR1VH?= =?utf-8?B?RURvWDltWEJud010Rkh1RVdIU0wrMjJVWWNxbi8zQmhlYUd0R0o4Z1NPdkt4?= =?utf-8?B?OWErTmdpT1ZOcHhLcGxNNWlhVmVKSmU4dW5ENklBcDJjZ1l1VDY5bjRYM2VN?= =?utf-8?B?MGRqL01ocUpJZjgyOGM2eVVaRWhGVmlPVEJFWTZXUSt1SENCbmlKNlN6VFhq?= =?utf-8?B?ZTkxSHd1VFlHTVVpNnR1M0ZZemg4MnY3WXlWTWhjdlcyZ25IbWlRb3lXaXJX?= =?utf-8?B?Ylo5OUhaejA0cFRsR203YXFkSm5UdGJ1UmxWMFgvWlhCREpSTG12akVidklu?= =?utf-8?B?d0JFUGFyUThYaDdDRGNHeXN4OGh0NE5QbWs1RUJmUjgyUzVuVWhoNDZ2LzBx?= =?utf-8?Q?AsyRdpypc0u88U2z/P/ZXcQN2Co5xCWLywoyk=3D?=
x-ms-exchange-transport-forked: True
arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bNIRks2FEJrtwH4m88X6nvC6rPI9H3MmsjrWnZlqMOiA/4WOHQVEfPvPnKX7kWFTzxuG+lQlnUkZ71hd6OqhQ0VdWgg8qok2ynEbCBT25TrjEkVV/9l7F6N8q+56pS4REZ6w6vxwi+DM8eJss25A71Y1/6QbRhDD4DDTKs0NaLbdoxE64kRaJT3m+Kt7U61tigKNNs2e8xJwLbHfHFJTHeZOOZ2nrebh20OIBTqj4MznUlV59gX+JM1Pc6/sBV/+LJlDYne9TfC1Skmp7dPxah6A0GtcFeOl0AzIeZxwEfHvVWTJdFbSkak/A3Q9Vy6E/UDkE56FXGmhT+J9kuAH0Q==
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=/WHtktLz5Yzb06sty3vpVggqQg8HKxw+0cGsh348/uM=; b=EVs9KB2eVbiEh452KTihoIJlCPPUK2NffPaOvYDPJd1t8ICKJv1kOfpcsp5BLgGW6kSplFs447lBiQVnwT1mDMLNfpsK5lz02EPQdzwHcH/JKumQJyw9z/y39iZXoP2zBcehgzeR6nzj9mu9gY1z2nEdY4OBW7KyiQj/s7f3ynkER9g3rbMHwlBGAibfunXnC2cv7nPcd2LCJl1leTYIEtbVXtvhPbyoeQOoPWviA0B2N5VYdXUhW03H7y/WiTs8IA3E8tfZLSsY61EO0zHINZlZoODJUG52DOhxGuwpWDEjkcu3KPf6eyh4V5jg85HMdcB47twD/5fIIjIyDP8OaA==
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: f8947eb9-8d74-4b4c-6a49-08d9116a3073
x-ms-exchange-crosstenant-originalarrivaltime: 07 May 2021 15:10:02.4313 (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: U28Ci1lvQ3wMb31LBWGf9AoRgltuxjjSqOK6AP0P78mX1fQmEfHAfthOyzEKbOI1pLEFvwqrXkrVmC35PsobIjvVXHtU8LZOzeUkh0CvDIo=
x-ms-exchange-transport-crosstenantheadersstamped: BL1PR11MB5525
x-originatororg: comcast.com
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4351736953B3058184CC7991F7579MN2PR11MB4351namp_"
MIME-Version: 1.0
X-CFilter-Loop: Forward AAETWB
X-Proofpoint-GUID: jdmNhU85ZSm5zj6YQ4bQeql33s7lZyHR
X-Proofpoint-ORIG-GUID: jdmNhU85ZSm5zj6YQ4bQeql33s7lZyHR
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-07_06:2021-05-06, 2021-05-07 signatures=0
X-Proofpoint-Spam-Reason: safe
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/nWaDMDH_QdiiQoofClvl8fGq6GE>
Subject: Re: [dmarc-ietf] nits in draft-ietf-dmarc-aggregate-reporting-02
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, 07 May 2021 15:10:39 -0000

Martin,


  1.  I’ll see if we can get this cleaned up (I’ll create a proper ticket for tracking this)
  2.  I’d welcome other inputs here on the original idea for this option.  I would imagine modern systems would be able to deal with rather large XML files, though MTAs routinely set limits under 50M for accepting messages.
  3.  I don’t think it suggests we should all send at the same time (Unless I’m reading a different section). It suggests that the report producer should create reports on the same UTC boundaries.  For example, we do abide by the day boundary, but our reports are generated a few hours after 0000UTC (and delivered upon completion).  If you’d like, I can put a clarifying note into the document.

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

From: dmarc <dmarc-bounces@ietf.org> On Behalf Of Martin Kealey
Sent: Friday, May 7, 2021 1:24 AM
To: dmarc@ietf.org
Subject: [dmarc-ietf] nits in draft-ietf-dmarc-aggregate-reporting-02

I'm not quite sure how I'm supposed to submit nitpickery like this, so if there's a better forum please let me know.

1. Filename & content-type

Section 2.6.1 among other things says that the name for the mime-part containing the report MUST end with ".xml" or ".xml.gz", yet the example given ends with neither of those (it ends with just ".gz").

The main use for this is as a unique report identifier; its use as a filename is entirely secondary and only relevant to manual processing by a human, so MUST seems quite excessive.

It seems like there are separate drivers for each part of the filename suffix, and perhaps they should be two independent SHOULD requirements. If we want to facilitate its use as a filename, perhaps we should just say that the filename SHOULD be universally unique and MUST NOT contain "/" or start with ".".

It seems strange to vary the content-type based solely on what amounts to a transport optimization, namely gzip; this smells of working around deficiencies in other standards. (From the perspective of an application using email as a transport, it would seem to make more sense to allow "content-transfer-encoding" to be a chain such as "base64+gzip", or alternatively, for "content-type" to accept the addition of a "gzip/" prefix, forming "gzip/text/xml". However I digress, as that's a discussion for an entirely different standards track.)

According to rfc 7303 §9.2<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7303*section-9.2__;Iw!!CQl3mcHX2A!RFC9J_lhPahv_fk_lJ87nHfTTbdL4ck7ruqYS3RZJXmOfkOe73AOD1_nSftMp7jrqYjm$>, the "text/xml" content-type is merely an alias for "application/xml". Other standards such as related documents by w3c<https://urldefense.com/v3/__https:/www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html*textxml__;Iw!!CQl3mcHX2A!RFC9J_lhPahv_fk_lJ87nHfTTbdL4ck7ruqYS3RZJXmOfkOe73AOD1_nSftMp3d4W5dH$> go further in actively declaring it deprecated.

It seems to me that rfc7303 §4.2<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7303*section-4.2__;Iw!!CQl3mcHX2A!RFC9J_lhPahv_fk_lJ87nHfTTbdL4ck7ruqYS3RZJXmOfkOe73AOD1_nSftMp6dQnJve$> and rfc6838 §4.2.5<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc6838*section-4.2.5__;Iw!!CQl3mcHX2A!RFC9J_lhPahv_fk_lJ87nHfTTbdL4ck7ruqYS3RZJXmOfkOe73AOD1_nSftMpzTRLTLD$> taken together indicate that registration of a content type such as application/dmarc-feedback+xml would be appropriate.

2. Size limit

I'm concerned that specifying the maximum report size after compression is possibly focussing on the wrong costs, and distorts the conceptual model:

  1.  It implies that the compressed file is the relevant artefact being transported, which leads to the weirdness with filenames and content-types mentioned above.
  2.  The size of the report is trivial compared with the size of the messages it's reporting on, both in terms of storage and bandwidth, and gzip decompression is very cheap, so compression makes negligible difference to those costs.
  3.  The cost of processing the received report to incorporate it into the bulk reporting correlates more closely with its "uncompressed" size. In particular, the memory footprint of the receiver process is likely to be correlated with this limit, especially if its first step is to build an in-memory DOM from the XML. (I would be surprised if any real report-accepting system didn't work this way.)

3. Scheduling

Concern about processing load also brings me to section 2.4.2, which essentially directs everyone to send their reports simultaneously. Since the receiver needs to be able handle reports with any reporting period, it seems likely that having most but not all reports arriving at the same time would be the worst outcome, needing both (a) complex coding to cope with asynchronous reporting, and (b) having to cope with high load spikes (or suffer delays with the reports spooled for batch processing).

It also imposes a load spike on the report generators, to generate all their reports at once (or spool and delay), but at least they can derive some benefit from not having overlapping reporting periods.

In the scheme of things this isn't a huge load compared with the actual processing of email, it seems like it would be preferable to allow the receiver to specify their preference in this regard, at least to choose between "UTC synchronized" and "randomized". Or for this document to specify "randomized" as the default.

-Martin