Policies - Configuring 3rd-Party Encryption Solutions

This article describes how to set up Mimecast to work with a 3rd party Encryption gateway to vouchsafe a message's authenticity, confidentiality, integrity, and non-repudiation supported by common encryption standards (SMIME, PGP). For example, you could use the following to secure the inbound and outbound email flow in your environment:

• • • PGP or S/MIME standard public key encryption gateway solutions, for example:
      • SEPPmail
      • Totemo
      • Allgeier julia.mailoffice
      • Ciphermail
      • Zertificon
      • NoSpamProxy
      • Symantec PGP Gateway
    • Echoworx or Egress Switch email encryption software.

In particular, the guide outlines:

• • • How encrypted inbound and outbound email flow works.
    • What policies must be configured to ensure the email flows correctly?
    • How journaling works for email retention and archiving.

This guide doesn't cover the email delivery workflow for unencrypted messages. These messages are transferred directly between Mimecast and your email environment.

Inbound Encrypted Email Workflow

The inbound encrypted email workflow is:

1. The inbound message is received by Mimecast via MX from the sender's email system by either opportunistic or enforced TLS. A Content Examination policy is used to determine if the email is encrypted, based on the presence of the relevant encryption X-Headers or the standard PGP text delimiters in the body.
2. If the relevant encryption indicators are detected by the Content Examination policy, the email is routed to the 3rd party encryption gateway using opportunistic or enforced TLS.
3. The 3rd party encryption gateway decrypts the message and sends it to our outbound smart hosts using enforced TLS.
4. The message is delivered to your email environment using enforced TLS.
5. The user receives the message unencrypted.

Policy Configuration

This section should be read in conjunction with the following pages:

• • • Configuring Delivery Routing Definitions and Policies
    • Configuring a Content Examination Definition
    • Configuring a Content Examination Policy
    • Configuring Content Examination Bypass Policies

A Delivery Routing definition is required with the following configuration:

Field / Option	Value
Hostname	The public IP address or publicly resolvable DNS name of the 3rd party encryption gateway.

A Content Examination definition is required with the following configuration:

Field / Option	Value
Activation Score	1
Word / Phrase Match List	# PGP encryption indicators 1 "Content-Type: application/pgp-encrypted" 1 "application/pgp-encrypted" 1 "application/pgp-signature" 1 "application/pgp-keys" 1 "-----BEGIN PGP MESSAGE-----" 1 "-----BEGIN PGP SIGNATURE-----" # SMIME encryption indicators 1 "Content-Type: multipart/encrypted" 1 "Content-Type: multipart/signed" 1 "Content-Type: application/pkcs7-mime" 1 "Content-Description: signed data" 1 "Content-Description: encrypted data" 1 "application/x-pkcs7-mime" 1 "application/pkcs7-signature" 1 "smime-type=enveloped-data" 1 "smime-type=signed-data"
Scan Message Headers	Enabled.
Scan Message Body	Enabled.
Policy Action	None.
Delivery Route	A previously configured Delivery Routing definition routing messages to the 3rd party encryption gateway.

A Content Examination policy is required with the following configuration:

Field / Option	Value
Select Option	Specify the Content Examination definition configured above.
Applies From	External.
Applies To	Internal.

A Content Examination Bypass policy is required with the following configuration:

Field / Option	Value
Select the Content Definition to Bypass	Specify the Content Examination definition configured above.
Source IP Ranges (n.n.n.n/x)	Specify the IP address of the 3rd party encryption gateway.
Applies From	External.
Applies To	Internal.

Outbound Encrypted Email Work Flow

Outbound email can be encrypted based on the scenarios listed below. In both scenarios, the work flow is similar, but the policy configuration differs. See the Scenario One - Using a Tag and Scenario Two - Specific Domain / Domains section below for full details.

Scenario One: Using an Encryption Tag

Work Flow

The encrypted outbound email work flow when using a tag is:

1. Either:

