Re: [dmarc-ietf] Versioning and XML namespaces in aggregate reports (#33, #70)

["Brotman, Alex" <[e-mail]>]

We "can avoid", but *must* we?  There are a number of tickets this impacts.

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

> -----Original Message-----
> From: dmarc <[e-mail]> On Behalf Of Alessandro Vesely
> Sent: Friday, May 14, 2021 2:13 PM
> To: [e-mail]
> Subject: Re: [dmarc-ietf] Versioning and XML namespaces in aggregate
> reports (#33, #70)
>
> On Fri 14/May/2021 15:42:56 +0200 Brotman, Alex wrote:
> > There are a few tickets that may break report ingestion systems due to
> structure and/or value changes.  Should we decide that's an implementation
> issue, or that we truly can't change the format of the reports?  I'm sure most
> ingestion systems are rather flexible given the number of reports that
> appear to not match what 7489 states/suggests.
>
>
> Report consumers use XML libraries to recover the value of named fields.
> We can safely add fields.  Renaming fields or change existing semantics
> would break backward compatibility, which I think we can avoid.
>
>
> > If we are going to allow changes to the structure, and there is some
> concern about which version the receiver supports (or prefers?), should we
> put a flag into the DMARC record?  And of course, that may dependent on
> the receiver, if multiple are listed, so that would have to belong to each
> individual receiving address.
>
>
> Overkill IMHO.
>
>
> >> From: dmarc <[e-mail]> On Behalf Of Matthäus Wander
> >>
> >> Regarding the existing top-level <version> below <feedback>: Even if
> >> parsers don't require the version to function, it remains useful for
> >> measuring the adoption of the different DMARC specifications (as
> >> requested in #70). In fact, one implementation I looked at
> >> (parsedmarc) uses it for only this purpose. A missing <version> is logged
> as "draft"
> >> schema version.
>
> In my tiny MX I have a cache of 631 aggregate reports received recently.  121
> reports from 31 unique org_names have a /feedback/version element, 510
> from 37 organizations don't.  The latter group includes google.com, Yahoo!
> Inc., Verizon Media, Mail.Ru, ...
>
> Perhaps, someone with larger mail flows can bring better statistics.
>
>
> >> Regarding the XML namespace declaration:
> >> The XML schema serves not only as specification for developers, but
> >> can be also used for automatic syntax checks of reports -- provided
> >> that the namespace declaration is fixed. XSD validation is an
> >> immensely useful tool for testing the output of report generators. It
> >> helped me to discover two nasty bugs in an implementation, which
> >> appeared in 2 out of ~10k reports and would have gone unnoticed
> otherwise.
>
>
> Very much agreed.  Validating the report before sending is very safe.  Also
> building online aggregate report checking utilities would benefit from this
> possibility.
>
> Does the IETF provide URLs for hosting XSDs?
>
>
> >> A version number within the schema is not necessary for this use case.
>
>
> Or we can stick to a static <version>1.0</version>, similar to v=DMARC1,
> MIME-Version, and the like, if useful.
>
>
> >> A different matter is whether automatic XSD validation on the report
> >> consumer side is a supported use case. There is some value in it: two lines
> of
> >> code suffice to perform input validation. However, the validation is strict
> and
> >> does not allow for being liberal in what you accept (might be handy for
> >> protocol police, though). Achieving upward compatibility is not trivial,
> >> because there is no general "ignore all unknown elements" statement in
> >> XSD. It is possible to define a <xs:any> placeholder in the schema, but this
> >> element must be inserted explicitly into each place where extensibility is
> >> desired. This would require careful foresight in the schema design.
>
>
> Designing an abstract extension for ARC is going to be particularly challenging.
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc
> __;!!CQl3mcHX2A!Q3kGuVczKJh6EQuYf24QFyvWnwvaeUkyjnyhIGu9DMQQ-
> 6Xb_w-hV7tSxFRmor-OwwfRXbxMrg$