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

John Levine <> Fri, 07 May 2021 16:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C3763A2969 for <>; Fri, 7 May 2021 09:41:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.85
X-Spam-Status: No, score=-1.85 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=KXjgaqxy; dkim=pass (2048-bit key) header.b=Nz0K7O04
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8RgSFSEipHrv for <>; Fri, 7 May 2021 09:41:19 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F17FA3A2972 for <>; Fri, 7 May 2021 09:41:18 -0700 (PDT)
Received: (qmail 32074 invoked from network); 7 May 2021 16:41:16 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple;; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=7d46.60956dac.k2105; bh=MVxrZGzUi6fVV5AwYdnMByF7uNSgTEpLkxyxw6GFIKQ=; b=KXjgaqxysWNYdnoMoyN+4hTKqw3EM9FPwhtSajV+v4ZWpiyEC8Gn136qUgbyX609zsZaBodpg/95/vpORO0WowX9TIFFnXC5yN3useuC7LD3qHM5TLh7IKCa/QVrZE0FyOIhbqze7kNqZhZrd50c0G6+y4adfVfUbM3uxMw3UTgh5kHFxsefoHRiuzvdAV8qUt6cz+nEoM0w52ZJJU/vss6XbfYn3iZjV3L7RdhcO1COnYg179vKjRj6W5zGDgtVkm80JBrtC6dOApMnuRAIl0kqZ9tZhsyqj2azam3bMasdEbb5Igw5LkleMxavezOXOR2GZGrKUyULkRBaWpHLqQ==
DKIM-Signature: v=1; a=rsa-sha256; c=simple;; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=7d46.60956dac.k2105; bh=MVxrZGzUi6fVV5AwYdnMByF7uNSgTEpLkxyxw6GFIKQ=; b=Nz0K7O04IUL/afqPVyxIa9LqeCA87MC90c0OTfKHC03+oR9fRPVtFhY/VcCJ17PzhAS7owWKgi2dJ5RXFSoT0TpIZK+xP9WJifX9Z+RhFWqexN5RvQCDF4bz5HEDGKwtcUf0OhaA4NXolnq+tNQGIdqvC8Fthjd3hvdz1FvBGArWVpyqx0QmXRWlG7vIy7dwVuxfQWwAOQXyImVOSKxBlfD1Fjcv3wOQOon0X5IWaOZksXEN2w5jbzJHycEshLIiidgQ356Em3KIv8BJ1zuVd8b3NiRUk1qO3lb5mzyhE3SZPHzJ3uRsixPkdedQiYrPz8Ac2l4ynaa/FsN0Asvk0Q==
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 07 May 2021 16:41:15 -0000
Received: by ary.qy (Postfix, from userid 501) id 462AE720C41; Fri, 7 May 2021 12:41:13 -0400 (EDT)
Date: 7 May 2021 12:41:13 -0400
Message-Id: <20210507164115.462AE720C41@ary.qy>
From: "John Levine" <>
In-Reply-To: <>
Organization: Taughannock Networks
X-Headerized: yes
Cleverness: minimal
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: <>
Subject: Re: [dmarc-ietf] nits in draft-ietf-dmarc-aggregate-reporting-02
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 May 2021 16:41:35 -0000

It appears that Brotman, Alex <> said:
>  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.

I suggested an option to deliver reports by https POST or PUT, like MTA-STS does,
with precious little interest, even though it's a much more efficient way to ship
large files around since it doesn't need base64 encoding and doesn't relay.

This suggests that the size limits are not a problem, at least not one
people think is worth fixing.

>  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.

I read it the way he did.  I suppose a comment like "but wait a random number of hours after 0000 before you actually send
the report" would do the trick.