SOLVED

Microsoft DMARC aggregate report SMTP issues

Brass Contributor

Since 2024-02-24 06:46:45 UTC, we've stopped processing Microsoft's DMARC reports. An investigation revealed that the issue stems from Microsoft's email servers, which are transmitting SMTP commands with syntax errors. These errors are leading to the termination of the email communication.

 

Expected:

 

MAIL FROM: <email address removed for privacy reasons>

 

 

Received:

 

MAIL FROM: <email address removed for privacy reasons> XATTRDIRECT=Originating XATTRORGID=xorgid:96f9e21d-a1c4-44a3-99e4-37191ac61848

 

 

Error:

 

SMTP syntax error malformed address: XATTRDIRECT=Originating XATTRORG may not follow <email address removed for privacy reasons>

 

 

Results:

Schermafbeelding 2024-02-29 234922.png

microsoft_dmarc_reports_line_chart_correct_date.png

5 Replies

@freddieleeman 

Don’t know whether you’ve solved this already, and I’m not an SMTP guru. But that looks a valid use of a SMTP Service Extension as defined in RFC5321 section 2.2. And in particular in section 4.1.1.2 with clause:

 

mail = "MAIL FROM:" Reverse-path

                                       [SP Mail-parameters] CRLF

 

But, the use of Service Extensions are negotiated in the EHLO command /response. Are they offering, and your server doesn’t disagree to the extensions?

 

At worst might be best to follow Jon Postel’s dictum and just accept (and ignore) that extra text.

@Alan McFarlane 

 

It's puzzling why Microsoft would activate service extensions for external, third-party email communications.

 

Interestingly, when applying the exact syntax to Microsoft's own MX record, the same response happens:

# telnet microsoft-com.mail.protection.outlook.com. 25
Trying 52.101.8.49...
Connected to microsoft-com.mail.protection.outlook.com.
Escape character is '^]'.
220 DS2PEPF00003514.mail.protection.outlook.com Microsoft ESMTP MAIL Service ready at Mon, 4 Mar 2024 21:56:42 +0000
EHLO example.com
250-DS2PEPF00003514.mail.protection.outlook.com Hello [<ip>]
250-SIZE 157286400
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250 SMTPUTF8
MAIL FROM <email address removed for privacy reasons> XATTRDIRECT=Originating XATTRORGID=xorgid:96f9e21d-a1c4-44a3-99e4-37191ac61848
501 5.5.4 Unrecognized parameter [DS2PEPF00003514.namprd00.prod.outlook.com 2024-03-04T21:57:22.044Z 08DC3C4C0141C86B]

Based on this situation, it seems likely that the domain microsoft.com is also not receiving any DMARC reports from Outlook.com and Enterprise Outlook.

 

What am I missing?

I was thinking there was a way at EHLO for the client to offer extensions, but that seems not to be the case. You’re not sending anything extension side in your response to the EHLO (XATTRDIRECT, etc)?

If your server replies with that error, “501 5.5.4 Unrecognized parameter…”, does their client resend the MAIL FROM without the parameters?

Anyway I’d just have your server ignore parameters after the address in MAIL FROM.

Might be worth asking here to get info from the real experts https://www.ietf.org/mailman/listinfo/ietf-smtp
To clarify, we handle millions of DMARC reports from thousands of organizations, but only Microsoft's DMARC reports (Outlook and Outlook Enterprise) have recently altered their MAIL FROM command, leading to complications. Are you implying that the rest of the internet should make alterations to their SMTP software if they want to receive DMARC reports from Microsoft? Rather than finding workarounds, wouldn't it be more effective for Microsoft to avoid sending these extra parameters in the first place?
best response confirmed by freddieleeman (Brass Contributor)
Solution
As of 2024-03-05 16:36:46 CET, Microsoft has rolled back the changes in their SMTP transmission, and aggregate reports have begun to flow in again. The final SMTP error was recorded at 18:49:37. I haven't found an official statement from Microsoft.
1 best response

Accepted Solutions
best response confirmed by freddieleeman (Brass Contributor)
Solution
As of 2024-03-05 16:36:46 CET, Microsoft has rolled back the changes in their SMTP transmission, and aggregate reports have begun to flow in again. The final SMTP error was recorded at 18:49:37. I haven't found an official statement from Microsoft.

View solution in original post