Default Connect Policies

Document created by user.oxriBaJeN4 Employee on Sep 23, 2015Last modified by user.oxriBaJeN4 Employee on Apr 10, 2017
Version 14Show Document
  • View in full screen mode

This guide outline the default policies created during the Connect process. For ease, they are split between those relevant to your inbound, outbound, and both inbound and outbound email flow.

You may not have all the policies mentioned below. The implemented policies are dependent on the Mimecast service you've purchased.

Applies To...

 

  • Administrators on Mimecast accounts that have gone through the Connect process.

 

Inbound Email Flow

 

Spam Scanning

 

See the Creating / Changing a Spam Scanning Definition and Configuring Spam Scanning Definitions and Policies pages for further details.

 

As part of the inbound email security checks, Mimecast uses multiple content based heuristic scanning engines. These examine the content of messages to look for key phrases, and other identifiers commonly used by spammers. These include content matching rules, DNS based definitions, checksum based definitions, and statistical filtering definitions.

 

The aim of Mimecast’s initial layers of defense, is to reject unwanted spam and malware messages in protocol. However there are occasions where Mimecast cannot determine if a message is wanted by the end user of not (e.g. promotional notifications, newsletters or advertisements). In such scenarios, you can configure spam scanning to check the content of all inbound email.

 

Spam scanning can be configured to apply to different levels of sensitivity and actions, should the policy be triggered. If an email address, domain name or IP address is added as a Permitted Sender, either on the customer account or globally, the inbound message will always bypass these content based spam checks, but virus scanning will still apply.

 

Greylisting

 

See the Configuring Greylisting Policies page for further details.

 

Greylisting looks at three pieces of information (which we will refer to as a "triplet" from now on) about any particular email delivery attempt:

  • The IP address of the host attempting the delivery.
  • The envelope sender address.
  • The envelope recipient address.

 

With this triplet, Mimecast has a unique relationship for that particular SMTP session. If we have never seen this triplet before, we issue a server busy status (451 Internal resource temporarily unavailable). This server busy status is maintained for 60 seconds, forcing the sending server to queue and retry. This is a 400 message (temporary error) and not a 500 message (permanent error). A correctly configured Message Transfer Agent (MTA) will attempt retries, if given an appropriate temporary failure code for a delivery attempt.

 

If the message comes back after 60 seconds, and before the 12 hour upper limit, the message will be not be subjected to further greylisting. If the message is not retried within this 12 hour period, an entry is logged in the Rejection Viewer as “Sender Failed to Retry” (12 hours after the initial attempt). If the message returns after 12 hours, the greylisting process starts again. An Exchange server, by default, will retry email every ten minutes up until a certain point. Greylisting is applied to all inbound email by default.

 

Anti-Spoofing

 

See the Configuring Anti-Spoofing Policies page for further details.

 

This policy is used to avoid spoofing. The policy is configured to apply anti-spoofing to email from your domain, to your domain. When configuring this policy, administrators should ensure they don’t have external clients that send email appearing to be from the internal domain, to internal users.

 

Permitted Senders

 

See the Configuring Permitted Senders Policies page for further details.

 

If a permitted senders policy applies to a message, it is passed through the system without the application of any additional spam checks.

A permitted senders message is still subject to system wide message compliance and virus checks. Adding an address to the permitted senders list, just removes the message from additional spam checks.

Auto Allow

 

See the Configuring Auto Allow Policies page for further details.

 

Auto allow lists produce the same result as a normal permitted senders list, which is the bypassing of spam checks. The policy asks Mimecast to review its sender / receiver database, to determine if an internal email sender has sent a message to the address from which a new message is arriving. This policy is used to build individual auto white list.

In general, the auto allow policy is set to apply from "Everyone" to "Everyone". The policy system offers flexibility for auto allow policies to only apply in certain cases, but the "Everyone" to "Everyone" is the most common application.

Auto allow policies bypass greylisting policies and spam scanning policies for known senders.

 

Digest Sets

 

See the Creating / Changing a Digest Sets Definition and Configuring Digest Sets Definitions and Policies pages for further details.

 

Mimecast will automatically create a digest set definition and policy.

 

Delivery Routing

 

See the Creating / Changing a Delivery Routing Definition and Configuring Delivery Routing Definitions and Policies pages for further information.

 

