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

Emil Gustafsson <emgu@google.com> Wed, 23 December 2020 19:49 UTC

Return-Path: <emgu@google.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 6192B3A09A4 for <dmarc@ietfa.amsl.com>; Wed, 23 Dec 2020 11:49:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 ogaZFZkqcSv4 for <dmarc@ietfa.amsl.com>; Wed, 23 Dec 2020 11:49:34 -0800 (PST)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C58AE3A0994 for <dmarc@ietf.org>; Wed, 23 Dec 2020 11:49:33 -0800 (PST)
Received: by mail-lf1-x130.google.com with SMTP id y19so42530304lfa.13 for <dmarc@ietf.org>; Wed, 23 Dec 2020 11:49:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Wg6vnNpZmWg0T7AvZEODSNDoqwVnwytRwhC48ECevVA=; b=ecqU5tR9yxROrPNywzwyoiVHOAHoGTPgvycyn6CBLv/2XKQswbmjuBHUQHxuLhi9N7 4j0DODs/YLP5tdon8kQAdCdOTF3dC46dB8Tty3RaGxRTNlnaEmJ/u4vxmB0ZDa5Zc0OM TmoEFhYtyPPmDkx3i1+fM3OQ55vClaV7VWk/1cHhTh/kpVQr/CPCIPA6yXXpWaPiljvM 6D9DKa0TRbNPGLEMzTXuDRaCP/+CJgjWaqqvaekeVy4A3ab3URNZP+9UsWWtKRdbuLTl PydpOeXtfTss+BdpfG+Fv6SO/ylnwSiLIY+plsgZUJ93a5Jgr1QgGnHKeHRmENtlGTwB AyLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Wg6vnNpZmWg0T7AvZEODSNDoqwVnwytRwhC48ECevVA=; b=b/giHkDV90QjOkdlK2dKYBQv8wf8DFsczRrKq3IM0TRfAGGfOeD0miPujrw2M7Nmy+ x7d/+Qc2f+wMg1WwAT+ziRp05Vs/G54WoIn/WhOxqhPyCPukKU7O9T4N3dHnfnt2bgjK 0/b/n9L59TC9An2F62IXPWoOwxET4eglj/8rCAPhGJ8vCEIS1CxJh5Twm2dLbMmeS05d T1w6WTFhs9th3QcxpKZ88j11DnE+AKmsFKzoLBIaXbAY0m1oOwYAM5jdcEMkdnKP6Cdk d0M5g4aA7zIskRIX5bV9CZcqTWujJmUrvMsNeUqVSikPO1l9Pxvc8V2qSL8Sa3J+wlKY MGpA==
X-Gm-Message-State: AOAM531qq9KbDK9l3MSBRUK1RKPa2c8hP8SDoiivDM/JYmv8lb+q/JyN L1Dzvxbdjs4OE3AOjTM7pAYl8C5opmgznfdf5xUA6AGIK+Lvkw==
X-Google-Smtp-Source: ABdhPJzNMShJvSlKMwtByeaG+EvKJkcavqUPPt8TgBOeOY3kL4zRWLL3iR5L0yRBoL9XrcAs+zWKRJXXXcmHXF0xcVo=
X-Received: by 2002:a2e:8113:: with SMTP id d19mr11629884ljg.303.1608752971150; Wed, 23 Dec 2020 11:49:31 -0800 (PST)
MIME-Version: 1.0
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> <caa661e5-dead-493b-ad27-8fef74b5499f@beta.fastmail.com> <MN2PR11MB43511AD9A2B8C6CF1356491DF7CD0@MN2PR11MB4351.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB43511AD9A2B8C6CF1356491DF7CD0@MN2PR11MB4351.namprd11.prod.outlook.com>
From: Emil Gustafsson <emgu@google.com>
Date: Wed, 23 Dec 2020 11:49:19 -0800
Message-ID: <CABZJ8knMmn-DmAQ_5TuDO13Rsu8=f9R2=XG3GFvpL=Uqy5RMJw@mail.gmail.com>
To: "Brotman, Alex" <Alex_Brotman=40comcast.com@dmarc.ietf.org>
Cc: Marc Bradshaw <marc=40marcbradshaw.net@dmarc.ietf.org>, DMARC IETF <dmarc@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000006ab52305b726fd06"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/QofzOs9HaCKo01YizE3Pb84QMI8>
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: Wed, 23 Dec 2020 19:49:38 -0000

