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

[Emil Gustafsson <[e-mail]>]

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=
[e-mail]> 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 <[e-mail]> *On Behalf Of * Marc Bradshaw
> *Sent:* Monday, December 7, 2020 5:17 PM
> *To:* DMARC IETF <[e-mail]>
> *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 <[e-mail]> On Behalf Of Alessandro Vesely
>
> >> Sent: Thursday, December 3, 2020 6:24 AM
>
> >> To: [e-mail]
>
> >> 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
>
> [e-mail]
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>