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

Marc Bradshaw <marc@marcbradshaw.net> Mon, 07 December 2020 22:17 UTC

Return-Path: <marc@marcbradshaw.net>
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 BD0443A0B92 for <dmarc@ietfa.amsl.com>; Mon, 7 Dec 2020 14:17:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-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 (2048-bit key) header.d=marcbradshaw.net header.b=Yu5B5Ixk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=p40Y3EnM
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 yjyRr9yIMasF for <dmarc@ietfa.amsl.com>; Mon, 7 Dec 2020 14:17:52 -0800 (PST)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF1DF3A0B6D for <dmarc@ietf.org>; Mon, 7 Dec 2020 14:17:51 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 85EAC13DD for <dmarc@ietf.org>; Mon, 7 Dec 2020 17:17:49 -0500 (EST)
Received: from imap10 ([10.202.2.60]) by compute3.internal (MEProxy); Mon, 07 Dec 2020 17:17:49 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= marcbradshaw.net; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=4ZEzN2L pwSpoTQ+mVmwERYlGKEggagCF1hQDnpy+gnQ=; b=Yu5B5Ixkv3KUo2jiFbiY9bi 04CFeZlNipQzF6o1XSD3i7nnUyQmtl1PVSSUGAz1L7JL63DVZFGGBVhipuqu2MTr m1AB0mY6l4lFuENlf7BVf2mJpXD9YHypOEukZSsLheM0u4DxoxL7NK1rbUlnHrtV 1XsOyEpIK6PNeYhBOuOuWc0IDcGbWdN2DeQC1adsz+iBojlZJ7TmRj0u45CGA2Ya SqlZheIsq0/1SDer7VGRIKEf1l8chaAEsda3oybP+I6AOsMf1DP5+OELGupVcMFl TgMxdC4M2+LHQ9/Ik/vYBIyBvnasuVZ6AsAsrEz08tlR3DqVXC9IMfzg0YiuMOw= =
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=4ZEzN2 LpwSpoTQ+mVmwERYlGKEggagCF1hQDnpy+gnQ=; b=p40Y3EnMGLnrXHxTF1s4ED 0uVRCY6TpK5smVEw+t5ckXOsMCx8+gZWdeOYKBep4UVXYcudZKC9W/2e6MhUayez 9xIxpa1Z8tWsjPA9G9M9XVQGNgnaflFvq7+LPFo8dzVFOqsxC79ga8lsPIVdXuVQ 4OXdMkmVuRBIdpx/jdBORdeR98Ua4JqJlPZhlWUN4kpfzDaWGkMlG7e5Adx1LwEY SlDe77/YNywmpOOAE0dbrmUdeeidL2XFrDHHo4rx11HVVYwYvhtq4YaWOHU8hVvC M+M0Bx1sDqIKfvJVCBfjDZkclEKMDtkNYPKyHwmJuY63LaA44UteoeBk9+UHlwow ==
X-ME-Sender: <xms:DKrOX5_BSXu7X_mwrbxIy25RZlQ3-X9mLL0iqsStutl4q5euIqoCvw> <xme:DKrOX9tm5mqODaXLmY6oQUyZw5o8GuHXAeq6c-tQfgEMVU3lklkPtpQ8y12s6ah53 B3YleSd01lPQ5p5wA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudejgedgudehlecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfofgr rhgtuceurhgrughshhgrfidfuceomhgrrhgtsehmrghrtggsrhgrughshhgrfidrnhgvth eqnecuggftrfgrthhtvghrnhepvdetveejhfejtdehvedttefftddtffeiveffueevhefg teevtedvudeikedtiedvnecuffhomhgrihhnpeiffedrohhrghdpughmrghrtgdrohhrgh dpihgvthhfrdhorhhgpdhmrghrtggsrhgrughshhgrfidrnhgvthdpthifihhtthgvrhdr tghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmrghrtgesmhgrrhgtsghrrggushhhrgifrdhnvght
X-ME-Proxy: <xmx:DKrOX3Dlxjf7R_CxaBin1I9gO3tOjZIKSSI-TltAy5xNtJsMVIFI8w> <xmx:DKrOX9e89VlgIlPMXuPswh_REfhK8Rx5E0AaM567k2EcSx5tRcWLsg> <xmx:DKrOX-NVwtmMT_KKwOn3YuGpj7eheU9brlhfTyAhfz7hxPJkFVQbng> <xmx:DarOX0YhD_2BSnVVIZ-zJ6oTzhuY8F-KqcXtRP3d56zU8nti2ICySw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9CDAE20126; Mon, 7 Dec 2020 17:17:48 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3
Mime-Version: 1.0
Message-Id: <caa661e5-dead-493b-ad27-8fef74b5499f@beta.fastmail.com>
In-Reply-To: <b00d374d-392c-5383-a4a1-31dc26d8e484@tana.it>
References: <MN2PR11MB43512A1BB729A717B6E688DFF7F30@MN2PR11MB4351.namprd11.prod.outlook.com> <d14f03ef-f4fd-1b7a-699c-c670dcd9631c@tana.it> <MN2PR11MB4351A6BF2052A98DF95EA2C6F7F20@MN2PR11MB4351.namprd11.prod.outlook.com> <b00d374d-392c-5383-a4a1-31dc26d8e484@tana.it>
Date: Tue, 08 Dec 2020 09:17:16 +1100
From: "Marc Bradshaw" <marc@marcbradshaw.net>
To: "DMARC IETF" <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary=cf268155a51c456b84a57e35dd933faf
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/y4kTSTHC8kGBkOLwEuqPYdt8tr8>
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: Mon, 07 Dec 2020 22:17:54 -0000

