Hi, As mentioned here: [ https://mailarchive.ietf.org/arch/msg/dmarc/ouSBtpMhD5KJp2osPfUXJktuoMQ/%C2%A0 | https://mailarchive.ietf.org/arch/msg/dmarc/ouSBtpMhD5KJp2osPfUXJktuoMQ/ ] I have found out that the current reporting ecosystem uses two types of XML Schema Definitions.
During IETF-118, I raised concerns to John and Murray regarding the current reporting ecosystem's use of two types of XML Schema Definitions. They suggested creating a dedicated thread to address this matter. Upon investigation, I found that the XSD present in RFC 7489 Appendix C ( [ https://datatracker.ietf.org/doc/html/rfc7489#appendix-C | https://datatracker.ietf.org/doc/html/rfc7489#appendix-C ] ) contains a targetNamespace with the URI [ http://dmarc.org/dmarc-xml/0.1. | http://dmarc.org/dmarc-xml/0.1. ] However, the website offers a different XSD. It seems plausible that implementers may have downloaded the version from dmarc.org, which lacks certain elements like /record/auth_result/spf/scope, /policy_published/fo, /record/identifiers/envelope_from, and /version, in contrast to the RFC version. Additionally, errata 5229 ( [ https://www.rfc-editor.org/errata/eid5229 | https://www.rfc-editor.org/errata/eid5229 ] ) and 5733 ( [ https://www.rfc-editor.org/errata/eid5229 | https://www.rfc-editor.org/errata/eid5229 ] ) introduce further disparities. Furthermore, the Dmarcbis XML schema ( [ https://www.ietf.org/archive/id/draft-ietf-dmarc-aggregate-reporting-13.html#name-appendix-a-dmarc-xml-schema | https://www.ietf.org/archive/id/draft-ietf-dmarc-aggregate-reporting-13.html#name-appendix-a-dmarc-xml-schema ] ) also deviates from the previous versions. These inconsistencies pose challenges for report receivers, leading to difficulties in parsing aggregated reports. I believe it is imperative for our working group to address and rectify these issues. I was personally thinking about the following options: 1) Specify Version "2" in the XML Schema for DmarcBis Aggregated Reports: While this option provides clarity on the version, there may be reluctance among actors to re-implement the reporting system. I am not sure that even with Dmarcbis, the report's sender will modify their implementation 2) Explore a JSON Format for Aggregated Reports: Considering a shift to a JSON format may address the inconsistencies and encourage improvements in implementations. This approach could potentially bring about a positive transformation in the reporting system (at the same time, they might fix their implementations and have a correct email object, who knows..). 3) Create an Extended XML Schema for Interoperability: Developing an extended XML schema that ensures interoperability across all versions could be a comprehensive solution. I have identified a working draft ( [ https://github.com/jorritfolmer/TA-dmarc/blob/master/bin/dmarc/rua_ta_dmarc_relaxed_v01.xsd | https://github.com/jorritfolmer/TA-dmarc/blob/master/bin/dmarc/rua_ta_dmarc_relaxed_v01.xsd ] ) that demonstrates promise, having resulted in approximately 10 times fewer reports with errors. I am inclined towards the third option as it offers a holistic approach to interoperability. I am looking forward to your remarks and propositions. Regards, Olivier Hureau
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
