Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Per Richard Gray for Aggregate Reporting (from IETF list) #1

Closed
abrotman opened this issue Feb 18, 2022 · 1 comment
Closed

Per Richard Gray for Aggregate Reporting (from IETF list) #1

abrotman opened this issue Feb 18, 2022 · 1 comment

Comments

@abrotman
Copy link
Contributor

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 () specified immediately under the 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.

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

@abrotman abrotman changed the title Per Richard Gray Per Richard Gray for Aggregate Reporting (from IETF list) Feb 18, 2022
@toddherr toddherr transferred this issue from ietf-wg-dmarc/dmarc-draftissues Jul 28, 2022
@abrotman
Copy link
Contributor Author

abrotman commented Mar 9, 2023

Bullet 1 resolved

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant