Just wondering if anyone has come across emails being parsed with the body coming up as NULL even though it has content.
We have M365 email alerts configured to deliver to the mailbox and specific emails are not presenting correctly.
Some emails with this issue are the ones titled:
“New vulnerabilities notification from Microsoft Defender for Endpoint”
these just show the body as being NULL so we can’t interrogate against the body of the email.
Other emails from Defender (with the same From address) do pass through the content of the body to the parser:
Example:
“High severity alert: Process memory dump on **********”
This allows us to identify the device name and the vulnerability directly from the body of the email.
I’m intrigued. This example you sent is clearly parsed by MSPintegrations with an empty body (both plaintext and HTML). When I view the original .eml file, I can see the contents, and when I download the .eml and open it in my mail client, I can see content.
We’ll be digging into this to get an answer. I’m convinced it’s something on our end, but I don’t yet know what it is.
In this email, there is an extra line after the content-type with extra information that should’t be there. I’ve redacted a bunch of info in this screenshot, but I think you get the idea. All of text in line 121 should not be there.
Background info: Email header lines that are too long wrap by being included on the next line and indented. In this example, lines 120 and 121 are part of the content-type header. The text in line 121 isn’t valid for the content-type.
When I remove line 121, MSPintegrations parses your email correctly.
How is this email being routed before it hits MSPintegrations? It looks like it might be forwarded through your customer’s Office 365 account as well as be scanned by Hornet Security. If you are able to send it more directly (even temporarily), I am curious if the content-type line comes through correctly and if MSPintegrations can then parse it correctly. I suspect that an intermediary email server may be causing some issues.
Let me know if you’re able to do any other testing and what you find.
We get all emails sent to our domain which then re-directs it to the MSP Integration Mailboxes.
I will add the MSP Integration Mailboxes as a recipient for the alerts but I don’t know when the next alert will be generated - although they are fairly regular.
I will let you know when it creates the next ticket.
I can see the message that was sent directly to MSPintegrations had the correct content-type header with no extra information:
This is good news and bad news. The good news is that the original email, when submitted directly to MSPintegrations, is not garbled. The bad news is that we don’t know what system is messing up the headers.
At this point, it will take trial and error to remove each “hop” of the email to see which hop is causing trouble.
But before you do that, I wonder if it would simpler to use an MSPintegrations Remote Mailbox instead of a Hosted Mailbox. Do you have access to the very first system to which this email is sent? If so, you can create a Remote Mailbox in MSPintegrations to poll that mailbox and retrieve the message before it’s forwarded. If that happens to be before the system that’s garbling the header, then this would fix the issue.
Best to leave it with me.
I will probably just get the emails delivered directly to the MSPIntegrations mailbox and use the text in the email to identify the tenant.
Our normal method is to get emails sent to the client domain, which redirects to our tenancy which in turn redirects to MSPIntegrations.
The beauty of this method is that we can generally use the To[0] address to identify the customer’s account.
However, these particular emails can have the organisation name in the email so we should be able to use that in the parser instead - might need to use a UDF in AutoTask to match the exact name.
You might consider using a regular expression mailbox in MSPintegrations for this. You can create an email address in our system to receive emails to [email protected], where XYZ is a wildcard that accepts any customer abbreviation.
The mailbox logic would then query Autotask for the account XYZ and create a ticket.
The great part about this setup is you only need one MSPintegrations mailbox with one rule. When you onboard a new customer, you just need to ensure the account is set up correctly in Autotask. You don’t need to add anything to MSPintegrations, you don’t need to set up any aliases or mailboxes or forwarders on the customers’ email servers. This mailbox would effectively give every Autotask account a direct email address to create tickets.
If this is interesting to you, I’ll be happy to write up more specifics if you need that.
