This article provides administrators an overview and instructions on how to create and edit Policy Chains to establish Mail Policy in PGP Universal Server.
|Note: This answer pertains to PGP Universal Server 2.5 - 2.12.0.|
HOW TO: Use Policy Chains to Set Mail Policy in PGP Universal Server
The PGP Universal Server processes email messages based on the policies you establish. Mail policy applies to inbound and outbound email for both PGP Universal Server traffic and email processed by PGP client software. Mail policy consists of multiple policy chains, comprised of sequential mail processing rules, which appear on the Mail Policy card.
The Mail Policy card lets you change the settings of the default mail policy chains, and add and edit policy chains and rules. It allows you detailed granular control of all aspects of mail processing.
If your PGP Universal Server is in gateway placement and your users do not have PGP client software installed, then mail policy will be applied only to messages sent to recipients outside the managed domain. Messages sent from internal users to internal users will not pass through the PGP Universal Server, so the policy will not be applied.
Policies are enforced on the PGP Universal Server with PGP Gateway Email, and at the desktop level with PGP Desktop Email. If your PGP Universal Server is outside the mailflow on your network, mail policy cannot be enforced at the network level. However, you can enforce mail policy on client PGP software. PGP Desktop installations bound to your PGP Universal Server will receive client policy information from that server. Any policy chain marked as applicable to client software is enforced by the installed client application. Even if your PGP Universal Server is not proxying and encrypting email in the mailstream, it is important to create secure mail policy, because PGP Desktop Email receives and enforces policy information from PGP Universal Server.
PGP Whole Disk Encryption and PGP NetShare are not affected by mail policy settings. If your PGP Universal Server is only managing these features, mail policy is not required.
How Policy Chains Work
Mail policy refers to the entire set of chains and rules as a whole. Individual policy chains process different kinds of email; for example, inbound or outbound mail. Each rule in a policy chain is one step in processing a message.
Understanding the Pre-Installed Policy Chains
This section describes the pre-installed policy chains for a new, non-migrated, PGP Universal Server installation. The pre-installed policy chains provide the PGP Universal Server and PGP Desktop with rules for processing email. You can edit any of these policy chains, but you should make sure that you understand each of the processing functions the chains provide before you change them.
|Note: This feature is available in version of PGP Universal Server 2.0, 2.5, and 2.6.|
Creating Valid Chains and Rules
Carefully plan and diagram the entire set of chains and rules before you begin creating mail policy on the PGP Universal Server. Once you have created your mail policy, test it before you implement it in your network.
|Caution: The PGP Universal Server will NOT prevent you from creating chains that contradict each other or make rules invalid.|
Consider the following when creating policy chains and rules:
Using Valid Processing Order:
Within a chain, some rules process email and then pass the email along to other actions or rules for further processing; for example, Scan for viruses. Other rules end email processing; for example, Deliver Message. When constructing a rule or chain of rules, make sure that actions that finish email processing come after the actions that allow continued processing.
The sample policy chain below is an example of invalid processing order. The Scan for Viruses rule is before the Decrypt Message rules, so that virus scanning is done on encrypted email. This means that PGP Universal Server cannot detect infected messages.
Within a rule, processing order is important to actions as well. Make sure that actions that finish processing come after actions that continue processing.
Creating Valid Groups:
It is important to pay attention to how your condition settings work, especially if you have nested groups.
In the example below, for the condition to be matched and the rule triggered, there are two things that must be true. The first condition setting states everything it applies to must be true. The first condition setting applies to a condition statement about the recipient address and to a nested group, both of which must be true. The second condition setting states everything it applies to must not be true. The second condition setting applies to a condition statement about the sender domain, which must not be true.
In other words, it must be true that the recipient address is in the Excluded Addresses: Do Not Sign dictionary, and it must be true that the Sender Domain is not company.com.
Creating a Valid Rule:
The following example shows how to create a valid rule. This sample rule applies to any email with a Sensitivity header sent to anyone in a specific domain.
The condition setting requires that all conditions be true to trigger the action. The first condition that must be true is that the email must be from senders in the company.com domain.The second condition that must be true is that the message header called Sensitivity must be the key word Confidential.
The rule action first sends a copy of the message to an SMTP server for archiving. The second action delivers the message. Notice that the action that finishes processing is last. If the action Deliver message comes first, the rule Send copy to alternate SMTP server cannot be performed.
Using the Rule Interface
The rule interface has a set of arrows and buttons to help you arrange conditions and actions. When you add or edit a rule, the rule interface will display the Conditions card first.
The Conditions Card:
This section describes how to use the interface to create, add, or delete groups and conditions for your rules.
This is what an unselected group looks like. Notice that the group box is blue and the triangle in the upper right corner points away from the condition.
You cannot add conditions to a group until you select the group. To select the group, click the triangle in the upper right corner. The selected group will turn green and the triangle will point toward the condition. You can now delete the group or add more conditions or groups.
To add a condition or group to the selected group, click the Add Condition or Add Group button.
If you click the Add Group button, another group will appear nested inside the group you originally selected.
You can nest up to 10 levels of groups or conditions.
To select a condition, click the arrow at the end of the condition. When the condition is selected, the arrow will point away from the condition and the condition background will be green. You cannot delete a condition until you select it.
To delete a group or condition, select that group or condition and click the Delete button. There must be at least one condition in a rule. If there is only one condition in a rule, you cannot delete it.
The Actions Card:
This section describes how to use the interface to add, delete, and reorder rule actions.
To add or delete an action in a rule, click the Add or Delete icons to the right of the action.
The order in which actions appear is the rule is important. Actions that finish processing must come at the end of a list of actions in a rule. For example, in a list of actions, the Send copy to alternate SMTP server action must come before the Deliver message action in a list.
To change the order of actions in a rule, renumber the action you want to move. All actions will automatically reorder.
The KeyServer Card:
This KeyServer Card allows for addtional Key Servers to be added to the rule to search for keys when applicable. By default, the following are searched: Internal users, External users, and Cached keys from prior lookups.