Subject: [dmarc-ietf] draft-ietf-dmarc-aggregate-reporting-04 feedback

From: Richard Gray <[email-masked]>
Date: Tue, 25 Jan 2022 23:03:00 +1300

Hi,

I've been reading over the DMARC Aggregate Reporting draft and have
some feedback on the schema and sample report.

* The ActionDispositionType type definition in the schema is missing a
closing </xs:simpleType> tag

* The schema has the DMARC report version element (<version>)
specified immediately under the <feedback> root element and not under
<report_metadata> as stated in section 2.1

* The draft states that <policy_published> has mandatory fields
domain, p, and sp, and optional fields fo, adkim, aspf, and testing.
The schema for PolicyPublishedType has mandatory fields domain and
version_published, with all other fields optional. Should
version_published be mandatory or optional?

* The schema for IdentifierType has header_from and envelope_from as
mandatory fields, and envelope_to as an optional field. The sample
report includes only header_from. The draft text in section 2.1 says
"In most cases, this will be a header_from element, which will contain
the 5322.From domain from the message". Is it the intention of the
draft that envelope_to should be mandatory?

* The schema for SPFAuthResultType has scope (mfrom/helo) as a
mandatory attribute but the sample report does not include a scope
section. Should the SPF scope be a mandatory field?

* The schema does not currently permit report extensions as described
in the draft (section 4). I am not sure if it is possible to define a
schema allowing an arbitrary element name with a required definition
attribute (pointing to the extension spec).

  As an alternative, would it be better to have a standard element
name representing an arbitrary extension, with an attribute (even just
the definition URI) to identify the specific extension in use? E.g.

  <extensions>
    <extension definition="https://www.example.com/dmarc-extension/0.1">
      ...
    </extension>
  </extensions>

* Lastly, the draft states that reports have two primary sections, one
with descriptive information and the other with row-data for the
report. The "informative" section is broken into two sub-sections,
which are report_metadata and policy_published. Would it perhaps be
clearer to say that there are three main sections rather than two?
report_metadata and policy_published are subsections of the main
feedback element along with the record elements holding the row data.
The schema is clear in this instance, I just wondered if the wording
in the draft might be improved.

Regards,
Richard

---

From: "Brotman, Alex" <[email-masked]>
Date: Wed, 26 Jan 2022 01:40:48 +0000

Richard,

Thanks for the notes.  I'll file a few trac issues to get these resolved, and try to get a new version released soon-ish.  If you're okay with it, I may send you a preview version to ensure it resolves the items noted below.  Thanks again

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

> -----Original Message-----
> From: dmarc <[email-masked]> On Behalf Of Richard Gray
> Sent: Tuesday, January 25, 2022 5:03 AM
> To: [email-masked]
> Subject: [dmarc-ietf] draft-ietf-dmarc-aggregate-reporting-04 feedback
>
> Hi,
>
> I've been reading over the DMARC Aggregate Reporting draft and have some
> feedback on the schema and sample report.
>
> * The ActionDispositionType type definition in the schema is missing a closing
> </xs:simpleType> tag
>
> * The schema has the DMARC report version element (<version>) specified
> immediately under the <feedback> root element and not under
> * The draft states that <policy_published> has mandatory fields domain, p, and
> sp, and optional fields fo, adkim, aspf, and testing.
> version_published, with all other fields optional. Should version_published be
> mandatory or optional?
>
> mandatory fields, and envelope_to as an optional field. The sample report
> includes only header_from. The draft text in section 2.1 says "In most cases, this
> will be a header_from element, which will contain the 5322.From domain from
> the message". Is it the intention of the draft that envelope_to should be
> mandatory?
>
> * The schema for SPFAuthResultType has scope (mfrom/helo) as a mandatory
> attribute but the sample report does not include a scope section. Should the SPF
> scope be a mandatory field?
>
> * The schema does not currently permit report extensions as described in the
> draft (section 4). I am not sure if it is possible to define a schema allowing an
> arbitrary element name with a required definition attribute (pointing to the
> extension spec).
>
>   As an alternative, would it be better to have a standard element name
> representing an arbitrary extension, with an attribute (even just the definition
> URI) to identify the specific extension in use? E.g.
>
>   <extensions>
>     <extension
> definition="https://urldefense.com/v3/__https://www.example.com/dmarc-
> extension/0.1__;!!CQl3mcHX2A!SZyg4CQrLEXm4I_qOm-N9qEMlEx-
> YkNnYRm5_S0C6L9rYHWuDoTGAMToQF8p5wahviZ7N-gj3w$ ">
>       ...
>     </extension>
>   </extensions>
>
> * Lastly, the draft states that reports have two primary sections, one with
> descriptive information and the other with row-data for the report. The
> "informative" section is broken into two sub-sections, which are
> report_metadata and policy_published. Would it perhaps be clearer to say that
> there are three main sections rather than two?
> report_metadata and policy_published are subsections of the main feedback
> element along with the record elements holding the row data.
> The schema is clear in this instance, I just wondered if the wording in the draft
> might be improved.
>
> Regards,
> Richard
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!
> !CQl3mcHX2A!SZyg4CQrLEXm4I_qOm-N9qEMlEx-
> YkNnYRm5_S0C6L9rYHWuDoTGAMToQF8p5wahvibu5fFB5w$

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 27 Jan 2022 12:52:25 +0100

Alex,

isn't it time we try and release a version which allows XSD automated validation?

Recall, for example, Matt's suggestions in
https://mailarchive.ietf.org/arch/msg/dmarc/JdRxmT9Aw3HkWM7rr3Av9B3EwRc/

Thank you
Ale

-------- Forwarded Message --------
Subject: Re: [dmarc-ietf] draft-ietf-dmarc-aggregate-reporting-04 feedback
Date: Wed, 26 Jan 2022 01:40:48 +0000
From: Brotman, Alex <Alex_Brotman=[email-masked]>
To: Richard Gray <[email-masked]>, [email-masked] <[email-masked]>

Richard,

_______________________________________________
dmarc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dmarc