Subject: [dmarc-ietf] Versioning and XML namespaces in aggregate reports (#33, #70)

From: Matthäus Wander <[email-masked]>
Date: Mon, 10 May 2021 16:10:30 +0200

1) #33 suggests to add a versioned XML namespace declaration in the root
<feedback> element.
https://trac.ietf.org/trac/dmarc/ticket/33

I support the use of the namespace declaration. A report with namespace
declaration allows for automatic syntax checks with XML Schema
Validation. XSD validators refuse to work without the declaration. It
should be added to the examples in the I-D.

Example report:
  <dmarc:feedback xmlns:dmarc="http://dmarc.org/dmarc-xml/0.2">
  ...
  </dmarc:feedback>

A shorter variant is possible if we change the schema slightly:
  <feedback xmlns="http://dmarc.org/dmarc-xml/0.2">
  ...
  </feedback>

Adapted schema with elementFormDefault:
  <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
    targetNamespace="http://dmarc.org/dmarc-xml/0.2"
    xmlns="http://dmarc.org/dmarc-xml/0.2"
    elementFormDefault="qualified">

Nit: I'd use 2.0 instead of 0.2.

2) #33 goes further and suggests to remove the <version> tag below
<feedback>, because it is redundant with the namespace declaration.

I wouldn't recommend the removal. RFC 7489 has introduced tag
<version>1.0</version> and existing implementations will rely on its
existence. Without <version>, chances are the report consumer interprets
the report as pre-IETF draft version.

3) #70 introduces a new <version> field, but this one is below
<report_metadata> and seems to have the purpose to inform about which
DMARC standard has been used for validation.
https://trac.ietf.org/trac/dmarc/ticket/70

Is it useful to announce separate version numbers for the DMARC
algorithm and the report format? I imagine, the RFC 7489 <version> would
do the job for both purposes.

4) How does the report generator know which format version the consumer
supports?

Ideas:
a) Send new format and don't care about old versions.
b) Send new format but avoid compatibility breaking changes in the XML
design. Add new fields, but do not change existing ones like
<disposition> (cf. #51, #75).
c) Consumer announces supported version in DNS record ("rua2=" or whatever).
d) Send both versions (... for how long?).

Regards,
Matt

---

From: "John Levine" <[email-masked]>
Date: 10 May 2021 11:21:08 -0400

It appears that Matthäus Wander <[email-masked]> said:
>I support the use of the namespace declaration. 

>4) How does the report generator know which format version the consumer

It doesn't.  If we change the schema, a lot of report parsers will break.  What actual
real world problem does this change solve?  I haven't seen a lot of ill-formed reports.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 May 2021 08:28:20 -0700

On 5/10/2021 7:10 AM, Matthäus Wander wrote:
> Validation.

Version numbers, and the like, tend to be a lot less useful than 
intuition leads one to expect.

The distinction to make is 'increments' versus 'incompatibilities'.l

If an new spec merely /adds/ to a previous spec, then the presence of 
the new constructs is self-declaring.  The only requirement is to have 
the base specification declare that unrecognized constructs are to be 
ignored.  So, versioning adds the illusion of utility, but really only 
adds unnecessary complexity.

Incompatibilities, where new constructs conflict with previous ones, 
mean that the new specification is not a new version.  It is an 
independent specification.  It needs to be labeled accordingly.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
[email-masked]

---

From: Matthäus Wander <[email-masked]>
Date: Mon, 10 May 2021 17:50:42 +0200

John Levine wrote on 2021-05-10 17:21:
> real world problem does this change solve?

The schema is broken already. See:
https://trac.ietf.org/trac/dmarc/ticket/44
https://trac.ietf.org/trac/dmarc/ticket/45
https://www.uriports.com/blog/dmarc-reports-ietf-rfc-compliance/

The point is to fix the schema.

> I haven't seen a lot of ill-formed reports.

You obviously haven't tried XSD validation.

Regards,
Matt

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 10 May 2021 18:29:37 +0200

On Mon 10/May/2021 17:28:20 +0200 Dave Crocker wrote:
> Version numbers, and the like, tend to be a lot less useful than intuition 
> leads one to expect.

Automatic syntax checks are a different beast, though.

> The distinction to make is 'increments' versus 'incompatibilities'.
> 
> If an new spec merely /adds/ to a previous spec, then the presence of the new 
> constructs is self-declaring.  The only requirement is to have the base 
> specification declare that unrecognized constructs are to be ignored.  So, 
> versioning adds the illusion of utility, but really only adds unnecessary 
> complexity.

I think the format we'll end up with will be pretty compatible with the 
existing practice, meaning that existing report consumers that use a proper XML 
parser and ignore unknown tags can work unchanged.  I don't think any consumer 
parses reports "by hands".