Delivery routes determine the route to be used for inbound email delivery. By default, outbound emails will be delivered to the recipient using available MX records. However if an outbound delivery route has been configured, this would override the MX record. Delivery routes require the specific route to be configured, and a policy to determine the flow of traffic. Alternate routes can also be created. This enables a failover option, should a customer’s primary route be unavailable. If multiple similar routes (the FROM and TO variables are the same) are configured, this results in a round robin (random selection) of these routes. This is also useful to balance mail server load.

 

Delivery routes contain the details of the delivery destination (e.g. the host name or IP Address of the email server). Mimecast’s flexible routing policies allows email to be delivered to a specific server based on a domain, group, attribute, or individual address.

 

DNS Authentication: Inbound Check

 

See the DNS Authentication - Inbound Checks page for further information.

 

DNS authentication is helpful in preventing unwanted and potentially harmful messages from reaching users. When enabled, inbound DNS authentication checks are performed against all messages regardless of any auto allow or permitted sender entries. The following actions can be applied depending on the result of the inbound checks performed:

  • Reject
  • Ignore managed / permitted sender entries
  • Take no action

 

By default, inbound DNS authentication policies are configured to ignore managed or permitted sender entries when a failure result is return by the SPF, DKIM, and DMARC checks that are performed. This means that should one of the configured checks fail, the message will be subject to reputation and spam checks.

 

Outbound Email Flow

 

Stationery Assignment

 

See the Creating / Changing a Stationery Layout and Configuring Stationery Layout Definitions and Policies pages for further details.

 

By default, a disclaimer will be applied for all outgoing email. The following examples show a couple of regional variations of this content:

 

Example 1 (UK & US):

 

"This email message has been delivered safely and archived online by Mimecast. For more information, please visit http://www.mimecast.com"

 

Example 2 (South Africa):

 

"The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

 

This email has been scanned for viruses and malware, and automatically archived by Mimecast SA (Pty) Ltd, an innovator in Software as a Service (SaaS) for business. Mimecast offers email continuity, security, archiving and compliance with all current legislation. To find out more, contact Mimecast."

 

Message Actions

 

See the Configuring Message Actions Policies page for further details.

 

A message actions policy is used to control usage features for Mimecast for Outlook, in conjunction with your Application Settings.

 

Inbound and OutBound Email Flow

 

Attachment Sets

 

See the Creating / Changing an Attachment Set Definition and Configuring Attachment Management Definitions and Policies pages for further details.

 

Most malware is hidden in attachments. As such, it is important to restrict what attachments are allowed in and out of your environment. Attachment sets provide a list of attachments, that can be used to configure what file types should be allowed, blocked, linked, or held when being sent outbound or inbound into your Mimecast account. A default attachment set is created during the Connect process. It uses Mimecast's best practice dangerous file types, all of which are set to be blocked.

 

Attachment handling can also be applied to assist in reducing bandwidth and resource abuse by users. The largest part of a message is always the attachment, so enabling restrictions to attachments will assist with efficiency levels with regards to email processing and storage.

Attachment set policies are available on specific Mimecast subscriptions.

Blocked Senders

 

See the Configuring Blocked Senders Policies page for further details.

 

Blocked senders policies are almost identical to anti-spoofing policies, but they are applied to all types of email: inbound and outbound.

It is more efficient to create a blocked sender policy against a profile group, and to maintain all suspect email addresses and domains into that profile group.  This means that any number of specific email domains or email addresses can be blocked, without the need to create a new blocked sender entry for each offending domain or address.

A policy from "EXTERNAL" to "EXTERNAL" is created by default to prevent open relay out to another external environment. You cannot make changes to this policy. A new blocked senders policy can be created to override aspects of the default policy, but you cannot configure an additional "EXTERNAL" to "EXTERNAL" blocked senders policy.

 

If you wish to allow external email to relay to another email address, you can add this address to the relay folder under Directory | Directory Groups | Relay (commonly used when forwarding from exchange to external contacts). There is a policy in place for this that is assigned to a relay folder.

 

Email Size Limits

 

See the Configuring Email Size Limits Policies page for further information.

 

By default, the maximum acceptable size is 100 MB for legacy gateway customers, and 200 MB for customers utilizing the latest gateway.

 

Suspected Malware

 

