Message Routing - Inbound Routing

Updated

This article contains information on performing inbound test cases for Mimecast, including recommendations for test execution, remediation re-testing, and implementing Opportunistic TLS to enhance email security.

For more information on Opportunistic TLS, see See Microsoft's article about TLS.

Overview

To route inbound emails to your organization through Mimecast, you must complete the following steps as part of the Connect process:

  • Configuration of a Delivery Route to deliver emails from Mimecast to the organization's infrastructure.
  • Changing MX records to route emails from the internet for your domains to Mimecast.

Once these steps have been completed, you can ensure all emails received by Mimecast are secured by encryption. This can be achieved in the test cases below for the Mimecast service's email routing and security elements. The tests are the minimum tests required to validate the service's core/base functionality and are by no means exhaustive. Customers and partners are encouraged to develop additional test cases to suit their specific email environment requirements.

You can copy/paste this page to a Microsoft Word document to create an editable test plan (including titles and tables).

Recommendations

We recommend that:

  • The test cases are performed in the order presented.
  • Multiple passes of the full test plan are performed to verify the service is functioning as expected.
  • On execution of any remediation activities against failed tests, the entire test plan is re-run. This ensures the changes made have not impacted any other service elements.

Inbound Test Cases to Mimecast

MAN16: Opportunistic TLS

Where it is supported, Opportunistic TLS allows email servers to negotiate encrypted connections, increasing the overall security of your messaging infrastructure. It is highly recommended that organizations implement Opportunistic TLS for all inbound/outbound connections as a default, then implement Enforced TLS where required for specific domains or communications.

Test Date Executed By Overseen By
     
Action Result

Verify the policy settings:

  1. Log in to the Mimecast Administration Console.
  2. Navigate to Policies | Gateway Policies menu item.
  3. Click on Secure Receipt in the Descriptions column.
  4. Click on the Secure Receipt policy to open it.
  5. Verify the policy exists with the following parameters:
    • From: Everyone.
    • To: Everyone.
    • Select Option: Default.
    • Date Range: All Time.
  • PASS (Expected)
  • FAIL
Corrective Action for FAIL Results

Create/update the Secure Receipt policy.

MAN25: Greylisting Policy Configuration

Greylisting is a default compliance check applied to all inbound emails for connections not previously seen by Mimecast. Provided the sender's mail server (Message Transfer Agent) complies with best practice guidelines (e.g., RFC compliance), the mail will be successfully delivered.

Test Date Executed By Overseen By
     
Action Result

Verify the policies created for all inbound routes:

  1. Log in to the Mimecast Administration Console.
  2. Navigate to Policies | Gateway Policies menu item.
  3. Click on Greylisting in the Descriptions column.
  4. Click on the Greylisting policy to open it.
  5. Verify the policy exists with the following parameters:
    • From: Everyone.
    • To: Everyone (or specific domains where applicable).
    • Policy: Apply Greylisting.
    • Validity: Always On.
  • PASS (Expected)
  • FAIL
Corrective Action for FAIL Results

Create/update the Greylisting policy.

MAN26: Anti-Spoofing Policy Configuration

The Anti-Spoofing policy specifically aims at blocking unwanted inbound spoofed emails. For example, an inbound email originating from the internet but displaying the internal domain name and directed to the internal end users.

Test Date Executed By Overseen By
     
Action Result

Verify the policies created for each of your internal domains:

  1. Log in to the Mimecast Administration Console.
  2. Navigate to Policies | Gateway Policies menu item.
  3. Click on Anti-Spoofing in the Descriptions column.
  4. Click on the Anti-Spoofing policy to open it.

Verify the policy exists with the following parameters:

    • From: Internal Domain.
    • To: Internal.
    • Policy: Apply Anti-Spoofing.
    • Validity: Always On.

Repeat the above for every Anti Spoofing policy you require.
  • PASS (Expected)
  • FAIL
Corrective Action for FAIL Results
Create/update the Anti Spoofing policies.

MAN27: Spam Scanning Definition Configuration

As part of the inbound email security checks, Mimecast uses multiple content-based heuristic scanning engines. These examine the content of emails, looking 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.

Test Date Executed By Overseen By
     
Action Result