The added complexity of using proper XML constructs to define the format, as 
well as properly formatting each instance, enables advanced use of XML parsing 
tools.  Did you notice no site offers aggregate report validation services?

> Incompatibilities, where new constructs conflict with previous ones, mean that 
> the new specification is not a new version.  It is an independent 
> specification.  It needs to be labeled accordingly.

This is not our case.  Even if we find a better TLD for the targetNamespace 
URL, the format is going to be the first official version of DMARC aggregate 
report format, following the one(s) in use since 2012.

Best
Ale
--

---

From: Matthäus Wander <[email-masked]>
Date: Thu, 13 May 2021 23:29:01 +0200

Alessandro Vesely wrote on 2021-05-10 18:29:
> existing practice, meaning that existing report consumers that use a
> proper XML parser and ignore unknown tags can work unchanged.  I don't
> think any consumer parses reports "by hands".

Alright, introducing incompabilities is off the table and backward
compability is a must. This brings #51 into question, which may affect
backward compability.
https://trac.ietf.org/trac/dmarc/ticket/51

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.

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.
A version number within the schema is not necessary for this use case.

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.

Regards,
Matt

---

From: "Brotman, Alex" <[email-masked]>
Date: Fri, 14 May 2021 13:42:56 +0000

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.

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.

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

> -----Original Message-----
> From: dmarc <[email-masked]> On Behalf Of Matthäus Wander
> Sent: Thursday, May 13, 2021 5:29 PM
> To: [email-masked]
> Subject: Re: [dmarc-ietf] Versioning and XML namespaces in aggregate
> reports (#33, #70)
>
> >> the new constructs is self-declaring.  The only requirement is to
> >> have the base specification declare that unrecognized constructs are
> >> to be ignored.  So, versioning adds the illusion of utility, but
> >> really only adds unnecessary complexity.
> >
> >
> > I think the format we'll end up with will be pretty compatible with
> > the existing practice, meaning that existing report consumers that use
> > a proper XML parser and ignore unknown tags can work unchanged.  I
> > don't think any consumer parses reports "by hands".
>
> Alright, introducing incompabilities is off the table and backward compability
> is a must. This brings #51 into question, which may affect backward
> compability.
> https://urldefense.com/v3/__https://trac.ietf.org/trac/dmarc/ticket/51__;!!
> CQl3mcHX2A!RCdb_46_lcqdxdM882JSzD-hjS-
> 66H5H0OL8qTxqEITjJ7dViYTApbhFoP1sF8sc-3FowsLllQ$
>
>
> 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.
>
>
> 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.
> 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.
>
> Regards,
> Matt
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc
> __;!!CQl3mcHX2A!RCdb_46_lcqdxdM882JSzD-hjS-
> 66H5H0OL8qTxqEITjJ7dViYTApbhFoP1sF8sc-3GZUejGJQ$

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 14 May 2021 20:12:42 +0200

> 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…

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, tha…

Overkill IMHO.

>> 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

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.

>> 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.

>> desired. This would require careful foresight in the schema design.

Designing an abstract extension for ARC is going to be particularly challenging.

Best
Ale
--

---

From: "Brotman, Alex" <[email-masked]>
Date: Fri, 14 May 2021 18:21:59 +0000

We "can avoid", but *must* we?  There are a number of tickets this impacts.

> From: dmarc <[email-masked]> On Behalf Of Alessandro Vesely
> Sent: Friday, May 14, 2021 2:13 PM
> To: [email-masked]
> > 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.
>
>
> >> 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.
>
> 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, ...
>
> >> 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.
>
>
> __;!!CQl3mcHX2A!Q3kGuVczKJh6EQuYf24QFyvWnwvaeUkyjnyhIGu9DMQQ-
> 6Xb_w-hV7tSxFRmor-OwwfRXbxMrg$

---

From: Matthäus Wander <[email-masked]>
Date: Sun, 16 May 2021 00:25:44 +0200

Alessandro Vesely wrote on 2021-05-14 20:12:
> 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, ...

In my data, 84% (193/229) of reporters announce <version>1.0</version>.
16% of reporters omit the version and seem to use the pre-IETF draft schema.

Regards,
Matt

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 16 May 2021 11:47:17 +0200

> We "can avoid", but *must* we?  There are a number of tickets this impacts.

Yes.  Matt mentioned ticket #51 (added in the subject), for example.

That change might break consumers who meticulously check the values, but those 
who just report whatever values they found might be undamaged.  In this case, 
I'd reckon that backward compatibility concerns would account for a rather 
minor hesitance against the change.  I'd say 2 on a 0-10 scale.

Perhaps we should rate each ticket.  Or we could produce some dummy reports 
with the new format and check how many parsers still work on them.

Best
Ale
--