Avoiding Excessive Security Warnings when Sending Automated E-mail Messages
This documentation is archived and is not being maintained.

Avoiding Excessive Security Warnings when Sending Automated E-mail Messages

Office 2003
 

Angela Wong
Microsoft Corporation

June 2004

Applies to:
   Microsoft Office Outlook 2003
   Microsoft Outlook 2002
   Microsoft Outlook 2000
   Microsoft Outlook 98

Summary:   Sending e-mail programmatically with Microsoft Office Outlook generates security warnings for the user. Even though these warnings help alert users to possible attacks from malicious programs, some users may get accustomed to acknowledging them and perhaps overlook a real threat. Find out how you can design applications that avoid overuse of these warnings, where appropriate. (8 printed pages)

Contents

Introduction
Types of Security Warnings
   Sending E-mail
   Accessing Address Information
   Attaching Disallowed Files
Ways to Avoid Security Warnings
   Administrative Security Form
   Trusted COM Add-ins
   Registry Settings
   Microsoft Extended MAPI
   Collaboration Data Objects for Windows
   Programmatically Acknowledging Security Warnings
Conclusion
Resources

Introduction

To prevent malicious programs from accessing e-mail addresses in Microsoft Office Outlook address books and using Outlook to propagate viruses, certain versions of Outlook have implemented security blocks to parts of the Outlook object model. These versions include Outlook 2003, Outlook 2002, Outlook 2000 Service Pack 2 (SP2), and versions of Outlook 2000 prior to SP2 and Outlook 98 that have been patched with the Outlook security update. Outlook applications that access these blocked properties and methods in the object model can generate security warnings for the user.

In particular, Outlook applications that automatically send e-mail through the object model of the above versions of Outlook always trigger a "send e-mail" security warning (Figure 1 or Figure 2). While these security warnings help protect users from computer virus attacks, depending on the design of the application, these warnings may get displayed so frequently that some features may become virtually unusable. Some users may eventually overlook the importance of the warnings. Learn about the types of security warnings and how administrators and application designers can avoid overusing them, where appropriate.

Types of Security Warnings

Generally, when an application attempts to access a method or property that has been blocked in the Outlook object model, a security warning is displayed. The following articles list the methods and properties subject to the Outlook security object model guard in each version of Outlook.

In particular, accessing methods and properties that relate to sending e-mail, accessing the address book, or attaching a disallowed document type to an e-mail message cause security warnings.

Sending E-mail

When an application attempts to send a message using the Send method of an item, the following security warning appears. To discourage the user from affirming the action without giving it some thought, the Yes button is initially disabled for a 5-second period.

Aa168346.odc_olsendemailsprogrammatically_1(en-us,office.11).gif

Figure 1. Send e-mail security warning for Send method

Sending e-mail with the Execute method of the Action object also invokes the following security warning (Figure 2).

Aa168346.odc_olsendemailsprogrammatically_2(en-us,office.11).gif

Figure 2. Send e-mail security warning for Execute method of Action object

Accessing Address Information

If an application tries to access address information in an Outlook item or the address book, or attempts to save an Outlook item as a file, the user sees the following security warning (Figure 3). The user can choose to deny access, authorize a one-time access, or authorize access for up to 10 minutes.

Aa168346.odc_olsendemailsprogrammatically_3(en-us,office.11).gif

Figure 3. Access e-mail addresses security warning

Note that, in general, accessing a blocked property invokes a security warning, but assigning it does not. For example, this line will invoke a security warning:

Debug.Print objMailItem.To

but this one will not:

objMailItem.To = "webmaster@outlookcode.com" 

Attaching Disallowed Files

Outlook 2003, Outlook 2002, Outlook 2000 SP2, and patched versions of Outlook 2000 and Outlook 98 have categorized certain file types as Level 1 attachments. Level 1 attachments generally are program files capable of malicious acts and are completely blocked by the object model guard. If an application attempts to attach a file that belongs to the Level 1 file types, the application will get a warning and will not be able to succeed. Outlook does not allow opening a Level 1 attachment either.

Note   Outlook does not remove a Level 1 attachment from an outgoing e-mail message. The attachment is only hidden in Outlook; other e-mail programs that do not block such attachments will still open them.

See Attachment File Types Restricted by Outlook 2003 for a default list of Level 1 attachment types that apply to all versions of Outlook that have the object model guard active. In addition to the default Level 1 list, Outlook 2000 SP3 blocks the Outlook Personal Folder file type (.pst) as well.

The object model guard supports Level 2 attachment types that require the e-mail recipient to save an attachment to disk before opening it. Level 2 files are generally considered less of a threat than Level 1 files; the antivirus program on the local computer is expected to scan the file for security once it is saved to disk. Note that Level 2 attachments cannot be forwarded. The object model guard does not specify by default any file type as a Level 2 attachment; administrators in a Microsoft Exchange Server environment can use the administrative security form to specify file types for Level 2 attachments.

Ways to Avoid Security Warnings

Generally, the object model guard is always active, even in cases where the code is digitally signed, unless the application is an Outlook 2003 trusted Component Object Model (COM) add-in or it runs from a published Outlook 2003 form. In scenarios where the object model guard displays security warnings, there are a number of administrative and programmatic alternatives that applications could use to modify this behavior. Among these alternatives, the administrative security form, trusted COM add-ins, appropriate registry settings, and Extended Messaging Application Programming Interface (MAPI) work well with Outlook. There are also Microsoft Windows and third-party libraries and tools that allow applications to bypass part or all of the Outlook object model guard, but not all of them are supported by Outlook. Table 1 provides a summary of these alternatives and the actions for which they can be used to modify the display of security warnings. The remainder of this article describes these alternatives and provides additional references that show how to implement them.

