This guide describes how to configure a reputation definition that can be applied to a reputation policy.
- Administrators responsible for configuring definitions and policies.
You do not have to create a reputation definition as, by default, all block lists and reputation checks are applied to inbound emails with a count of 1. However reputation definitions provide administrators with granular control over the reputation based spam detection technologies we use as part of the default security stack. For example, some of these checks can be excluded, or their sensitivity decreased. You can:
- Deactivate one of the default block lists to ensure that certain messages are allowed through.
- Apply stronger hit rates before a message is rejected based on reputation.
To configure a reputation definition:
- Log in to the Administration Console.
- Click on the Administration menu item.
- Click on the menu item.
- Click on the button.
- Click on the Reputation Definition menu item. Any existing definitions are listed.
- Click the button to create a definition
- Click on the definition to be changed.
- Complete the Reputation Properties section as follows:
Field Description Description Specify a name for the definition to enable you to identity it's purpose. Mimecast Global Permitted List
If selected, the connecting IP address of all inbound email is checked against an permit list maintained by our Security Team. This list comprises domains known to be of good reputation. If the connecting IP address is on the permit list, it bypasses spam checking.
Global Block Lists If selected, all inbound email is checked for spam against six IP address based block lists. This option is used in conjunction with the "Number of Block List Hits" option. Number of Block List Hits
Specify a value to set the number of hits required before the sending IP address of a message is rejected.
- Select the Save and Exit button.
Example Use Cases
Example 1: IP Address on Two or More Block Lists
In this example, messages are rejected when the IP address is found on a minimum of two block lists, and the policy applies to emails from "Everyone to Internal":
Example 2: newsletter.com on all Block Lists
In this example, we deactivate the Mimecast Global Permitted List for newsletter.com, with a requirement that the sending server of the mail for newsletter.com is found on all block lists. In this example, the policy is set to apply to emails from newsletter.com to "Internal".