ietf-wg-dmarc / draft-ietf-dmarc-aggregate-reporting Goto Github PK

View Code? Open in Web Editor NEW

3.0 12.0 2.0 86 KB

Makefile 100.00%

draft-ietf-dmarc-aggregate-reporting's Introduction

draft-ietf-dmarc-aggregate-reporting

draft-ietf-dmarc-aggregate-reporting's People

Contributors

Stargazers

Watchers

Forkers

kitterma alevesely

draft-ietf-dmarc-aggregate-reporting's Issues

Per Richard Gray for Aggregate Reporting (from IETF list)

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

Report identifier loose ends

keyword_unique-id_msg-id_report_id owner:[email protected] type_defect | by [email protected]

unique-id, msg-id, and report_id are loosely defined.

The spec needs to say that they are semantically the same thing and must have the same content.

In addition:

Message-ID should also be based on unique-id if possible (for example, msg-id@domain-name),
make optional the final part of the Subject:, [Report-ID: msg-id] (like the filename).

Issue migrated from trac:120 at 2022-01-24 16:54:19 +0000

Clarify data integrity needs within DMARC reports

keyword_clarify_report owner:[email protected] type_defect | by [email protected]

The spec needs clarification to be specific about what constitutes valid data in a report.

For instance, to assure one cannot contradict oneself in a DMARC report (i.e. DKIM=fail but DMARC DKIM=pass); while this clarification should not be needed, there are many widely deployed implementations that get some of this wrong.

See: https://mailarchive.ietf.org/arch/msg/dmarc/Ii_dLXFzBNnRP361F922ty789I8/

Issue migrated from trac:40 at 2022-01-24 16:16:04 +0000

XML format: version

type_enhancement | by [email protected]

Note added in http://bit.ly/dmarc-rpt-schema

It is more useful to specify the XML format version using the URI of a spec file, such as http://dmarc.org/dmarc-xml/0.2. Therefore, it is reduntand, useless , and error prone to have a element, which currently stands right at the beginning of the element.

There are several tools that can validate XML syntax based on a specification. To allow automated syntax verification, reports should refer to the schema version in the feedback element namespace, for example, 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.2">
      <report_metadata>
         <org_name>example.com</org_name>
[...]

Issue migrated from trac:33 at 2022-01-24 16:15:35 +0000

Address aggregate reporting XML schema inconsistencies

keyword_clarify_reports owner:[email protected] type_defect | by [email protected]

From https://mailarchive.ietf.org/arch/msg/dmarc/kZI0bytLU9uaMmh4yQB_FTJSKX4/:

"The bottom line is that the RFC 7489 Appendix C is a mess and contradicts
itself numerous times in both schema and comments. I think it's important to
be clearer and stricter about the xml elements and their values. Too much of
this section is open to interpretation. "

For DMARCbis, the reporting XML should be consistent and sanity checked against the above.

Issue migrated from trac:44 at 2022-01-24 16:16:20 +0000

DKIM correctness

keyword_reporting_nit owner:[email protected] type_defect | by [email protected]

The spec is ambiguous about which DKIM key needs to be reported; the aligned key used to determine the DMARC pass/fail status is the one which is needed

See: https://mailarchive.ietf.org/arch/msg/dmarc/9-V596yl2BBaUzCNaDZB1Tg1s4c/

Issue migrated from trac:38 at 2022-01-24 16:15:54 +0000

Define and add NXDOMAIN aggregate reporting

keyword_improve_reports type_enhancement | by [email protected]

Public Suffix Domains might want a special type of reporting limited to NXDOMAINs being used to send email within their zones. One of the ket uses cases being discussed as part of PSD is not just blocking unauthenticated being sent from NXDOMAINs, but being able to gather some data on what exactly is being abused. An NXDOMAIN aggregate report meets this need, and is desirable for operators PSDs.

Issue migrated from trac:60 at 2022-01-24 16:17:32 +0000

Address missing report elements from deprecated drafts

keyword_clarify_reports type_defect | by [email protected]

See: https://mailarchive.ietf.org/arch/msg/dmarc/7QmWbMMEp-TpkjGmDg0wvzhtDuQ/

Issue migrated from trac:45 at 2022-01-24 16:16:23 +0000

Codify ARC reporting in DMARC XML

keyword_clarify_reports owner:[email protected] type_enhancement | by [email protected]

ARC data doesn't have a clean place to live in a DMARC report. Right now, results from ARC are shimmed into a local_policy comment, but this is a text blob. ARC reporting needs a structured schema for data to come back through, and probably a new section of the DMARC report to live within.

Issue migrated from trac:56 at 2022-01-24 16:17:18 +0000

Report field for policy discovery mechanism

Create an optional field in the report that states the policy discovery method: "treewalk"/"psl"

Report-ID syntax in subject line

Section 7.2.1.1. says that the Report-ID is a msg-id. Almost nobody does that. Google uses a long decimal number, Outlook uses a hex number, Fastmail sends a datestamp with dots between the numbers, Yahoo sends two dot-separated numbers in angle brackets, Comcast sends a dash separated string including the domain in angle brackets, AWS sends dash-separated hex numbers in {} braces.

Since the only interesting thing about the report-iD is that it is distinct from other report IDs, I suggest loosening the syntax to agree with reality, except perhaps for the AWS angle brackets.

Fix disposition reporting in aggregate reports

keyword_clarify_reports type_enhancement | by [email protected]

In a DMARC report, a record with a disposition of "none" is confusing and ambiguous (a "none" at p=none is different than a "none" at reject or quarantine) - it may be worth revisiting what is reported in the latter case, and instead reporting "pass"

Issue migrated from trac:51 at 2022-01-24 16:16:54 +0000

Make DMARC reporting extensible

keyword_improve_reports owner:[email protected] type_enhancement | by [email protected]

It should be possible in a DMARC report to define custom authentication attributes (beyond SPF and DKIM) for a report to convey.

This allows for DMARC itself to more extensible, data on new authentication to be gathered, and future needs for DMARC and other authentication mechanisms to be cleanly gathered without needing to build out new mechanisms for reporting.

Issue migrated from trac:65 at 2022-01-24 16:17:50 +0000

Section 7.2 needs ascii art

owner:[email protected] type_enhancement | by [email protected]

it is extremely difficult to decipher the XML in the appendix for the reporting format for somebody who is not intent on implementing the draft. it would be extremely useful to have some ascii art to show the layout of the reporting structure both as an implementer and a more casual consumer of the draft.

Issue migrated from trac:102 at 2022-01-24 16:53:19 +0000