Forum Discussion
Microsoft DMARC aggregate report SMTP issues
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:
- 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.
- freddieleemanBrass ContributorAs 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.
- Kiska87Copper Contributoremail address removed for privacy reasons
- Alan_McFarlaneIron Contributor
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.
- freddieleemanBrass Contributor
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?
- Alan_McFarlaneIron ContributorI 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