Message Tracking - Suspicious Message Structure

This article explains why messages can be held due to Suspicious Message Structure, and is intended for Administrators.

Introduction

If a message is flagged as having a Suspicious Message Structure, it indicates that something about the construction of the message violates the RFCs that define how an email should be formed.
We check for Suspicious Message Structure because such messages could contain dangerous contents, e.g. malware, in the form of attachments.

• Messages that trigger the Suspicious Message Structure check are placed on Administrator hold. This applies to benign as well as dangerous messages with Suspicious Message Structure, as a precaution. 

• An email may be sent to the intended recipient of an email when the message is held due to Suspicious Message Structure, however, only an Administrator can take action as a result of this notification as detailed below. 

• Administrators can release an administrator hold message if they've determined it to be safe. The message cannot be viewed in the End User's hold queue. Once released, the message is delivered to the recipient.

Hold Reasons

Reason	Details
Mail formatting issues.	The email cannot be broken apart, making it hard to parse or view. The contents cannot be identified, so the message is put on Administrator hold. Examples: Opening of a boundary in a message header that is never closed (this is the most common cause). Boundaries are not being set properly. There are multiple parts with the same boundary, confusing the structure. A multipart doesn’t specify a boundary. We've identified part of a message as having an RFC822 structure when it does not and tried to parse it.  Line endings merging headers and malforming part separation.  An unexpected part found in transmission.
Mail format that should not be sent over the internet.	Message that has a WINMAIL.DAT attachment with multiple formatting irregularities. This format is only supported by Microsoft Exchange, as the .DAT file contains formatting components for a specific email client application. The sending server should not allow messages with this formatting to traverse the internet, as not all mail servers can interpret the file. Transport Neutral Encapsulation Format (TNEF) doesn’t cause this. We can parse these messages, or we might convert them, or hold the WINMAIL.DAT file if it fails to convert.
Incorrect encoding of message.	An example of this would be if we had received a message that had been encoded by a system in binary format. This can result in a corrupt email, a corrupt mail folder, or mail program. It’s unlikely that the file will even be usable, and the sender should try to send the message again.
Mimecast part count exceeded.	We allow 250 MIME part counts. Messages exceeding this part count will be held for Suspicious Message Structure. In certain cases, such as when the part count is exceedingly high, we will not process the message at all. It will fail when viewing details in Message Tracking. This is often caused by a very old email chain that has been sent back and forth many times. As such, our recommendation in this case is to start over with the chain. Messages held for this reason are also unlikely to be viewable in most email clients.

Bypass Options

Examples of when you may need to bypass this policy:

• An external sender is sending messages with over 250 attachments or message parts, or they are sending from a Mail Transfer Agent (MTA) that is sending the messages in a Binary format.  
  You can make a Message Passthrough policy that will allow the messages to bypass these particular issues and allow the message through to the recipient.
• Messages with Suspicious Message Structure check are placed on Administrator hold, but are believed to be safe. You can bypass these by using a Message Passthrough policy.

Please ensure that you have reviewed the Message Passthrough policy article, as using this will prevent Mimecast from adding any tagging to the message.