While the common format would be great as a consumer of reports, I'm
wondering how many different reports there would be. New auth standards
don't pop up that often, so what other reports are you thinking about? I
can see two obvious candidates; the mailserver software and the spam/abuse
prevention software. It would be interesting to support something like that
too but shouldn't those just put the results inside the dkim/spf/arc
auth_results?
/E

On Tue, Dec 8, 2020 at 12:29 PM Brotman, Alex <Alex_Brotman=
40comcast.com@dmarc.ietf.org> wrote:

> I feel (as a receiver of reports) as though another reason to have these
> as a single report is so that the receiver of the report is able to more
> easily correlate the data/times.  I should be able to believe that all
> reports (without a specified ri) will be 0000-2359, though things happen,
> and systems break down.
>
>
>
> --
>
> Alex Brotman
>
> Sr. Engineer, Anti-Abuse & Messaging Policy
>
> Comcast
>
>
>
> *From:* dmarc <dmarc-bounces@ietf.org> *On Behalf Of * Marc Bradshaw
> *Sent:* Monday, December 7, 2020 5:17 PM
> *To:* DMARC IETF <dmarc@ietf.org>
> *Subject:* Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket
> #56)
>
>
>
>
>
> 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
> <https://urldefense.com/v3/__http:/www.w3.org/2001/XMLSchema-instance__;!!CQl3mcHX2A!W_xDXVx707gc61M5TAh1t1CL61wpj57BHndbtFxULnxLzggrXnZfXLDP5T6PCW5mqmCE$>
> "
>
> xmlns:dmarc="http://dmarc.org/dmarc-xml/0.1
> <https://urldefense.com/v3/__http:/dmarc.org/dmarc-xml/0.1__;!!CQl3mcHX2A!W_xDXVx707gc61M5TAh1t1CL61wpj57BHndbtFxULnxLzggrXnZfXLDP5T6PCX_7HCv_$>
> "
>
> xs:schemaLocation="http://dmarc.org/dmarc-xml/0.1
> <https://urldefense.com/v3/__http:/dmarc.org/dmarc-xml/0.1__;!!CQl3mcHX2A!W_xDXVx707gc61M5TAh1t1CL61wpj57BHndbtFxULnxLzggrXnZfXLDP5T6PCX_7HCv_$>
> rua.xsd">
>
> <report_metadata>
>
>         ...
>
>
>
> (Perhaps something better than "http://dmarc.org/dmarc-xml/0.1
> <https://urldefense.com/v3/__http:/dmarc.org/dmarc-xml/0.1__;!!CQl3mcHX2A!W_xDXVx707gc61M5TAh1t1CL61wpj57BHndbtFxULnxLzggrXnZfXLDP5T6PCX_7HCv_$>"
> 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
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;!!CQl3mcHX2A!W_xDXVx707gc61M5TAh1t1CL61wpj57BHndbtFxULnxLzggrXnZfXLDP5T6PCcp8JAZr$>
>
>
>
>
>
> --
>
>   Marc Bradshaw
>
>   marcbradshaw.net
> <https://urldefense.com/v3/__http:/marcbradshaw.net/__;!!CQl3mcHX2A!W_xDXVx707gc61M5TAh1t1CL61wpj57BHndbtFxULnxLzggrXnZfXLDP5T6PCcwnsT8Z$>
> | @marcbradshaw
> <https://urldefense.com/v3/__https:/twitter.com/marcbradshaw__;!!CQl3mcHX2A!W_xDXVx707gc61M5TAh1t1CL61wpj57BHndbtFxULnxLzggrXnZfXLDP5T6PCZsg4P4v$>
>
>
>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>