• • • Users use a specific X-Header (e.g., the confidentiality flag) to trigger encryption.
    • Users add an encryption tag to the email subject or body.

      The tag used must be easy to remember but specific enough to ensure normal email communications aren't affected by the policy being triggered unnecessarily. To help, we recommend enclosing the tag in square brackets (e.g., [Encrypted Email]).

2. The email is delivered to Mimecast by the user's mail server using opportunistic or enforced TLS.
3. Mimecast checks the email for the presence of the encryption tag specified in step 1.
4. If the encryption tag is detected in the email's subject, header, or body, it is delivered to the 3rd party encryption gateway using opportunistic or enforced TLS.
5. Once encrypted, the email is delivered back to Mimecast's outbound smart hosts by the 3rd party encryption gateway for processing.
6. The message is delivered outbound to the external email environment using opportunistic or enforced TLS and DKIM signing. The recipient receives the message encrypted.

Policy Configuration

This section should be read in conjunction with the following pages:

• • • Configuring Content Examination Definitions and Policies.
    • Configuring Content Examination Bypass Policies.

A Content Examination definition is required with the following configuration:

Field /Option	Value
Activation Score	1
Word / Phrase Match List	# This is the tag used to encrypt the email. Change the tag below to the tag used to identify the encrypted email. 1 "[Encrypted Email]" This list must reflect your needs, processes, and environment. It must include the terms and triggers required for your situation.
Scan Subject Line	Enabled.
Scan Message Header	Enabled. This is required in case an X-Header is used to transport the encrypt command.
Scan Message Body	Enabled.
Delivery Route	A previously configured Delivery Routing definition routes messages to the 3rd party encryption gateway.
Policy Action	None.

A Content Examination policy is required with the following configuration:

Field / Option	Value
Select Option	Specify the Content Examination definition configured above.
Applies From	Internal.
Applies To	External.

A Content Examination Bypass policy is required with the following configuration:

Field / Option	Value
Select the Content Definition to bypass.	Specify the Content Examination definition configured above.
Source IP Ranges (n.n.n.n/x)	Specify the IP address of the 3rd party encryption gateway.
Applies From	Internal.
Applies To	External.

Depending on the mail flow intended by your organization, there may be the possibility of message looping. We recommend configuring the 3rd party encryption gateway to either:

• • • Remove the encryption command tag from the subject line, etc.
    • Add an additional post-encryption X-Header to indicate that encryption took place, and evaluate this in the corresponding Content Examination definition.

If this isn't possible, other means of preventing message looping must be evaluated. Capabilities to do these may differ, depending on the encryption gateway technology you use.

Scenario Two: Encryption for Specific Domain/Domains

Work Flow

The encrypted outbound email work flow when using a tag is:

1. Users send an email to a domain requiring encryption.
2. The email is delivered to Mimecast by the user's mail server using opportunistic or enforced TLS.
3. Mimecast detects that the recipient domain or user requires encryption.
4. Mimecast delivered the email to the 3rd party encryption gateway for encryption using opportunistic or enforced TLS.
5. Once encrypted, the 3rd party encryption gateway delivers the email back to Mimecast using opportunistic or enforced TLS.
6. The message is delivered to the recipient's email system using opportunistic or enforced TLS. The recipient receives the message encrypted.

Policy Configuration

This section should be read in conjunction with the following pages:

• • • Managing Groups

We recommend creating a profile group containing the domains and email addresses that require encryption for outbound email. The group can be used by the Delivery Routing policy, thereby negating the need to create a separate Delivery Routing policy for each encrypted domain.

A Delivery Routing definition is required with the following configuration:

Field / Option	Value
Hostname	The public IP address or publicly resolvable DNS name of the 3rd party encryption gateway.

A Delivery Routing policy is required with the following configuration:

Field / Option	Value
Select Route	Select the Delivery Routing Definition created above.
Applies From	Internal.
Applies To	Either specify the: Domain (if you've only one domain requiring encryption). Profile Group (if you've got multiple domains requiring encryption).

See Also...

• • • Connect Application: Setting Up TLS Policies
    • Configuring Secure Receipt Policies
    • Configuring Secure Delivery Definitions and Policies
    • Maximum Retention Settings – Technical Concepts
    • Retention Adjustments