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 <dmarc-boun...@ietf.org> On Behalf Of Alessandro Vesely > Sent: Friday, May 14, 2021 2:13 PM > To: dmarc@ietf.org > 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 <dmarc-boun...@ietf.org> 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 > dmarc@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc > __;!!CQl3mcHX2A!Q3kGuVczKJh6EQuYf24QFyvWnwvaeUkyjnyhIGu9DMQQ- > 6Xb_w-hV7tSxFRmor-OwwfRXbxMrg$ _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
