The "report_metadata" is included in the aggregate reports and should be able to be pulled into the dmarc_failures.csv. Add the org_name, email, extra_contact_info, report_id, begin dates, and end dates.
Motivation and context
Request received from stakeholder to improve the Trustymail reports. The "report_metadata" is included in the aggregate reports and should be able to be pulled into the dmarc_failures.csv.
The DMARC report XML format has a section titled , however, the BOD 18-01 report does not seem to present any of this data, so it is nearly impossible to trace the report back to the source without using a commercial tool like Proofpoint’s EFD as a manual cross reference.
The stakeholder needs the requested report metadata in order to figure out which systems are producing these weird DMARC reports.
Implementation notes
The section report_metadata should include at least the following elements:
org_name: Reporting Organization
email: Contact to be used when contacting the Reporting Organization
extra_contact_info: Additional contact details
report_id: UUID, specified elsewhere
date_range: begin and end dates. Ideally converted to ISO 8601 format and each presented in their own columns.
Acceptance criteria
The dmarc_failures.csv files should include the following:
[ ] org_name
[ ] email
[ ] extra_contact_info
[ ] report_id
[ ] date_range (both beginning as well as end dates)
💡 Summary
The "report_metadata" is included in the aggregate reports and should be able to be pulled into the dmarc_failures.csv. Add the org_name, email, extra_contact_info, report_id, begin dates, and end dates.
Motivation and context
Request received from stakeholder to improve the Trustymail reports. The "report_metadata" is included in the aggregate reports and should be able to be pulled into the dmarc_failures.csv.
The DMARC report XML format has a section titled, however, the BOD 18-01 report does not seem to present any of this data, so it is nearly impossible to trace the report back to the source without using a commercial tool like Proofpoint’s EFD as a manual cross reference.
The stakeholder needs the requested report metadata in order to figure out which systems are producing these weird DMARC reports.
Implementation notes
The section report_metadata should include at least the following elements:
org_name: Reporting Organization
email: Contact to be used when contacting the Reporting Organization
extra_contact_info: Additional contact details
report_id: UUID, specified elsewhere
date_range: begin and end dates. Ideally converted to ISO 8601 format and each presented in their own columns.
Acceptance criteria
The dmarc_failures.csv files should include the following: