Great!... more inconsistencies. The xsd file does not make things better. It also does not mention 'envelope_from', spf scope, and parent version. I understand now why so many organizations have a different implementation of DMARC aggregate reporting. I think we can all agree this is a mess we need to fix. I don't believe the namespaces and schema locations are the biggest issues but the RFC should be clear about that to. Thanks for bringing the xsd to my attention.
-- Freddie Leeman -----Oorspronkelijk bericht----- Van: Alessandro Vesely [mailto:[email protected]] Verzonden: dinsdag 6 augustus 2019 19:37 Aan: [email protected] Onderwerp: Re: [dmarc-ietf] DMARC aggregate reports XML Schema inconsistencies On Wed 31/Jul/2019 11:47:29 +0200 Freddie Leeman wrote: > [...] > > DMARC reporting capabilities are a valuable aspect of the DMARC > mechanism. It can help domain owners in setting up and hardening their DKIM/SPF/DMARC policy. > But unless these reports follow strict guidelines they just pile up to > a lot of inconsistent data open to interpretation and guesswork. > Domain owners should be able to understand the data without the need > for a spiritual voodoo DMARC guru (trademark pending) to make sense of it all. I had tried and programmed carefully, but never formally checked what I was sending. Too bad. Now that I did, I see my reports miss the <pct> and <fo>[*] elements, and some other nuisance. However, the most striking difference is that, after some tinkering, to be able to formally validate a report, it has to be rewritten like so: <?xml version="1.0" encoding="UTF-8"?> <dmarc:feedback xmlns:xs="http://www.w3.org/2001/XMLSchema-instance"; xmlns:dmarc="http://dmarc.org/dmarc-xml/0.1"; xs:schemaLocation="http://dmarc.org/dmarc-xml/0.1 rua.xsd"> <report_metadata> <org_name>example.com</org_name> <email>[email protected]</email> [...] Is that correct? Is that how reports should be written? I ask because checking some aggregate report I received, I found no mention of namespaces and schema locations. XSLT works well even without those. Validation doesn't. What do you reckon? Best Ale -- [*] <fo> is present in Appendix C of the spec, but not in https://dmarc.org/dmarc-xml/0.1/rua.xsd _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
