Mimecast Security Systems

What are the Mimecast Security Systems?

When Mimecast processes an inbound email, certain checks and scans are performed to ensure that only legitimate emails are accepted.  Part of this processing includes Mimecast’s proprietary ARMed SMTP (Advanced Reputation Management), which helps to make inbound email scanning more efficient and effective by looking at the reputation of the sending IP and email address.  Mimecast uses a combination of Policies, reputation checks, anti-spam and virus systems to detect, and if necessary, reject any unwanted emails.

Why use the Mimecast Security Systems?

There are many types of malware that could target your environment, and cause theft of data, irritation, loss of productivity, and other immeasurable losses.  Mimecast provides a series of checks for all inbound email to prevent spam and malware.  The order of these checks is significant, as it will assist you when troubleshooting delayed or failed inbound and outbound emails.

The following flow-chart shows the various steps involved in processing an inbound email, with a brief explanation of each point below:

1.          Inbound lockout Policy:

This Policy blocks spoof attempts. In this way, if a spammer falsifies their sending address to masquerade as an internal domain address, Mimecast will reject the email.

2/3.     Blocked Senders Policy:

This includes both those block entries created by the Administrator and those created by individuals. These Policies reject the connection, and as with all other rejections, the connection is dropped in protocol.  This means that the email data cannot be released/retrieved, as it is not present in Mimecast.

4/5.     Permitted Senders Policy:

Again these include global and individual Permit Policies.  Permitted Sender Policies will bypass all spam checks (reputation-based and content-based), but not anti-virus checks. If an email address or domain is in both the Permit and Block Policy, as the Blocked Senders Policy is applied first, the email would be rejected.  For example, an end user may have Permitted an email address, but the Administrator has Blocked that entire domain at a global level. In this case, the email would have the Block Policy applied first, and so be rejected.

6.       Auto Allow Policy:

When an internal user sends an email outbound, Mimecast captures the recipient’s email address, and adds it to a database known as Auto Allow. When this recipient then sends an email inbound to the Mimecast user, Mimecast checks against this database, and if a match is found, the inbound email will be allowed through without applying additional spam reputation checks and content checks – similar to a permitted sender (virus checks are still applied).

7.       IP reputation checks:

a.         Real-time Blackhole List (RBL) are applied next. RBL’s contain the IP addresses of known malware senders. Mimecast uses its own Real-Time IP Block List, along with 3 other commercial DNS RBL’s.

b.        The other IP reputation check functions as a global network outbreak detection system, which allows Mimecast to be the first responder to many malware threats, both known and unknown. This reputation service temporarily defers connections if they are suspected to have a bad reputation.

Note that IP Reputation checks are bypassed by the Auto Allow and Permitted Sender Policies.

8.       Greylisting:

Compliance checks are applied to the sender’s mail server for all connections not previously seen before by Mimecast. Mimecast gives a busy signal, which prompts the sending server to retry the email delivery after 1 minute.  If the sender’s mail server retries the connection, the email is processed. If the email is not retried within 12 hours, the email connection is dropped and rejected.

Note that Greylisting is bypassed by the Auto Allow and Permitted Sender Policies.

9.       Recipient validation:

Recipient validation is used to prevent inbound emails with invalid recipient addresses. To be effective, spammers send out numerous emails, most of which are guessed or a result of directory harvesting.   

Mimecast uses different types of recipient validation, and this is configured against each domain in Mimecast.

10.   Next the emails are moved to the scanners.

a.         Spam scanning: Mimecast uses multiple content-based, heuristic scanning engines. These engines examine the content of emails, and look for key phrases and other identifiers commonly used by spammers. These include content-matching rules, and also DNS-based, checksum-based and statistical filtering definitions. Depending on the policy configured, if a match is found, the email is held for review.

Note that spam scanning is bypassed by the Auto Allow and Permitted Sender Policies.

b.        Virus scanning: Mimecast uses its own proprietary software, as well as market leading Commercial software, providing malware protection software with combined intelligence gathered from the millions of commercial and freeware users. Mimecast’s engines combine signature and heuristic malware detection technologies.  These detection systems work on-the-wire, which also allows Mimecast to shut off viral and intrusive transmissions early. Any email which matches a malware signature will be rejected.

11.   Content Policies:

If Content Policies have been configured, emails are then scanned for any text matches. Content Policies can be configured to scan the content of an email for a word, phrase or combination thereof. Matches can then be held for review, encrypted or sent using Mimecast’s secure mail (CCM – Closed Circuit Messaging).   

12.   Attachment scanning:

Attachment Policies are configured to look for certain attachment types and sizes. If found, the following actions can take place:

a.         Hold for Review:  Email delivery is interrupted, and a Notification or a Digest is sent to the recipient.  

b.         Deny (strip): Removes the attachment from the email, but delivers the email to the recipient.  The email content is modified to include a note on the details of the attachment that has been denied.  The user is able to contact the Administrator to have the attachment released, if necessary.

c.          Strip and Link: The attachment is removed from the email, and is replaced with an FTP download link within the body of the message.  The user has the ability to download the attachment using the FTP link.

During these checks, any email that matches a security Policy will be rejected in protocol. Any scanning engine match may be sent to the Hold Review Queue, or if it is an attachment, this may be stripped. Ultimately, emails that pass all these checks will be accepted, and moved to the Delivery Queue for final delivery to the recipients mail server.