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

John Levine <johnl@taugh.com> Wed, 02 December 2020 23:34 UTC

Return-Path: <johnl@iecc.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 795C13A1601 for <dmarc@ietfa.amsl.com>; Wed, 2 Dec 2020 15:34:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.851
X-Spam-Level:
X-Spam-Status: No, score=-1.851 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, 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=iecc.com header.b=KBzY7MA5; dkim=pass (2048-bit key) header.d=taugh.com header.b=YP3CpJzG
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 IHZb-8MskpCS for <dmarc@ietfa.amsl.com>; Wed, 2 Dec 2020 15:34:35 -0800 (PST)
Received: from gal.iecc.com (gal.iecc.com [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 ietfa.amsl.com (Postfix) with ESMTPS id 8A8813A1600 for <dmarc@ietf.org>; Wed, 2 Dec 2020 15:34:35 -0800 (PST)
Received: (qmail 71661 invoked from network); 2 Dec 2020 23:34:33 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=117e8.5fc82489.k2012; bh=//A8FUy2MU9YqMp+GWUFQmYK8NbEK34W38Nsczhriw8=; b=KBzY7MA5OyQUsq4rYxei4qvuZbUbfGKhYufn1r1W2RsAlylt2zY6nngUTVkEf7eR8t44JU34wKceKqPlYeIZNg6lhf/lJ8RRGfjjqKyzAFUmjgytHYYtwIxoMn3qE7UKLYYzcZTrevUAi2VwOSOyRcPSm/G2o54YzQvKyQjZ5kSZsqxW/clSjIRcWsC+vYsHqf0goCVm4Ta65og6+lbUwv8juP1FMYAN8PT3FRHztI6M9/sajZpkyf4fssViY1PrfZ8mzeDO9S7tiyiCoxIVOMym55pYylXTbXhs69lLs7p1WT4cwk15GJ3K/mNL2GMJx99HJ/kPLeiKL/+LMK1Ohg==
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=117e8.5fc82489.k2012; bh=//A8FUy2MU9YqMp+GWUFQmYK8NbEK34W38Nsczhriw8=; b=YP3CpJzGfvwxVXoadvaiKzor14i9/sjEu5RyTfm2sKusU22JePv6ReiWCC1n7CDJLreKIZD0V0cvtSuMMwt/vg6q8Uyp8fqqruU+jzSQKdEFIXb4XA/vomGv/oWRolW4AqoYWhZvZ+X7f9cJfJhQhlaD0Pt8nvMsTS/4x4E3W/hfPCGjCyGCDo58mZKP9sdaQ7MBoIq/G3Lnyv6BIle8w6/rX+7MSl0VCI9VngvEddLUcvMeUpHBEJ3da7twdpW1psPnDNJ/izfnpI97zT/jkm7bdO6J16a84IJ6bcHRcXPE86pDPHVQ1khpWvU+jAmpHh7PWc1tWXNwtseMBqX90Q==
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 02 Dec 2020 23:34:33 -0000
Received: by ary.qy (Postfix, from userid 501) id D45FB28E1943; Wed, 2 Dec 2020 18:34:32 -0500 (EST)
Date: 2 Dec 2020 18:34:32 -0500
Message-Id: <20201202233432.D45FB28E1943@ary.qy>
From: "John Levine" <johnl@taugh.com>
To: dmarc@ietf.org
Cc: vesely@tana.it
In-Reply-To: <c8aff369-f540-a506-7351-3dff6384d426@tana.it>
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: <https://mailarchive.ietf.org/arch/msg/dmarc/QIIYoBSLpdK5t6RI0X2flMh-t2s>
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: Wed, 02 Dec 2020 23:34:38 -0000

In article <c8aff369-f540-a506-7351-3dff6384d426@tana.it> you write:
>On Tue 01/Dec/2020 23:21:48 +0100 John R Levine wrote:
>> We can adapt the approach MTA-STS uses in RFC 8460.
>> 
>> If rua= has an https URI, the reporter uses HTTP POST to that URI with
>> the report as an uncompressed or gzipped XML file as the POST body.
>
>TL;DR: neutral
>
>Delivery via https, with possible retry queue, imposes an additional burden to 
>report producers.  Since there seem to be less producers than consumers, it may 
>be fair to grant the choice of transport to the former.  That is, to make the 
>mailto scheme mandatory and https optional.
>
>Even if the the spec allows consumers to specify the transport they like 
>better, there will probably be producers which only honor one type.  So, 
>consumers may want to specify both schemes anyway.

That seems reasonable to make mailto: mandatory and https: optional if
you have an rua tag. I wouldn't expect reporters to provide queueing
if https fails, and mailto is certainly not going away. But if both
are available, http is a lot faster.

>A better means to control report size is to gauge the reporting interval.

When this came up before someone said that reports can be extremely
large, many megabytes.  An HTTP POST or PUT is a much better way to send that.

Here's another nit: POST doesn't pass the report's filename. There
should be a copy of the name in the header of the gzip data, but
semantically it would be better to do an https PUT to
<url>/<filename>. That also has the advantage of being idempotent so
if it puts the same file twice the server can tell it's a duplicate.

R's,
John