Forum Discussion
As of February 2021, does EOP/Microsoft now send DMARC aggregate reports?
JeremyTBradshaw - Not yet Jeremy. You found the right User Voice however there is no ETA yet.
MicrosoftThanks all for the details and we have fixed the issue and it is rolling out.
Arindam_ThokderYou have only solved part of the problem. As of this week, the report attachment has been split into multiple lines, but unfortunately you didn't do this for the headers and body, so the entire message is still not RFC compliant.
And why do you (UTF8 BASE64) encode the subject and body, even when they do not contain special characters? I process DMARC aggregate reports from more than 3,000 organizations, and all of them (with the exception of Seznam) just use plain text, which makes processing them a lot easier.
- Arindam_Thokderfreddieleeman - we have fixed the base 64 encoding issue by splitting the encoding line of test/html into lines of 78 characters. Could you please have a look.
Arindam_ThokderI found the issue that is causing the Microsoft DMARC reports to fail RFC compliance about 1% of the time (https://www.uriports.com/blog/dmarc-reports-ietf-rfc-compliance/). Sometimes the reports have empty elements for domain and selector DKIM auth results.
RFC7489:
<xs:complexType name="DKIMAuthResultType"> <xs:all> <!-- The "d=" parameter in the signature. --> <xs:element name="domain" type="xs:string" minOccurs="1"/> <!-- The "s=" parameter in the signature. --> <xs:element name="selector" type="xs:string" minOccurs="0"/> <!-- The DKIM verification result. --> <xs:element name="result" type="DKIMResultType" minOccurs="1"/> <!-- Any extra information (e.g., from Authentication-Results). --> <xs:element name="human_result" type="xs:string" minOccurs="0"/> </xs:all> </xs:complexType>The_Exchange_Team Arindam_Thokder, I've located the source of this issue. The empty elements are added when an email is signed with an ed25519 DKIM signature.
- We are processing new reports from Outlook right now (06:20 CET), and the issue has not been resolved.
- The last DMARC aggregate report we've processed was from today (Oct 27) at 11:55 CET, and it still had a base64 encoded text/html part that was not divided into lines of 78 characters. So why would you even base64 this part and the subject anyway?
