Re: [dmarc-ietf] DMARC aggregate reports XML Schema inconsistencies

"Freddie Leeman" <freddie@leemankuiper.nl> Tue, 06 August 2019 22:05 UTC

From: Freddie Leeman <freddie@leemankuiper.nl>
To: 'Alessandro Vesely' <vesely@tana.it>, dmarc@ietf.org
References: <008401d54784$f8300750$e89015f0$@leemankuiper.nl> <e1fa3716-39b0-4de5-99df-10ed6fd91724@tana.it>
In-Reply-To: <e1fa3716-39b0-4de5-99df-10ed6fd91724@tana.it>
Date: Wed, 07 Aug 2019 00:05:52 +0200
Message-ID: <00b101d54ca3$1d388040$57a980c0$@leemankuiper.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AQEwMtDJj/TREh0OevgSswABly9FJAFy9+IqqC1FHHA=
Content-Language: nl
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/bfc2UAJ7LfWRgdykTlm4E6_87Ew>
Subject: Re: [dmarc-ietf] DMARC aggregate reports XML Schema inconsistencies
Precedence: list

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:vesely@tana.it] 
Verzonden: dinsdag 6 augustus 2019 19:37
Aan: dmarc@ietf.org
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>postmaster@example.com</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-ietf] DMARC aggregate reports XML Schema i… Freddie Leeman
Re: [dmarc-ietf] DMARC aggregate reports XML Sche… Kurt Andersen (b)
Re: [dmarc-ietf] DMARC aggregate reports XML Sche… Freddie Leeman
Re: [dmarc-ietf] DMARC aggregate reports XML Sche… Alessandro Vesely
Re: [dmarc-ietf] DMARC aggregate reports XML Sche… Freddie Leeman
Re: [dmarc-ietf] DMARC aggregate reports XML Sche… Alessandro Vesely
Re: [dmarc-ietf] DMARC aggregate reports XML Sche… Marc Bradshaw