Validity parameters control the application of a Policy to an email. An Active Policy is applied to emails, and an Expired Policy is ignored by Mimecast. Validity can be controlled manually, and Policies can also be automatically set to expire on a certain date. By default policies are set to apply Eternally.
Policy Validity also allows certain options to be applied to policies e.g. bi-directional policy application, Policy Override, and adding Source IP addresses.
Policy Validity can be used to apply or expire polices that affect email processing on Mimecast. By expiring a Policy so that it does not take effect, the Policy can be retained for future use (as opposed to deleting the Policy, and having to re-create it). The Validity options of a Policy also determine the bi-directionality and Override settings of the Policy, and allow policies to apply based on source IP addresses or ranges.
How do I Use Policy Validity?
By default, when a new Policy is created, the Start and End dates are automatically set to Eternal, which indicates that the Policy is immediately active and is not set to expire. These date fields can be modified so that a Policy can either be active, ready (set to activate in the future), or expire (take no effect).
The validity of a policy is shown using different colored status indicators:
Policy is currently active
Policy starts in the future
Policy has expired
Only active policies are applied when Mimecast processes an email. Open the Policy to set the Validity options:
Clicking this button will either enable (default) or disable the policy your are currently configuring. Allowing for policies to be disabled quickly and easily without the need for backdating or deleting the policy.
Policy expiration date ranges are still honoured, resulting in expired policies becoming disabled.
|Set policy as perpetual (Always On)||Clicking this button will set/change the Start and End Dates of the Policy to Eternal|
|Date Range||This is set to All Time by default. Clicking on the drop-down arrow will launch a Calendar control which allows the Administrator to manually set the Start and End date for the Policy|
An Override changes the order of selection for a list of Policies. When an Administrator needs to force Mimecast to ignore specificity, they can apply the Override option - Mimecast will apply the Policy with the Override before it applies the other Policies.
For example, a new mail server is deployed and is being tested for several days. Instead of removing all the Delivery Routing Policies for the existing mail server, a new Policy with an Override is created, and while testing, email routing is changed to the new mail server. In this way, ad hoc changes can be made to Policies for short term use, without affecting the underlying and long lived Policies.
Another example would be if you wanted to force a Policy to be applied first based on the Source IP address range. In this example, you may have added an Anti-Spoofing Policy to prevent inbound spoofed emails from and to your internal domain. However, you do have legitimate inbound email being generated by a web server, which would appear as spoofed traffic because of the sender address being an internal address. You could then create an Override Policy from Everyone, but then specify the Source IP Addresses and choose not to apply the Anti-Spoofing Policy. This Policy will not apply, unless you choose the Override option, as the From variable of Everyone would be less specific than the spoof Policy which specifies the domain name.
The Override options changes the mechanism for policy selection under the following conditions:
- The Policy selector prepares a list of all policies for the same type that would apply to a particular email. The first scan of this list is to check for Policy Overrides, before performing the specificity checks that would normally apply. At this stage, Mimecast will separate all the policies into Message Header From policies and Email Envelope From policies. Remember, all Message Header From Policies are evaluated before Email Envelope From Policies.
Once the Policy Override is removed, the Policy selection system will return to its normal selection methodology, applying the most to the least specific Policies.
|Bi-Directional||Applies the Policy in the reverse mail flow as well, i.e. when emails are from the To field and are sent to the From field as defined in the policy. An Administrator is able to create one policy that applies to emails traveling both inbound and outbound, rather than having to create two separate policies for the same result. For example: To apply a Policy that will cover inbound (External TO Internal) and outbound (Internal TO External) email, create one policy (External TO Internal) and select the Bi Directional check box.Note: A policy that is set to apply FROM Everyone and TO Everyone achieves the same effect as a bi-directional Policy set to apply FROM Internal TO external.|
|Source IP Ranges||This field is optional and is used to validate the originating IP address. If configured, it will be used in conjunction with the Email From/Email To details. IP addresses should be added in CIDR format and can either be added as an individual host (18.104.22.168/32) or as a network range (22.214.171.124/24). Multiple IP addresses/ranges can be added by listing them one below the next.|
If a Policy is configured with both a specific FROM variable and source IP address, only emails which match both of these properties will trigger the Policy. Alternatively, if you would like to specify only the source IP address, select the FROM variable as Everyone, and enter the desired IP address/range in the Source IP Range field.
|Hostnames||Some policies allow you to enter a list of hostnames to bypass. The policy only applies, when the hostname matches the IP address used by the sending server. We will confirm when this is the case.|