See the Configuring a Suspected Malware Definition and Configuring Suspected Malware Definitions and Policies pages for further information.

 

Email containing the following file types in a ZIP file, are held in the hold review queue and marked as suspected malware:

  • EXE
  • COM
  • PIF
  • SCR
  • CPL
  • MSI

 

Encrypted ZIP files are not affected by this system. The intended recipient receives a notification, and will need to ask their administrators to release the message. This system works independently of any attachment management policy that you may have created, and can be bypassed via a suspected malware bypass policy  We do not recommend that you implement such a policy, as it means new virus outbreaks might go undetected while signatures are being updated. This ensures comprehensive protection to all customers regardless of their individual settings.

 

The default suspected malware definition and policy are implemented by default for all inbound emails.

 

Archive Limit Reached / Archive Extract Error

 

See the Configuring Message Passthrough Policies page for further details.

 

Archived limit reached means that one of the following limits has been reached:

  • 5 levels of .ZIP file recursion.
  • 10,000 files per .ZIP file.
  • Maximum unpacked file size 100 MB.
  • Total maximum unpacked size 2GB.
The "Archive Extract Error" gets thrown for unsupported .ZIP files (e.g. .ZIPX).

As the platform was not able to correctly extract the archive it couldn’t be examined against your policies and definitions. The message is automatically placed in the on hold queue, allowing you to examine it and take appropriate action.

 

To allow such items to be received without being placed on hold, configure a Message Passthrough Policy. This stops the platform from examining the communication, and policies configured for particular components of a message no longer apply. We recommend that you configure the message passthrough policy to be as specific as possible. For example:

  • Policy Options: Do not explode message content.
  • Applies From: Individual email address.
  • Specifically: Enter the sender email address.
  • Applies To: Individual email address or domain.
  • Specifically: Enter the recipient email address or domain

 

Suspicious Message Structure

 

See the Suspicious Message Structure page for further details.

 

Items placed in the hold review queue due to “Suspicious Message Structure”, indicate the message has not been correctly structured, based on RFC822 and RFC1123 (Request for Comment) documents published by the Internet Engineering Task Force. Mimecast provides extensive checking based on the structure and make up of these messages to prevent any malicious or dangerous email from entering a mail environment. Although it is common that many mail servers and clients do not conform to the RFC standards, we are flexible on the format we accept, and hold only the problematic instances. The notification the recipient receives is similar to the following:

 

This is a content alert notification message.

 

The message indicated below matches content alert policies set by the system Administrator(s).

 

Message information:

 

Sender : sending address

 

Intended Recipient : recipient address

 

Message Subject : subject

 

Message Date : date and time

 

Message Status : The message has been placed on HOLD - action required

 

Content Policies Triggered:

 

- This message is badly structured and may contain dangerous content

 

Some of the reasons for messages being placed in the hold queue “Suspicious Message Structure” can be the following:

 

Incorrect encoding of message

 

An example 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, mail folder on the recipient's mail folder, or mail program. It’s unlikely that the file will even be usable, and the sender should try and send the message again.

 

See the http://msdn.microsoft.com/en-us/library/ms527563.aspx page on the Microsoft website for further details.

 

Mail format that should not be sent over the internet

 

An example 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 file contains formatting components for a specific email client application. The sending machine should not allow messages with this formatting to traverse the internet, as not all mail servers can interpret the file.

 

To get around the above issue, Microsoft recommends the following actions on their website:

 

Messages that are placed in the hold for review queue and subsequently determined to be safe, can be released so by carrying out the following actions:

  • Select the message in question and proceed by clicking on “Release Selected Items”.
  • If the sending party can't resolve the issue on their end, you can prevent these messages from being placed on hold by configuring a Message Passthrough Policy.

 

The policy should be set up with:

  • Policy Options: Do not explode message content.
  • Applies From: Individual email address.
  • Specifically: Enter the sender email address.
  • Applies To: Individual email address or domain.
  • Specifically: Enter the recipient email address or domain

 

Application Settings

 

See the Application Settings page for further details.

 

An application settings definition is enabled for all internal users, and provides access to all Mimecast user tools. This default definition cannot be edited, but additional definitions can be created to apply to specific user groups.

 

See Also...

 

1 person found this helpful

Attachments

    Outcomes