Article ID: 838871
This article describes the developer-related security changes that have been made in Microsoft Outlook 2002 Service Pack 3 (SP3). These changes may adversely affect custom solutions that integrate with Outlook 2002.
Outlook 2002 SP3 includes a variety of security-related changes to help reduce the effects of various forms of malicious attacks on your computer and on your Outlook program. However, some of these changes may restrict the functionality that was available before you installed Outlook 2002 SP3. Although Microsoft regrets any adverse affect that these changes may have on custom solutions, these changes are necessary to help reduce risk.
The following issues may occur if you install Outlook 2002 SP3 with a custom solution, such as a custom form, a COM add-in, Outlook Visual Basic for Applications, or external code that automates Outlook.
Security warning about accessing the Address BookOutlook 2002 generates the following security warning if a custom solution programmatically accesses the body or the notes of an item: If you click Yes, you receive the following message:
This issue occurs when the Body, the HTMLBody, the WordEditor, or the HTMLEditor properties in the Outlook object library are used.
A program is trying to automatically send e-mail on your behalf. Do you want to allow this? If this is unexpected, it may be a virus and you should choose "No".
This security warning is designed to prevent malicious code from extracting e-mail addresses from the body of an e-mail message. This security message was first included in Microsoft Office Outlook 2003, but it has been added to Microsoft Outlook 2002 SP3 to additionally reduce the chance of malicious code being able to access e-mail addresses. The following programs are known to be affected by this change:
(http://support.microsoft.com/kb/290500/ )Description of the developer-related e-mail security features in Outlook 2002
Custom forms may not work in delegated (shared) mailboxes or in public foldersIf you are using Microsoft Exchange Server, you can access folders in another user's mailbox. By default, if you are accessing another user's mailbox, Visual Basic Scripting Edition (VBScript) code in Outlook custom forms will not run and folder home pages will not be loaded. Additionally, Outlook includes the ability to prevent Microsoft Visual Basic Scripting Edition (VBScript) code in Outlook custom forms from running and folder home pages from being loaded in Exchange public folders. By default, this functionality is already enabled.
These new security features that prevent VBScript code in Outlook custom forms from running and folder home pages from loading in shared mailboxes and Exchange public folders were first introduced in Outlook 2003. In Outlook 2003, you can also configure settings in the Outlook user interface to permit VBScript code in Outlook custom forms to run and folder home pages to load. To locate these settings in Outlook 2003, click Options on the Tools menu, click the Other tab, and then click Advanced Options. In versions of Outlook that are earlier than Outlook 2003, you cannot use the user interface to change these settings. However, you can use the registry to configure these settings.
Control custom code in shared mailboxesImportant This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/322756/ )How to back up and restore the registry in Windows
By default, custom code will run in public folders, and you do not have to create or to set a registry key to enable it. However, you can use the registry to prevent custom code and folder home pages from running in Exchange public folders.
Follow these steps, and then quit Registry Editor:
Control custom code in Exchange public foldersBy default, custom code will run in public folders, and you do not have to create or to set a registry key to enable it. However, you can use the registry to prevent custom code and folder home pages from running in Exchange public folders.
Follow these steps, and then quit Registry Editor:
Untrusted controls in one-off forms do not runIf you are using a one-off form, Outlook will not load ActiveX Controls that are not considered safe. This includes all controls that are not safe for scripting or for initialization. For additional information about one-off forms, click the following article number to view the article in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/290657/ )Description of form definitions and one-off forms in Outlook 2002
Outlook forms cache is folder-specificOutlook has been changed so that custom forms are cached for every folder where they are used. This change was made for security purposes, and it is consistent with the way that Outlook 2003 caches custom forms. In most custom form scenarios, this change in behavior will not affect how Outlook custom forms are used. However, custom form developers must take this change in account in scenarios where forms are published to multiple locations with the same name.
The <Filter> tag in the Outlook View Control works only on a folder home pageThe ViewXML property of the Outlook View Control was modified so that you cannot programmatically set a view's filter unless the control is hosted on a folder home page in Outlook.
The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, regarding the performance or reliability of these products.