There is value in including these in one report, especially where the extended property being reported on influences how DMARC is evaluated.

Using ARC as the example, when a p=reject policy was overriden by the receiver because of an ARC evaluation, when that data is included in the report the indirect mail flow can be clearly seen, which would not be the case if ARC were included as a separate report.

This could be included in an <extension> element, or could be included directly in the auth_results section of the report, based on an assumption that the things being reported SHOULD have an authentication results entry in processed mail.

<auth_results>
<dkim>...</dkim>
<spf>...</spf>
<arc> (as defined in arc standard) </arc>
<foo> (as defined in foo standard) </foo>
</auth_results>

These would be defined in a registry with reference to each standard, and parsers would ignore any sections they did not understand.

On Fri, 4 Dec 2020, at 6:43 AM, Alessandro Vesely wrote:
> On Thu 03/Dec/2020 19:54:51 +0100 Brotman, Alex wrote:
> > 
> >> -----Original Message-----
> >> From: dmarc <dmarc-bounces@ietf.org> On Behalf Of Alessandro Vesely
> >> Sent: Thursday, December 3, 2020 6:24 AM
> >> To: dmarc@ietf.org
> >> Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56)
> >>
> >> 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.>>
> > 
> > We could add an element called "<extensions>", and we allow ARC or whatever
> > it may be to exist under that element.  The Aggregate Reporting document
> > needs to specify that any extensions are expected to be proper XML, and if
> > there are no extensions, an empty element is sufficient.  We could create a
> > bit more structure as a requirement if we wanted:> 
> > <extensions>
> >    <extension name="arc" standard="ARC_DMARC_REPORTING_EXTENSION_DEFINITION">
> >      ... (as defined in referenced standard)
> >    </extension>
> > </extensions>
> > 
> > If a report parser doesn't know what ARC is (or any of the extensions), it could skip the processing.  I do understand this means that <extensions> element may break existing parsers, even when empty, though, I expect many of the things we're proposing may fracture the expected XML.
> 
> 
> We can do a better job at producing aggregate reports with an automatically verifiable content.  For example, prepending stuff like this:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <dmarc:feedback xmlns:xs="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:dmarc="http://dmarc.org/dmarc-xml/0.1"
> xs:schemaLocation="http://dmarc.org/dmarc-xml/0.1 rua.xsd">
> <report_metadata>
>         ...
> 
> (Perhaps something better than "http://dmarc.org/dmarc-xml/0.1" for the version)
> 
> But then, would the <extensions> imply dmarc-xml grammar should be upgraded every time ARC (or whatever) is upgraded?
> 
> Separate reports sounds simpler.
> 
> 
> Best
> Ale
> -- 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
> 

--

  Marc Bradshaw
  marcbradshaw.net | @marcbradshaw <https://twitter.com/marcbradshaw>