Table 1. Options to modify the display of security warnings

 Sending e-mailAccessing address informationAttaching Level 1 or Level 2 files to e-mail messages
Administrative security formYesYesYes
Trusted COM add-insYesYesNo
Registry settingsNoNoYes
Extended MAPIYesYesNo
CDOSYSYesYesYes
Programmatic acknowledgementYesYesNo

Administrative Security Form

In an Exchange Server environment, administrators can use an administrative security form to customize security settings. These settings override the default security settings in Outlook. Using this form is the only way within Outlook to modify overall how the object model guard displays security warnings, including those invoked by applications trying to send e-mail programmatically.

The administrator installs the security form in a public folder and uses it to configure security options. The form supports the following customizations:

  • Trusting COM add-ins so that calls to blocked properties and methods do not invoke any security warnings. For Outlook 2003, COM add-ins should be constructed in a certain way, as described below in the "Trusted COM Add-ins" section.
  • For Outlook 2002, trusting Microsoft Visual Basic Scripting Edition (VBScript) code behind one-off forms. For Outlook 2003, while you can no longer trust one-off forms, published forms are always trusted, if the code behind the form derives all Outlook objects from the intrinsic Application and Item objects.
  • Specifying whether to prompt, automatically approve, or automatically deny when sending Outlook items, accessing address information, and saving an Outlook item.
  • Specifying their own sets of Level 1 and Level 2 attachments.
  • Lowering the default security settings for Level 1 attachments.
    Warning    Lowering the level of security through an administrative security form applies to all applications running in that Exchange Server environment, including malicious programs.

For more information on the administrative security form for Outlook 2003, see Customizing Security Settings by Using the Outlook Security Template. For information for earlier versions of Outlook, see the Microsoft Office Resource Kit for the corresponding version.

Trusted COM Add-ins

For Outlook 2003 and Outlook 2002, COM add-ins can be trusted through the administrative security form. Outlook 2003 has additional security changes for COM add-ins. One condition for COM add-ins to be trusted is to derive all objects from the Application object passed by the OnConnection event. You can also specify whether to trust all installed COM add-ins in the macro security dialog box. For more information on trusting COM add-ins, see What's New in Microsoft Office Outlook 2003 for Developers for Outlook 2003, and Using the COM Add-in Shim to Trust Outlook 2002 Add-ins Built with Visual Studio .NET for Outlook 2002.

Registry Settings

Security warnings about file attachments can be generated when an application attempts to add certain attachment types to an e-mail message before sending it programmatically. In Outlook 2002 and Outlook 2000 SP3, end users and system administrators can modify the system registry to change the file attachment types that the object model guard blocks by default.

Warning   Lowering the security level for certain attachment file types increases the vulnerability to a virus attack. For more information, see Microsoft Knowledge Base Article – 290497: OL2002: You Cannot Open Attachments for Outlook 2002 and Microsoft Knowledge Base Article – 262631: OL2000: Information About the Outlook E-mail Security Update for Outlook 2000 SP3.

Note that security settings specified in an administrative security form override those set in the system registry.

Microsoft Extended MAPI

Extended Messaging Application Programming Interface (MAPI) is usually referred to simply as MAPI and is a library of functions that allow applications to create and manage messages on a client computer. COM add-ins and external programs written in C, C++, or Delphi can fully utilize Extended MAPI to avoid security warnings generated by the Outlook object model guard. Outlook developers can choose to use Extended MAPI to avoid security warnings if, for some reason, their COM add-ins cannot be run as trusted.

Note   Since the release of Office 2002 SP3, which blocks the HTMLBody property, applications using Extended MAPI can no longer extract the HTML content from messages. For more information, see Microsoft Knowledge Base Article – 838871: Custom solutions and add-ins that integrate with Outlook 2002 are affected after you apply Office XP Service Pack 3 (SP3).

Collaboration Data Objects for Windows

Microsoft Collaboration Data Objects (CDO) for Microsoft Windows 2000 and later is a collection of COM libraries that allow applications to create and send Internet messages with the Simple Mail Transfer Protocol (SMTP). The collection is commonly known as CDOSYS and is available as CDOSYS.DLL. CDOSYS implements the 2.0 version of the Collaboration Data Objects API specification; it bypasses the Outlook object model and hence does not invoke security warnings of the Outlook object model guard.

For more information, see Collaboration Data Objects for Windows 2000.

Programmatically Acknowledging Security Warnings

The Microsoft Visual Basic or Visual Basic for Applications SendKeys command can be used in earlier, unpatched versions of Outlook to programmatically acknowledge security warnings. A number of third-party tools also exist to acknowledge security warning dialog boxes automatically, but these alternatives are highly discouraged.

Warning    Clicking through security warnings automatically opens a security vulnerability to malicious worms and viruses that seek to exploit the Outlook object model.

Versions of Outlook with the object model guard (that is, Outlook 2003, Outlook 2002, Outlook 2000 SP2, and patched versions of Outlook 2000 and Outlook 98) do not allow the SendKeys command to access security dialog boxes. This feature prevents malicious programs from automatically dismissing the warning messages and circumventing the security features.

Conclusion

The Outlook object model guard helps protect users from malicious viruses and worms that can be spread by exploiting Outlook. Applications using the Outlook object model invoke security warnings when they attempt to send e-mail, access any address information, or attach certain files to an e-mail message. Under some circumstances, these warnings may be overwhelming and thus render themselves ineffective. Administrators and application designers can use various methods to avoid overuse of these warnings, where appropriate.

Resources

Customizing Outlook 2003 to Help Prevent Viruses

Outlook "Object Model Guard" Security Issues for Developers

Outlook Email Security Update

Show:
© 2016 Microsoft