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

Alessandro Vesely <vesely@tana.it> Sun, 06 December 2020 11:32 UTC

Return-Path: <vesely@tana.it>
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 8546B3A0C83 for <dmarc@ietfa.amsl.com>; Sun, 6 Dec 2020 03:32:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
X-Spam-Status: No, score=-2.121 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 5orl7fq-f72x for <dmarc@ietfa.amsl.com>; Sun, 6 Dec 2020 03:32:02 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 58B3D3A0C81 for <dmarc@ietf.org>; Sun, 6 Dec 2020 03:32:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1607254318; bh=INIca+U4oeDrmKQEbdtVcE82NjHh56YEXum3EP3BOrI=; l=1818; h=To:References:From:Date:In-Reply-To; b=C7IRs7wKo3gXZb3fy3rQYpT5yMdkJGU/65m+r3iAoj71PsDV9L4sK83ZqDiM2aTj5 lGqID3+KFtvHG3eAS/5o/jnKBUDU2RyN+1CNvSj9e/s8qCiFRCSILRcfRtxfh60ZMH SB0cbT0W2uSKe4yS6XLmqUwCPXmQgiP4PQdHKyxaaY6ogCm6ixAEeW6YMKFHQ
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC07C.000000005FCCC12E.00003BAB; Sun, 06 Dec 2020 12:31:58 +0100
To: John Levine <johnl@taugh.com>, dmarc@ietf.org
References: <20201205210639.54261290454A@ary.qy>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <570ba614-a138-8a83-eae1-e6077b82937f@tana.it>
Date: Sun, 6 Dec 2020 12:31:57 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <20201205210639.54261290454A@ary.qy>
Content-Type: text/plain; charset=us-ascii
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/SgBUrWaFVveLZ7-uRLQnZxKkVMM>
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: Sun, 06 Dec 2020 11:32:05 -0000

On Sat 05/Dec/2020 22:06:38 +0100 John Levine wrote:
> In article <b8265b69-6e95-feb5-9486-82a8a88d3afc@tana.it> you write:
> 
>> The VALCHAR element in Section 3.2 of RFC 6376 accepts "/", which is seldom used in email addresses and
>> ubiquitous in https URIs.  We could convene that when a mailto is to be considered as an alternative ...
> 
> If we want to do something like that, I would overload the existing
> !size hack. For example, add an "f" for finished flag and say that the
> URIs are conceptually processed from left to right and if you send
> your report to one with a !f (or !10mf or the like) flag, you can stop.


Legacy producers unable to interpret "f" may discard the whole URI.


> Still not convinced this is useful but it is slightly more backward
> compatible.


For backward compatibility, one could add a comma before the OR-slash:

v=DMARC1; p=none; rua=mailto:local@example.com, mailto:report@service.example, /https://service.example/report/;

A legacy producer will discard "/https" as an unknown scheme.  It would have discarded "https" as well.

Am upgraded producer can interpret a leading slash as introducing an alternative to the preceding destination.  Possibly, there can be a series of them, to allow for secondary servers in case the previous URI fails.  The first scheme without a leading slash introduces a new series of alternatives.

For compatibility, mailto has to be the first URI of each series.  Logically, however, it must be considered to be the last alternative.  In fact, sending mail can only fail if the local submission server is unavailable.  So it doesn't make sense to have multiple mailto's in the same series.  This, the fact that supporting mailto is mandated, and backward compatibility justify the logic exception.


Best
Ale
--