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

John Levine <> Fri, 07 May 2021 15:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 944823A25A9 for <>; Fri, 7 May 2021 08:10:16 -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=jkWpRAVd; dkim=pass (2048-bit key) header.b=h1zPnbt0
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 00ODmhSB1wjh for <>; Fri, 7 May 2021 08:10:11 -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 2BD8A3A259B for <>; Fri, 7 May 2021 08:10:10 -0700 (PDT)
Received: (qmail 96725 invoked from network); 7 May 2021 15:10:08 -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=179d3.60955850.k2105; bh=vRyXlX3Lalc9EaumTttkR2YFOMxag/a48wvHwECZwqg=; b=jkWpRAVdTbOshwbSEqJWG2eHBtmEI4KfmBcvTq1M/IJdgKCAuTDoN4/Huk8iYe/xOlFiGVh2h0BDhwtEiVLGPovH3fwCXRncX1PZYzgpQF20COax4n8GMmc/RA/Qh8L5bftAft8KBGl8etN6/ng3MLjmbGrxV03OUuVaiLZRpH8Ec1bI4a07QCM41CrpugJSfuvYrSB5iGDFVdKTVdtYU8ur8DVbkRQFKx/vm0k6Z/UowidTcT29sEPtU+vsNTkNNlcg8QDOUx2ikhYZQ4H1hE+MlXv5WVG4FiReWGnhQFjxJkxSM/pMg9TFMfp2tKbHPzzkATNvW2bK11lHioZXpA==
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=179d3.60955850.k2105; bh=vRyXlX3Lalc9EaumTttkR2YFOMxag/a48wvHwECZwqg=; b=h1zPnbt0rJOwTnwsosXT1ifGJqpFFn8Uo2UkY5ifkko9LZ3ncIDjK2D94d5qIggvf+UBnVTQnKq15XVTjYJ1sqYB2/WFpBPKS0lYm9c32OhDQMU5lyEOB2PU12zOsj2hvbperm9KpeknJnwqhnq6oYU2C9GVBlURYPy5cemeGiiCVlkyAK5xcnzKzHD0iF1QbJLyHO/QZWTXp5lvsAcYwxqsgt9GATak00Q3Qg7eyErUC6X8TIgEvXW7zbA1Wxk+4/3+SLD3dyNEjc9EelGTyH5HpYCTdlIPuVPqd2gWj5RABoMi5HDulmU3fkC00fzWFntWfzo+Zad3XXyUt26sTA==
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 15:10:08 -0000
Received: by ary.qy (Postfix, from userid 501) id 7FB68720351; Fri, 7 May 2021 11:10:06 -0400 (EDT)
Date: 7 May 2021 11:10:06 -0400
Message-Id: <20210507151007.7FB68720351@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 15:10:17 -0000

It appears that Martin Kealey  <> said:
>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 example is wrong.  It should obviously be .xml.gz

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

It does, but that's how we've been doing compressed MIME forever.

Early on, the DMARC drafts said to commpress with ZIP and send files
ending in .zip as application/zip. A lot of reporters still do that so
the draft needs to say to accept those even though nobody, not even
Google, should be generating them any more.

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

The problem is that many mail systems have a maximum message size
they will accept.  It's true that the expanded XML can be pretty big but
on modern computers, a few gigabytes of RAM are not a big deal.

>3. Scheduling
>Concern about processing load also brings me to section 2.4.2, which
>essentially directs everyone to send their reports simultaneously. ...

It does, but as far as I know it is not a problem in practice.

I could see getting rid of the 0000 UTC advice since I don't see that
it solves any real problem.