Verify all the spam scanning definitions have been created to suit your requirements:

  1. Log in to the Mimecast Administration Console.
  2. Navigate to Policies | Gateway Policies menu item.
  3. Click on the Scan Definitions menu item from the Definitions drop-down menu.
  4. Click on the Scan Definitions definition to open it.
  5. Verify the definition exists with the following parameters. These are the default and recommended settings:
    • Spam Detection Level: Relaxed.
    • Spam Detection Action: Hold for Review.
    • Enable Bulk Mail Filtering: Disabled (enable to stop Newsletters).
    • Hold Type: User.
    • Notification Options: All Disabled.
      Enabling will result in notification for every message triggering the policy in almost real time.

Repeat the above for every scan definition you require.
  • PASS (Expected)
  • FAIL
Corrective Action for FAIL Results

Create/update the Scan Definition.

MAN28: Spam Scanning Policy Configuration

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

Test Date Executed By Overseen By
     
Action Result

Verify the spam scanning policies created :

  1. Log in to the Mimecast Administration Console.
  2. Navigate to Policies | Gateway Policies menu item.
  3. Click on Spam Scanning in the Descriptions column.
  4. Click on the Spam Scanning policy to open it.

Verify the policy exists with the following parameters:

    • From: Everyone.
    • To: Internal.
    • Policy: Relaxed Spam Detection (Recommended).
    • Validity: Always On.

Repeat the above for every Spam Scanning policy you require.
  • PASS (Expected)
  • FAIL
Corrective Action for FAIL Results

Create/update the Scan Policies to suit your requirements.

MAN29: Attachment Sets Definition Configuration

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 and can be used to configure what attachment types should be allowed, blocked, linked, or held when being sent outbound from or inbound to your organization. A default attachment set is created during the Mimecast implementation process, and the list of Mimecast best practice dangerous file types is set to be blocked.

Test Date Executed By Overseen By
     
Action Result

Verify that the Attachment Set definition has been created:

  1. Log in to the Mimecast Administration Console.
  2. Navigate to Gateway | Policies menu item.
  3. Click on the Attachment Sets menu item from the Definitions drop-down menu.
  4. Click on the Attachment Set definition to open it.
  5. Check the list of attachment types that should be blocked.
  • PASS (Expected)
  • FAIL
Corrective Action for FAIL Results

Create/update the Attachment Set definition to suit your requirements.

Inbound Test Cases to my Environment

MAN23: Delivery Route Definitions

Delivery Routes are used to deliver emails from Mimecast. This is typically inbound to your local infrastructure, although it can also override MX records for outbound delivery. Delivery Routes contain the details of the delivery destination (e.g., Host Name, email server IP Address). Mimecast's flexible routing policies allow emails to be delivered to a specific server based on a domain, group, attribute, or individual address.

Test Date Executed By Overseen By
     
Action Result

Verify that an entry exists for each MTA that should accept email for your email environment:

  1. Log in to the Mimecast Administration Console.
  2. Navigate to Policies | Gateway Policies menu item.
  3. Click on the Delivery Routes menu item from the Definitions drop-down menu.
  4. Click on the Delivery Route definition to open it.
  5. If you have more than one MTA for a single messaging environment, ensure that each entry has an Alternate Route defined for redundancy.
  6. If SMTP Authentication is required to submit messages to your MTA, check that the option is enabled and the correct credentials are provided. This is not a common configuration.
  • PASS (Expected)
  • FAIL
Corrective Action for FAIL Results

Create/update the Delivery Route definitions.

MAN24: Delivery Route Policy Configuration

Delivery Routes are used to deliver emails from Mimecast. This is typically inbound to your local infrastructure, although it can also override MX records for outbound delivery. Delivery Routes contain the details of the delivery destination (e.g., Host Name, email server IP Address). Mimecast's flexible routing policies allow emails to be delivered to a specific server based on a domain, group, attribute, or individual address.

Test Date Executed By Overseen By
     
Action Result

Verify there are policies for all inbound routes:

  1. Log in to the Mimecast Administration Console.
  2. Navigate to Policies | Gateway Policies menu item.
  3. Click on Delivery Routing in the "Descriptions" column.
  4. Click on the Delivery Routing policy to open it.
  5. Verify the policy exists with the following parameters:
    • From: Everyone.
    • To: Internal (or specific domains where applicable).
    • Policy: Appropriate Delivery Route Selected.
    • Validity: Always On.
  1. If you have multiple Delivery Route definitions, confirm that either of the following is present:
    • A single policy for fail-over routing configuration.
    • One policy for each definition for active/active routing configuration.
  • PASS (Expected)
  • FAIL
Corrective Action for FAIL Results

Create/update the Delivery Route policies.

Related to

Was this article helpful?
0 out of 1 found this helpful

Comments

0 comments

Please sign in to leave a comment.