Creating Policy Chains to Set Mail Policy in PGP Encryption Server (Symantec Encryption Management Server)
Article ID: 180151
Updated On:
Products
Issue/Introduction
Symantec Encryption Management Server, or the PGP Server, has the capability to encrypt and decrypt emails automatically when placed in the mailflow. It can then process mail based on a plethora of logic that can address just about any situation.
The way the PGP Encryption server evaluates the rules is by Chains and Rules inside of the Chains.
The "Chains", which handle the scenario of the email, such as if an email is inbound, or if an email is outbound, will then contain all the rules to process the mail.
The "Rules" are configured in these Chains and will take action based on conditions to be configured.
There are many different ways to configure these Chains and Rules. This article goes over the basics of this functionality and provides administrators an overview and instructions on how to create and edit Policy Chains for the PGP server.
For information on headers that are used for encrypted content, which can be handy when working with these rules, see the following article:
Resolution
The PGP Encryption Server processes email messages based on the policies you establish. There are a set of default rules, and then you can customize most of the rules to meet your individual needs.
Mail policy applies to inbound and outbound email for both PGP Server traffic and email processed by PGP Encryption 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 Encryption Server is in gateway placement and your users do not have PGP Encryption 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 Encryption Server, so the policy will not be applied.
This article will cover the following topics:
Table of Contents
Policies are enforced on the PGP Encryption Server with PGP Gateway Email, and at the desktop level with PGP Encryption Desktop client. If your PGP 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 Encryption client installations bound to your PGP 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 Server is not proxying and encrypting email in the mailstream, it is important to create secure mail policy, because PGP client receives and enforces policy information from the PGP Server.
Symantec Drive Encryption and Symantec File Share Encryption are not affected by mail policy settings. If your PGP Encryption Server is only managing these features, mail policy is not required.
Section 1 of 5: 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.
This is a screenshot of each of these:
Section 2 of 5: Understanding the Pre-Installed Policy Chains
This section describes the pre-installed policy chains for a new, non-migrated, PGP Encryption Server installation. The pre-installed policy chains provide the PGP Encryption Server and PGP Desktop client 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 Server and PGP Desktop client.
- 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 Virus Scan: This policy chain specifies how to scan email for viruses, then bounce infected email or pass clean messages to the Outbound chain. Messages are routed to this chain by the Default chain. The rules in this chain apply only to messages processed by the PGP 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.
Section 3 of 5: 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 Encryption Server. Once you have created your mail policy, test it before you implement it in your network.
| Caution: The PGP 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:
- 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 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 example.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 example.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.
- Once you have finished creating conditions, click the Actions arrow button to open the Actions card and add actions to the rule.
- Next, click the Key Search arrow button to add searchable keyservers to the rule, if necessary.
- To see a summary of the entire rule, click the Summary arrow button.
Section 4 of 5: 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.
Section 5 of 5: Troubleshooting and Scenarios for Mail Rules
Troubleshooting Scenario 1: You want to make sure that when you send to a user "[email protected]", then encrypt to a list of keys, the rule will look something like this:
Conditions:
In the screenshot above, the qualifier "If all of the following are true" means that all the conditions need to match. Since we have only one condition, we can leave it.
If there were more conditions, then you can use "If all..." or "If any..." and then take the action needed.
There's flexibility with how these rules can be created.
Action:
As you can see in the screenshot above, we are not selecting the first check box to encrypt to recipient keys, but a specific list of keys.
So the conditions state that if [email protected], send the message, then the rule will invoke this action to encrypt to these three keys.
Troubleshooting Scenario 2: We want to receive SMIME signed content for some users, but for these users, we do not want the PGP server to attempt to decrypt or annotate the message.
In order to achieve this, let's look at the following rule:
Condition:
TIP: If you would like to see more samples of the headers above, see the following article:
150133 - Header and body flags that indicate PGP encrypted email for SPAM filter and mail server configuration
As you can see in the screenshot above, we've got the qualifier "If all of the following are true", meaning all of the conditions need to match.
In this example, we've got two groups listed. The first is for the email address for the recipient. Then there is another group that has several other conditions, but these conditions can be "or", meaning, any one of the four conditions match.
So for this rule to match, the email needs to match both the email address, and one of the next conditions in the second group.
So for example, if the email is going to "[email protected]", and the email has a "Content-Type" header of "multipart/signed" then rule condition will match.
In another example, if the email is going to "[email protected]", and the email has a "Content-Type" header of "Application/pkcs7-signature" then rule condition will match.
Because we used the "If any" for the second qualifier group, you don't need to match all of the conditions, only one of them from the first group, and one from the second group for this Condition.
Troubleshooting Scenario 3: Forcing messages to be sent unencrypted based on header
WARNING - Although this will describe how to send messages unencrypted based on header, doing so requires thorough testing to ensure no sensitive data is sent out unencrypted.
To do this, see the above screenshot in Scenario 2 for the basis of this. In this example, we want to ensure calendar invites are all sent unencrypted.
Calendar invites typically have the same content type, which is the following:
In this example, we can create a rule with the following components in the Conditions section:
1. If any
2. Message Header
3. Content-Type
4. is
5. Content-Type: text/calendar
Then in the Actions section, you can set the message to send unencrypted.
So if any calendar invites are sent out, they are sent unencrypted.
As mentioned, this should be thoroughly tested to ensure sensitve content is not sent out unencrypted. If there is any chance that calendar invites may contain sensitive information, this should not be used.
Instead, you should add more conditions, so that multiple conditions need to be matched, such as the header mentioned above + "noencrypt" in the title or similar tactic.
There are many more ways you can do the above, such as build a Dictionary and then use these headers. If you need more ideas on what you can do or to troubleshoot, reach out to Symantec Encryption Support for further guidance
Additional Information
153426 - Troubleshooting: Mailflow with Symantec Encryption Management Server (PGP Server)
181072 - Configuring Mail Proxies with the PGP Server (Symantec Encryption Management Server)
156100 - Emails going to exception chain on the PGP Server (Symantec Encryption Management Server)
156303 - Symantec Encryption Products Current Version Available
Feedback
