Description of the developer-related security changes in Outlook 2002 Service Pack 3 (SP3) (838871)

MORE INFORMATION

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 Book

Outlook 2002 generates the following security warning if a custom solution programmatically accesses the body or the notes of an item: A program is trying to access e-mail addresses you have stored in Outlook. Do you want to allow this? If this is unexpected, it may be a virus and you should choose "No". 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.

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:

• IHateSpam
• SpamNet
• Norton
• AntiSpam
• HotBar
• Smiley Central
• ActiveX programs for Palm Pilot software Palm's Hotsync v4.1.0
• NewsGator Acrobat add-in for Word Incredimail for Outlook plug-in Cloudmark

For more information about preventing the security warning from appearing, click the following article number to view the article in the Microsoft Knowledge Base:

Custom forms may not work in delegated (shared) mailboxes or in public folders

If 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 mailboxes

Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.
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:

1. Click Start, click Run, type regedit, and then click OK.
2. Locate and then click the following key in the registry:

   HKEY_CURRENT_USER\Software\Microsoft\Office\10.0\Outlook\Security

3. On the Edit menu, point to New, and then click DWORD Value.
4. Type SharedFolderScript, and then press ENTER.
5. On the Edit menu, click Modify.
6. Type 1, and then click OK.

Control custom code in Exchange public folders

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:

1. Click Start, click Run, type regedit, and then click OK.
2. Locate and then click the following key in the registry:

   HKEY_CURRENT_USER\Software\Microsoft\Office\10.0\Outlook\Security

3. On the Edit menu, point to New, and then click DWORD Value.
4. Type PublicFolderScript, and then press ENTER.
5. On the Edit menu, click Modify.
6. Type 0, and then click OK.

Untrusted controls in one-off forms do not run

If 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:

Outlook forms cache is folder-specific

Outlook 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 page

The 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.

MORE INFORMATION

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.