Inbound Routing and Security Test Cases

Document created by user.oxriBaJeN4 Employee on Sep 18, 2015Last modified by user.oxriBaJeN4 Employee on Mar 27, 2017
Version 12Show Document
  • View in full screen mode

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 of 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 by using the test cases below for the email routing and security elements of the Mimecast service. The tests are the minimum tests required in order 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 your own 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 elements of the service.

 

Inbound Test Cases to Mimecast

 

MAN16: Opportunistic TLS

 

Where it is supported, Opportunistic TLS allows email servers to negotiated 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 DateExecuted ByOverseen By
ActionResult

Verify the policy settings:

  1. Log in to the Administration Console.
  2. Click on the Administration menu item.
  3. Click on the Gateway | Policies menu item.
  4. Click on Secure Receipt in the "Descriptions" column.
  5. Click on the Secure Receipt policy to open it.
  6. 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 that is applied to all inbound email for connections not previously seen by Mimecast. Provided the senders mail server (Message Transfer Agent) complies with best practice guidelines (e.g. RFC compliance), the mail will be successfully delivered.

 

Test DateExecuted ByOverseen By
ActionResult

Verify the policies created for all inbound routes:

  1. Log in to the Administration Console.
  2. Click on the Administration menu item.
  3. Click on the Gateway | Policies menu item.
  4. Click on Greylisting in the "Descriptions" column.
  5. Click on the Greylisting policy to open it.
  6. 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 DateExecuted ByOverseen By
ActionResult

Verify the policies created for each of your internal domains:

  1. Log in to the Administration Console.
  2. Click on the Administration menu item.
  3. Click on the Gateway | Policies menu item.
  4. Click on Anti-Spoofing in the "Descriptions" column.
  5. Click on the Anti-Spoofing policy to open it.
  6. 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 DateExecuted ByOverseen By
ActionResult

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

  1. Log in to the Administration Console.
  2. Click on the Administration menu item.
  3. Click on the Gateway | Policies menu item.
  4. Click on the Scan Definitions menu item from the Definitions drop down menu.
  5. Click on the Scan Definitions definition to open it.
  6. 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 DateExecuted ByOverseen By
ActionResult

Verify the spam scanning policies created :

  1. Log in to the Administration Console.
  2. Click on the Administration menu item.
  3. Click on the Gateway | Policies menu item.
  4. Click on Spam Scanning in the "Descriptions" column.
  5. Click on the Spam Scanning policy to open it.
  6. 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 organizaion. A default attachment set is created during the Mimecast implementation process, and the list of Mimecast best practice dangerous file types are set to be blocked.

 

Test DateExecuted ByOverseen By
ActionResult

Verify that the Attachment Set definition has been created:

  1. Log in to the Administration Console.
  2. Click on the Administration menu item.
  3. Click on the Gateway | Policies menu item.
  4. Click on the Attachment Sets menu item from the Definitions drop down menu.
  5. Click on the Attachment Set definition to open it.
  6. 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 they can also be used to 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 DateExecuted ByOverseen By
ActionResult

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

  1. Log in to the Administration Console.
  2. Click on the Administration menu item.
  3. Click on the Gateway | Policies menu item.
  4. Click on the Delivery Routes menu item from the Definitions drop down menu.
  5. Click on the Delivery Route definition to open it.
  6. If you have more than one MTA for a single messaging environment, ensure that each entry has an Alternate Route defined for redundancy.
  7. If SMTP Authentication is required to submit messages to your MTA, check that the option is enabled and correct credentials 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 they can also be used to 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 DateExecuted ByOverseen By
ActionResult

Verify there are policies for all inbound routes:

  1. Log in to the Administration Console.
  2. Click on the Administration menu item.
  3. Click on the Gateway | Policies menu item.
  4. Click on Delivery Routing in the "Descriptions" column.
  5. Click on the Delivery Routing policy to open it.
  6. 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
  7. If you have multiple Delivery Route definitions, confirm 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

Attachments

    Outcomes