Re: [dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML Schema

[Matthäus Wander]

Alessandro Vesely wrote on 2023-11-17 10:22:

On Thu 16/Nov/2023 16:47:48 +0100 Olivier Hureau wrote:
However, I think you should have a fixed value for the /version 
variable in order to clearly differentiate the XSD version, Even 
thought it is clearly specified in RFC 7489 :
``` The "version" for reports generated per this specification MUST 
bethe value 1.0. ``` It is not yet specified in Dmarcbis.



That's right.  The only mention is in Appendix B. Sample Report, saying 
1.0.


[...]

The IETF XML Registry is defined by RFC 3688.[*]  IANA is supposed to 
insert our "dmarc-2.0" per IANA Considerations section.  Referencing 
that schema in the feedback element identifies the format more clearly 
than a version number. However, Matt suggested to keep  for 
compliance with RFC 7489[†].  In that case, is it correct to stick to 1,0?



[*] https://www.iana.org/assignments/xml-registry/xml-registry.xhtml
[†] https://mailarchive.ietf.org/arch/msg/dmarc/JdRxmT9Aw3HkWM7rr3Av9B3EwRc


Speaking from today, I think the presence or content of the  
field does not really matter. The "dmarc-2.0" XML schema declares it 
optional, which is probably the best choice.


In my data, 75% of reporters announce 1.0. They can 
continue to do so. Dave Crocker has argued that bumping the version 
number is of no use:



Omitting the  field might confuse the statistics of report 
analyzers, but most likely won't do any harm.


Regards,
Matt

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML Schema

[Hector Santos]

> On Mar 11, 2024, at 10:33 PM, Neil Anuskiewicz 
>  wrote:
> 
> Wow, the stat on how many domain operators move to enforcing reject policy 
> sans aggregate reports shocked me. Trust the force, Luke.

It should not be a surprise the client/server protocol concept of “email 
reporting” was always and I still believe is considered a taboo as it can be a 
form of abuse when not negotiated, requested or solicited. It is an 100% 
optional feature to provide a reporting address.

With DMARC policy publishing, for exploratory reasons only, I have reports sent 
to an email to newsgroup forum where I can privately review and so far, it has 
not provided any benefit beyond what is expected.  I have advocated for a 
straight text report but I probably have to write a translator. The current 
format expects JSON/XML readers. 

 Our wcDMARC verification processor does not have built-in support for 
reporting. 


All the best,
Hector Santos


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML Schema

[Neil Anuskiewicz]

I’d say extend your thinking on why beyond the format itself. What else could be the cause? On Mar 11, 2024, at 7:33 PM, Neil Anuskiewicz  wrote:Wow, the stat on how many domain operators move to enforcing reject policy sans aggregate reports shocked me. Trust the force, Luke.On Feb 28, 2024, at 4:54 AM, OLIVIER HUREAU  wrote:Hello,TLDR: I think Dmarcbis should not have reference to the XML format of the aggregate reports in 5.5.3 and only refer to the [I-D.ietf-dmarc-aggregate-reporting] I've strayed a bit from DMARC, but occasionally I think about the aggregate reporting analysis problems a domain owner may encounter. In earlier emails, I mentioned using a JSON format for reports. Although the format change has been discussed in the past and the working group agreed not to switch to JSON, I'm not sure that providing a new XSD file will solve the problem of the multiple XSDs we already have.In my opinion, players who have already implemented the reporting system may not be inclined to update to the new format, and we'll then have 3 different definitions of XML.The question of JSON then arises, to start afresh on a sound footing. While this may require considerable effort in terms of RFC writing and code implementation, I think it will provide greater clarity and access for newcomers. As part of my research, I've written a paper on DMARC that will be published soon (mid-March). Even though DMARC adoption increases (4.5% in 2022 to 5.4% in 2023), the proportion of p=none handling policies also decreases (67.7% to 55.5%). One of my first hypotheses is that domain owners were using the reporting system to enhance their infrastructure and then adopted more restrictive policies.The figure below (Fig.7) illustrates the differences in reporting policies between the two years and that the adoption of more restrictive policies can be attributed tothe new DMARC domain names.However, the increase in the "restrictive" handling policy does not seem correlated with the use of the reporting system.I have compared the handling policies and content of RUA tags during the period (see graph below, Fig.8).To summarize my analysis: 54.7% of the domain name that had p=none and moved to p=reject, did not have rua tags ( 5) and 48.2% of all domain names displayed unexpected behavior: they removed the rua tag without adopting more restrictive policies or have adopted more strict policies without having rua tagsIn conclusion, I feel that there is something behind the difficulty of analyzing aggregate reports, and it is related to the current XML format...Nevertheless, this is only a feeling and not tangible proof (yet), so it doesn't constitute a reasonable technical argument to justify my remarks about a new JSON format.The current version of Dmarcbis does not leave room for a possible new aggregate report format in section 5.3.3. Shouldn't this section be less specific about the XML format, while still referring to [I-D.ietf-dmarc-aggregate-reporting], which could be updated in the future?If the working group is interested in the idea of a new (or alternative) JSON format, I can try my hand at writing a draft (if I'm accompanied by an IETF's experience writer).Regards,Olivier Hureau--PS: I can send interested readers a pre-printed version of my work.___dmarc mailing listdmarc@ietf.orghttps://www.ietf.org/mailman/listinfo/dmarc___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML Schema

[Neil Anuskiewicz]

Wow, the stat on how many domain operators move to enforcing reject policy sans aggregate reports shocked me. Trust the force, Luke.On Feb 28, 2024, at 4:54 AM, OLIVIER HUREAU  wrote:Hello,TLDR: I think Dmarcbis should not have reference to the XML format of the aggregate reports in 5.5.3 and only refer to the [I-D.ietf-dmarc-aggregate-reporting] I've strayed a bit from DMARC, but occasionally I think about the aggregate reporting analysis problems a domain owner may encounter. In earlier emails, I mentioned using a JSON format for reports. Although the format change has been discussed in the past and the working group agreed not to switch to JSON, I'm not sure that providing a new XSD file will solve the problem of the multiple XSDs we already have.In my opinion, players who have already implemented the reporting system may not be inclined to update to the new format, and we'll then have 3 different definitions of XML.The question of JSON then arises, to start afresh on a sound footing. While this may require considerable effort in terms of RFC writing and code implementation, I think it will provide greater clarity and access for newcomers. As part of my research, I've written a paper on DMARC that will be published soon (mid-March). Even though DMARC adoption increases (4.5% in 2022 to 5.4% in 2023), the proportion of p=none handling policies also decreases (67.7% to 55.5%). One of my first hypotheses is that domain owners were using the reporting system to enhance their infrastructure and then adopted more restrictive policies.The figure below (Fig.7) illustrates the differences in reporting policies between the two years and that the adoption of more restrictive policies can be attributed tothe new DMARC domain names.However, the increase in the "restrictive" handling policy does not seem correlated with the use of the reporting system.I have compared the handling policies and content of RUA tags during the period (see graph below, Fig.8).To summarize my analysis: 54.7% of the domain name that had p=none and moved to p=reject, did not have rua tags ( 5) and 48.2% of all domain names displayed unexpected behavior: they removed the rua tag without adopting more restrictive policies or have adopted more strict policies without having rua tagsIn conclusion, I feel that there is something behind the difficulty of analyzing aggregate reports, and it is related to the current XML format...Nevertheless, this is only a feeling and not tangible proof (yet), so it doesn't constitute a reasonable technical argument to justify my remarks about a new JSON format.The current version of Dmarcbis does not leave room for a possible new aggregate report format in section 5.3.3. Shouldn't this section be less specific about the XML format, while still referring to [I-D.ietf-dmarc-aggregate-reporting], which could be updated in the future?If the working group is interested in the idea of a new (or alternative) JSON format, I can try my hand at writing a draft (if I'm accompanied by an IETF's experience writer).Regards,Olivier Hureau--PS: I can send interested readers a pre-printed version of my work.___dmarc mailing listdmarc@ietf.orghttps://www.ietf.org/mailman/listinfo/dmarc___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML Schema

[Scott Kitterman]

On Thursday, February 29, 2024 9:04:03 AM EST Todd Herr wrote:
> On Wed, Feb 28, 2024 at 6:27 PM Douglas Foster <
> 
> dougfoster.emailstanda...@gmail.com> wrote:
> > I interpret your data differently.   These domains collected data until it
> > was clear that they could safely move to enforcement.   Thereafter, they
> > saw no need to study reports, at least until their configuration changes.
> > 
> >  Daily reporting is perceived as a waste of system and staff resources.
> > 
> > I suggested an errors-only reporting option, which would allow for error
> > monitoring without the wasted resources, but it was discarded by the
> > group.
> 
> Not all DMARC passes are intentional passes. The SPF upgrade attacks that
> we've witnessed over the past year or so and too-permissive SPF records in
> general are but two examples of where DMARC passes can occur for mail that
> was not authorized by the Domain Owner. A reporting model that only reports
> failures would not reveal these flows to the Domain Owner.
> 
> Please note that I am explicitly NOT arguing for a DMARC mechanism that
> does not rely on SPF; in fact I oppose such a thing at this time. Rather, I
> submit that it behooves Domain Owners to routinely clean and manage their
> SPF records to mitigate against risk of these sorts of attacks, and DMARC
> aggregate reports are a tool that can be used to do so.

I agree with this.  I would add that domain owners should look for evidence of 
cross-domain forgery in their data and where they see it seriously reconsider 
using that provider.  Unless there's some kind of market demand for correct 
implementation of SPF, there are apparently lots of providers that aren't 
going to bother.

Scott K



___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML Schema

[Todd Herr]

On Wed, Feb 28, 2024 at 6:27 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> I interpret your data differently.   These domains collected data until it
> was clear that they could safely move to enforcement.   Thereafter, they
> saw no need to study reports, at least until their configuration changes.
>  Daily reporting is perceived as a waste of system and staff resources.
>
> I suggested an errors-only reporting option, which would allow for error
> monitoring without the wasted resources, but it was discarded by the group.
>
>
Not all DMARC passes are intentional passes. The SPF upgrade attacks that
we've witnessed over the past year or so and too-permissive SPF records in
general are but two examples of where DMARC passes can occur for mail that
was not authorized by the Domain Owner. A reporting model that only reports
failures would not reveal these flows to the Domain Owner.

Please note that I am explicitly NOT arguing for a DMARC mechanism that
does not rely on SPF; in fact I oppose such a thing at this time. Rather, I
submit that it behooves Domain Owners to routinely clean and manage their
SPF records to mitigate against risk of these sorts of attacks, and DMARC
aggregate reports are a tool that can be used to do so.

-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML Schema

[Todd Herr]

On Wed, Feb 28, 2024 at 10:50 AM Brotman, Alex  wrote:

> Olivier,
>
>
>
> Yes, we’re firmly attached to XML for this iteration.  With the splitting
> of the documents, perhaps this could change in the future without changing
> the functionality of DMARC itself.
>
>
>
> Agreed on 5.5.3.
>

I also agree on 5.5.3, and DMARCbis rev-30 will contain no occurrences of
the three letter sequence "XML".

-- 

*Todd Herr * | Technical Director, Standards & Ecosystem
*e:* todd.h...@valimail.com
*p:* 703-220-4153
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML Schema

[Brotman, Alex]

Apologies, I went back to read this while I was looking for other updates.  

That URL was the only update that was required for DMARCbis for Aggregate 
Reports?  If so, it'll be updated in the next draft.

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

> -Original Message-
> From: Alessandro Vesely 
> Sent: Friday, November 17, 2023 4:22 AM
> To: dmarc@ietf.org; Brotman, Alex 
> Subject: Re: [dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML
> Schema
> 
> On Thu 16/Nov/2023 16:47:48 +0100 Olivier Hureau wrote:
> > On 15/11/2023 14:22, Alessandro Vesely wrote:
> >>
> >> We've had quite some discussion on that scheme, which resulted in
> >> https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-aggregate-reporting
> >> /blob/main/dmarc-xml-0.2.xsd
> >> included in the current draft.
> >
> > Indeed, I was referring to this one.
> > However, I think you should have a fixed value for the /version
> > variable in order to clearly differentiate the XSD version, Even
> > thought it is clearly specified in RFC 7489 :
> > ``` The "version" for reports generated per this specification MUST
> > bethe value 1.0. ``` It is not yet specified in Dmarcbis.
> 
> 
> That's right.  The only mention is in Appendix B. Sample Report, saying
> 1.0.
> 
> That sample record is wrong, as it identifies itself as  xmlns="http://dmarc.org/dmarc-xml/0.2;>.  It should have used
> xmlns="urn:ietf:params:xml:ns:dmarc-2.0".  My fault proposing it.  Alex,
> would you pleas fix that?
> 
> The IETF XML Registry is defined by RFC 3688.[*]  IANA is supposed to insert
> our "dmarc-2.0" per IANA Considerations section.  Referencing that schema in
> the feedback element identifies the format more clearly than a version
> number.
> However, Matt suggested to keep  for compliance with RFC 7489[†].
> In that case, is it correct to stick to 1,0?
> 
> I note that while the report metadata provides for producer identifiers and
> contacts, the software name and version are missing.  Or should version refer
> to the software?  (In that case only its name is missing...)
> 
> 
> Best
> Ale
> --
> [*] https://www.iana.org/assignments/xml-registry/xml-registry.xhtml
> [†]
> https://mailarchive.ietf.org/arch/msg/dmarc/JdRxmT9Aw3HkWM7rr3Av9B3
> EwRc
> 
> 
> 
> 
> 
> 

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML Schema

[Alessandro Vesely]

On Thu 16/Nov/2023 16:47:48 +0100 Olivier Hureau wrote:

On 15/11/2023 14:22, Alessandro Vesely wrote:


We've had quite some discussion on that scheme, which resulted in
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-aggregate-reporting/blob/main/dmarc-xml-0.2.xsd
included in the current draft. 


Indeed, I was referring to this one.
However, I think you should have a fixed value for the /version variable in 
order to clearly differentiate the XSD version, Even thought it is clearly 
specified in RFC 7489 :
``` The "version" for reports generated per this specification MUST bethe value 
1.0. ``` It is not yet specified in Dmarcbis.



That's right.  The only mention is in Appendix B. Sample Report, saying 
1.0.


That sample record is wrong, as it identifies itself as xmlns="http://dmarc.org/dmarc-xml/0.2;>.  It should have used 
xmlns="urn:ietf:params:xml:ns:dmarc-2.0".  My fault proposing it.  Alex, would 
you pleas fix that?


The IETF XML Registry is defined by RFC 3688.[*]  IANA is supposed to insert 
our "dmarc-2.0" per IANA Considerations section.  Referencing that schema in 
the feedback element identifies the format more clearly than a version number. 
However, Matt suggested to keep  for compliance with RFC 7489[†].  In 
that case, is it correct to stick to 1,0?


I note that while the report metadata provides for producer identifiers and 
contacts, the software name and version are missing.  Or should version refer 
to the software?  (In that case only its name is missing...)



Best
Ale
--
[*] https://www.iana.org/assignments/xml-registry/xml-registry.xhtml
[†] https://mailarchive.ietf.org/arch/msg/dmarc/JdRxmT9Aw3HkWM7rr3Av9B3EwRc







___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML Schema

[Olivier Hureau]

On 15/11/2023 14:22, Alessandro Vesely wrote:



We've had quite some discussion on that scheme, which resulted in
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-aggregate-reporting/blob/main/dmarc-xml-0.2.xsd 

included in the current draft. 


Indeed, I was referring to this one.
However, I think you should have a fixed value for the /version variable 
in order to clearly differentiate the XSD version, Even thought it is 
clearly specified in RFC 7489 :
``` The "version" for reports generated per this specification MUST 
bethe value 1.0. ``` It is not yet specified in Dmarcbis.


On 16/11/2023 02:25, Steven M Jones wrote:

I can put an updated version on dmarc.org


Attached you will find the version of the XSD as presented in RFC 7489. 
I have removed the trailing white-space and line breaks.
However, I would suggest waiting the WG opinion before doing any 
modifications. It's been like that for a long time already.



Regards,

Olivier





rfc7489.xsd
Description: XML document
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML Schema

[Steven M Jones]

On 11/15/23 02:12, OLIVIER HUREAU wrote:


As mentioned here: 
https://mailarchive.ietf.org/arch/msg/dmarc/ouSBtpMhD5KJp2osPfUXJktuoMQ/ 

I have found out that the current reporting ecosystem uses two types 
of XML Schema Definitions.


...

Upon investigation, I found that the XSD present in RFC 7489 Appendix 
C (https://datatracker.ietf.org/doc/html/rfc7489#appendix-C) contains 
a targetNamespace with the URI 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.



I can put an updated version on dmarc.org, but right now I'm trying to 
get out of a hotel room. probably 48 hours minimum before I can get to 
this, if somebody would be so kind as to identify the replacement.


--S.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML Schema

[Alessandro Vesely]

On Tue 14/Nov/2023 20:09:52 +0100 John Levine wrote:

Thanks for doing this work.  It cleans up a messy corner of DMARC.

It appears that OLIVIER HUREAU   said:
I was personally thinking about the following options: 


1) Specify Version "2" ...

2) Explore a JSON Format for Aggregated Reports: ...

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. 


If we were starting from scratch, 1 or 2 would be worth considering
but as you suggest, at this point nobody would do it.  So I agree
that it makes sense to build a schema that matches the reports
people are sending.



We've had quite some discussion on that scheme, which resulted in
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-aggregate-reporting/blob/main/dmarc-xml-0.2.xsd
included in the current draft.

At a glance, some differences between our xsd (I) and jorritholmer's one (J) 
are as follows:
* I specifies targetNamespace, xmlns and elementFormDefault,
* I redundantly specifies min/max occurs on almost every element,
* J has an added empty disposition string "because Splunk returns an empty 'sp' 
string",
* I has an ActionDispositionType for disposition whereas J misses the "pass" 
element,
* I has a DiscoveryType, added after tree walk,
* in PolicyPublishedType, I has testing, J has pct, fo, rf, ri, rua, ruf and v,
* J adds uppercase Pass and Fail in DMARCResultType,
* J has a minOccurs="0" for the case of no DKIM signatures (neither specify 
unbounded),
* I has IP regexes that fit RFC column limitation,
* J adds "unknown" and "error" to SPFResultType,
* I adds "human_result" to SPFAuthResultType,
* I adds an ExtensionType to the feedback element.

Some of that may deserve a bit of review.

Best
Ale
--






___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML Schema

[John Levine]

Thanks for doing this work.  It cleans up a messy corner of DMARC.

It appears that OLIVIER HUREAU   said:
>I was personally thinking about the following options: 
>
>1) Specify Version "2" ...
>
>2) Explore a JSON Format for Aggregated Reports: ...
>
>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. 

If we were starting from scratch, 1 or 2 would be worth considering
but as you suggest, at this point nobody would do it.  So I agree
that it makes sense to build a schema that matches the reports
people are sending.

R's,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML Schema

[OLIVIER HUREAU]

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