Any messages that trigger the suspicious message structure check are sent to the Hold Queue. Additionally, an email notification is sent to the intended recipient of the email. For example:
This is a content alert notification message.
The message indicated below is badly structured and could not be fully examined.
These notifications can be customized to include customer specific details (e.g. Helpdesk telephone number for releasing held emails).
Below are some of the reasons for messages being placed in the Hold Queue because of "Suspicious Message Structure": For more details, see the MSDN website.
- Mail format that should not be sent over the internet: An example of this could be a message that has a WINMAIL.DAT attachment with a number of formatting irregularities. This format is only supported by Microsoft Exchange, as the .DAT ﬁle contains formatting components for a speciﬁc 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 ﬁle.
- Incorrect encoding of message: An example of this would be if we have received a message that has been encoded by a system in a binary format. This can result in a corrupt email, a corrupt mail folder, or mail program. It’s unlikely that the ﬁle will even be usable, and the sender should try and send the message again.
- Suspected Malware Detection interrogates emails with .ZIP file attachments for certain file types (e.g. .EXE, .MSI) and if detected a notification is sent to the intended recipient, and the email is placed in the Administrator Hold Queue. This detection works independently of any Attachment Management policy configured for your account, and ensures comprehensive protection for all Mimecast customers regardless of their individual settings.
Messages placed in the hold queue that are subsequently determined to be safe, can only be released by an administrator and cannot be viewed in the end user's hold queue). Once released, the message is delivered to the recipient.
Below is an example of when you may need to bypass this policy.
If the sending party cannot resolve the suspicious message structure issue on their end and you want to prevent these messages from being held, you can configure a Message Passthrough policy. For example, if your organization is developing software with an external vendor, and is using .EXE files for updates. The Passthrough policy will allow the files to be delivered to the internal user as intended, instead of applying a Hold action. This should typically only be created after testing with Mimecast Support has been completed.
We advise using a message bypass policy with caution, as it could allow a new virus outbreak to go undetected whilst signatures are being updated. It may also negate the Mimecast Virus Service Level Agreement.