This article provides administrators an overview and instructions on how to create and edit Policy Chains to establish Mail Policy in PGP Universal Server.

 

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.
 

• Policy chains determine how messages are processed. Chains are made up of sequences of rules. A message may pass through more than one policy chain during processing.
  
   
• Rules consists of sets of conditions and actions. Messages pass through the rules in a chain in order until the message comes to a rule that applies. If the conditions for the rule are met by a message, the rule takes effect. If the conditions of a rule are not met by a message, the message is passed to the next rule in the chain.
  
   
• Conditions are the set of requirements a message must meet to trigger a rule. If a message meets the conditions, the associated actions are performed on the message.
  
   
• Groups are sets of one or more conditions, linked together by statements about the Conditions. For example, rule can have a group of conditions that are all required to be true for the rule to be triggered.
  
   
• Condition statements link together conditions into groups, and specify how conditions should be matched. For example, if you have more than one condition in a rule, you can specify that the rule is triggered if all of the conditions are matched, or you can specify that the rule is triggered if only one of the conditions is matched.
  
   
• Actions are processes performed on messages when rule conditions apply. Actions applied to a message may include encryption, virus scanning, or simply passing the message along to another policy chain.
  
   

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.

 

• Default: This is the starting point for the mail policy. This chain specifies how to evaluate all messages and route them to the next appropriate policy chain for processing. All messages start processing here, and are routed to the Inbound, Outbound, or Outbound Virus Scan chains. Because this is the root policy chain for the entire mail policy, it cannot be deleted. The rules in this chain apply to messages processed by both PGP Universal Server and PGP Desktop. 
  
   
• Default: Legacy Client: This policy chain provides mail policy support for 9.0.x legacy client software. This policy chain cannot be deleted.
  
   
• Inbound: This policy chain describes how to process inbound messages to users inside the managed domains. The primary function of this policy chain is to decrypt messages, then drop virus-infected messages and deliver clean messages to the user. This is the final chain in processing inbound email. Messages are routed to this chain by the Default chain. The rules in this chain apply to messages processed by the PGP Universal Server. 
  
    
• Outbound: This policy chain contains processing rules for email to external users, excluded addresses, and PGP Universal Web Messenger users. The policy chain also requires the encryption of sensitive email. Any email that is not processed according to these rules is passed along to the Outbound: Server Only or Outbound: Client Only chains for further processing. The rules in this chain apply to messages processed by both PGP Universal Server and PGP Desktop.
  
   
• Outbound: Server Only: If the email has not yet been processed and sent, then the final rule in this list completes processing and sends the email. The rules in this chain apply only to messages processed by the PGP Universal Server. 
  
   
• Outbound: Client Only: If the email has not yet been processed and sent, then the final rule in this list completes processing and sends the email. The rules in this chain apply to messages processed by PGP Desktop.
  
   

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.

 

Consider the following when creating policy chains and rules:
 

• When you create a policy chain, organize the policy chains and rules in the correct order.
  
   
• Make sure you understand how to use condition settings, conditions, and actions to create valid rules.
  
   
• Ensure every email type that needs special processing is covered by a rule that applies; for example, confidential email or email to specific recipients.
  
   
• Do not allow email to drop through the end of your policy chains. Make sure that for every message that passes through mail policy, there is a rule with an action that finishes processing by sending, delivering, bouncing, or dropping the email.
   

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.

 

1. Once you have finished creating conditions, click the Actions arrow button to open the Actions card and add actions to the rule.
   
    
2. Next, click the Key Search arrow button to add searchable keyservers to the rule, if necessary.
   
    
3. To see a summary of the entire rule, click the Summary arrow button.

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.