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://www.ietf.org/mailman/listinfo/dmarc
