Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56)

Alessandro Vesely <vesely@tana.it> Thu, 03 December 2020 11:24 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 0FCB83A045E for <dmarc@ietfa.amsl.com>; Thu, 3 Dec 2020 03:24:32 -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 g6O-zDxJGCuL for <dmarc@ietfa.amsl.com>; Thu, 3 Dec 2020 03:24:30 -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 1B2B03A046A for <dmarc@ietf.org>; Thu, 3 Dec 2020 03:24:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1606994668; bh=p7HKssRH2gJnPEJIUVz/sSaY4lXzmRArKNvODlk9iyI=; l=1053; h=To:References:From:Date:In-Reply-To; b=BJoSYzv+hMCek+IGEtWuoomMAY4RmyZhe43Li11fFMmS8wy2U4nfAROfqOTgLBMri 74XYwwhlWuWrMVhYT5BMinqKaWmddUjNyCQJ+k1CEoLI5WZy1XMQP0RL9yZVygH9gZ xlRjN7gRhwmqBxsQKQ5ClPWKzLmfX4Ll8N+qejYmvNg2jOgqCxUAvI54s+STZ
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 00000000005DC03D.000000005FC8CAEC.0000654C; Thu, 03 Dec 2020 12:24:28 +0100
To: dmarc@ietf.org
References: <MN2PR11MB43512A1BB729A717B6E688DFF7F30@MN2PR11MB4351.namprd11.prod.outlook.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <d14f03ef-f4fd-1b7a-699c-c670dcd9631c@tana.it>
Date: Thu, 3 Dec 2020 12:24:28 +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: <MN2PR11MB43512A1BB729A717B6E688DFF7F30@MN2PR11MB4351.namprd11.prod.outlook.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/t97fbj_DjCvnxzvpd-ro0WOM3_k>
Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56)
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: Thu, 03 Dec 2020 11:24:32 -0000

On Wed 02/Dec/2020 20:46:54 +0100 Brotman, Alex wrote:
> 
> While this ticket/enhancement specifically mentions ARC, I could perhaps see the usefulness in other places.  It seems like it would be more beneficial to create a method by which other documents could provide XML- based "extensions" to the report.  This would allow mechanisms relying on DMARC to independently define their reporting schema to be included in DMARC aggregate reports.  Alternately, we could focus specifically on ARC, and work to include that in the base XML.  This means that any later reporting requirements could again require changes to the core drafts.
> 


Another possibility is for ARC to define its own report format.  Hijacking rua= 
targets to send a different kind of report should be allowed.  Otherwise, we 
could define a new tag, e.g. rue= (e for Extension).

In either case, as we're introduce variations in aggregate report content, we 
have to devise a method for determining what version/kind of report is attached 
to a given message.


Best
Ale
--