Improve Microsoft Outlook MAPI Performance with PGP Encryption Desktop for Email Encryption

Products

• Desktop Email Encryption
• Desktop Email Encryption, Powered by PGP Technology
• Encryption Desktop Corporate Powered by PGP Technology

Issue/Introduction

This article includes some troubleshooting steps to improve performance with Microsoft Outlook MAPI operation's when used in combination with PGP Encryption Desktop for Email Encryption. 

Resolution

When you perform Microsoft Outlook MAPI operations, you can minimize poor performances in several instances by making a few configuration changes.

TIP: For information on how to troubleshoot PGP Plug-in scenarios, see article 190223.

The following list describes the problems and changes you can do to improve performance while using MAPI.

Scenario 1: Slow behavior in the message list/inbox.

Remedy: Disable the Reading Pane (View > Reading Pane > Off), and (if desired) enable the Preview (View > AutoPreview).

Explanation: PGP Desktop with MAPI keeps the email messages encrypted but decrypts the message and verifies the signatures when they are read. If the Reading Pane is used, it forces each message to be decrypted/verified every time it is highlighted, even when the user is merely scrolling through the inbox looking for something else.

The AutoPreview option displays a 2-3 line preview under each message. This preview does not force the MAPI proxy to decrypt the messages, and therefore dramatically improves the time to scroll through a message list. Additionally, the encrypted messages are not displayed in the AutoPreview, thus protecting sensitive information from being read by someone looking over the user's shoulder.

After you disable the reading pane, it should not take time to open the messages - if it is still takes a while to open the message, check the WINS configuration. In PGP Desktop version 9.8 and earlier, when a message is opened for reading, it will search for the exchange server's NETBIOS name. If the WINS server is not configured, it causes a local broadcast for WINS name resolutions and waits for a response. The chance of the exchange server being on the same physical network as the Outlook client is less, and the wait goes on until time out. To avoid this scenario, add the exchange server WINS name to the LMHOSTS and HOSTS file. This will speed up the name resolution and open messages without delay.

 

Scenario 2: Long delay when sending messages before the Windows Notifier appears.

Remedy: Optimize network performance, specifically, the DNS lookups. Explanation: When sending a message, PGP Desktop will connect to the PGP Universal server to check the policy via the domain name (for example, keys.example.com). Any delay in resolving the domain name to an IP address may cause performance bottlenecks when sending emails; even small delays can add-up into a noticeable delay.

 

Scenario 3: Long delay when sending messages, after Notifier appears.

Remedy: Disable the Notifier or adjust settings.

Explanation: By default, the Notifier displays a message for up to six seconds whenever an email is sent, even the unencrypted ones. This allows the user to cancel a message which should be encrypted, but is not. Users may get frustrated by this delay, instead of seeing this as a security confirmation of their outbound messages. In this case, to increase user satisfaction at the potential expense of a marginal increase in security exposure, you can minimize this delay or eliminate the use of Notifier entirely.

Scenario 4: Long delays when sending messages that are not encrypted.

Remedy: Use a custom rule set to encrypt the message that matches certain criteria, such as, message flagged as Confidential in Outlook.

Explanation: By default, PGP Desktop will encrypt a message to any recipient with an encryption key whether the message is marked as sensitive or not. This is a very powerful capability, allowing an organization to set a central policy and ensure that confidential information is protected; and at the same time the user does not need to do anything extra to send a secure email.

Consequently, PGP Desktop scans all outgoing messages for users with keys. If a message is sent to a distribution list, PGP Desktop expands the list and the checks each individual recipient. This process can be lengthy, but adds a significant amount of security to an organization's email traffic.

Some organizations may wish to optimize certain users for performance as opposed to security. In such cases, you can write a policy which encrypts only messages marked as confidential; and all others get passed through without processing.

To enable this policy, set the first policy in the Outbound Chain on PGP Universal to specify: If the message is not marked confidential then send in clear. This negative rule will be executed for non-confidential messages and further processing (including mailing list expansion) will be bypassed.

Note that such a policy may be particularly attractive to organizations with PGP Desktop email and a network-based Data Leak Protection (DLP) product integrated with PGP Universal Gateway email. In this scenario, messages which must be encrypted per policy can be tagged by the DLP product and routed through the PGP Universal server for encryption before leaving the corporate network, even if they are not tagged as confidential by the user when it was sent.

Scenario 5: Shared accounts/mailboxes configured in Outlook slow when used with "Auto Mapping" feature configured for the Exchange account.

Remedy: Disabling the Auto Mapping feature will help improve general performance with outlook, but when used with Symantec Encryption Desktop, significant performance can be observed.

Explanation: Using Shared Accounts or Mailboxes in Outlook configured with Auto Mapping can cause general performance issues even without email encryption.  Using Email encryption can add some additional cycles to this, but disabling Auto Mapping has seen significant performance improvements and should operate normally doing email encryption after disabling this feature.