Outlook "Object Model Guard" Security Issues for Developers

"Security" in this context refers to the so-called "object model guard" that triggers security prompts and blocks access to certain features in an effort to prevent malicious programs from harvesting email addresses from Outlook data and using Outlook to propagate viruses and spam. These prompts cannot simply be turned off, except in Outlook 2007 with an anti-virus application running. This page discusses strategies for avoiding the security prompts. For information on security issues related to Outlook forms development, see:

• Microsoft Outlook Forms Security Issues

Object model guard

When an external application (or badly written Outlook add-in, VBA, or form code) accesses a blocked property or method related to addresses, Outlook displays this dialog, to which the user must respond before the application can continue:

The user has the option of allowing access for up to 10 minutes.

When an application attempts to send a message, this dialog appears. The Yes button is disabled for a 5-second waiting period.

Note that setting a blocked property is generally OK. For example, this statement will not trigger an address security prompt:

objMailItem.To = "webmaster@outlookcode.com"

but this one will:

Debug.Print objMailItem.To

Strategies

Ideally, applications that automate Outlook should avoid code that triggers these security prompts. However, if security prompts cannot be avoided, you should at least handle the possible errors to make sure that your application doesn't crash if a user clicks No when presented with a security prompt. Additional details on strategies appear after the lists of what's available.

Sending messages

It is not necessary to use Outlook objects at all if your goal is simply to create and send an email message. Microsoft provides the CDO for Windows library for creating and sending messages with SMTP. Using this library totally bypasses Outlook and MAPI and does not trigger security prompts. For code samples, see:

• VBScript To Send Email Using CDO
• Forward message and retain sender with CDO for Windows
• Sending mail from Excel with CDO

For ISVs

In general, ISVs need to take a different approach from that used by personal or corporate developers, who have some control over the Outlook environment. ISVs cannot assume that their applications will be "trusted" with regard to the object model guard or that Outlook 2007 users will have an anti-virus application running. At a minimum, ISVs should ensure that code execution continues even if the user says No to a security prompt. Strategies appropriate for ISVs include, in order of descending security and complexity:

• Use Extended MAPI instead of Outlook objects, Simple MAPI, or CDO 1.21 for all code that potentially triggers security prompts. This is the most secure strategy and is what Microsoft recommends for external applications; it used by tools such as PDA synchronization applications. For an example of a C++ project that can provide ExMAPI functionality to an Outlook application, see Bridging the Gap between .NET and Extended MAPI .

• Use a third-party library -- Redemption or MAPI33 -- for all code that potentially triggers security prompts. This approach is easier than using Extended MAPI, which has a steep learning curve, and almost as secure. These libraries also offer additional features to help with Outlook code projects.

• Deploy with your application a tool to suppress the security prompts.

For personal and corporate developers

Because they potentially have more control over the client mail environment, personal and corporate developers can consider some other strategies in addition to those available to ISVs:

• For Outlook 2007, make sure the machine is running an up-to-date anti-virus application and do all coding with Outlook objects, avoiding CDO 1.21 and Simple MAPI code.

• In Outlook custom form code, Outlook VBA code, and COM add-ins, derive all objects from the Outlook.Application object provided by VBA or the add-in architecture. For example, see the sample VBA "run a script" rule procedure below.

• Deploy Outlook security settings that "trust" certain COM add-ins or that allow all applications to have unrestricted access to certain features, such as accessing addresses. In versions before Outlook 2007, this requires Microsoft Exchange Server. For Outlook 2007, see the section on version-specific considerations below.

In a corporate environment where Exchange is the email server, direct access to the data on the server is available through the WebDAV API beginning with Exchange 2000 and, starting with Exchange 2007, through Exchange Web Services. We do not cover Exchange development topics on this site. See:

• Exchange developer documentation
• Basic concepts and links to other resources
• Exchange development discussion forum

Version-specific considerations

In Outlook 2007, external applications that automate Outlook with Outlook objects do not trigger security prompts if the machine is running Windows XP or Windows Vista and is configured with an up-to-date anti-virus application. See:

• Code Security Changes in Outlook 2007
• Customize programmatic settings in Outlook 2007

If the machine does not have an up-to-date anti-virus application, Outlook 2007 will act like Outlook 2003. By default, Outlook 2003 does not display security prompts in three specific types of applications:

• VBScript code in published, non-one-off Outlook forms constructed to derive all Outlook objects from the intrinsic Application and Item objects. For information on one-off forms, see Saving and Publishing Outlook Forms.

• Outlook add-ins constructed to derive all objects from the Application object passed by the add-in architecture

• Outlook VBA code constructed to derive all Outlook objects from the intrinsic Application object. If you're writing a "run a script" rule to run code against a particular message, you'll need to derive the message from the Application object using the message's EntryID, as shown  below.

Also see:

• What's New in Microsoft Office Outlook 2003 for Developers

VBA "Run a Script" Rule

To take advantage of the fact that the Application object in Outlook VBA is trusted, a VBA procedure designed to be executed as a "run a script" rule action from the Rules Wizard needs to use the EntryID of the VBA procedure's MailItem or MeetingItem argument to get the desired item as an object derived from the Application object, rather than use the item passed as an argument:

Sub RunAScriptRuleRoutine(MyMail As MailItem) Dim strID As String Dim olNS As Outlook.NameSpace Dim oMail As Outlook.MailItem strID = MyMail.EntryID Set olNS = Application.GetNamespace("MAPI") Set oMail = olNS.GetItemFromID(strID) ' do stuff with oMail, e.g. MsgBox oMail.Body Set olMail = Nothing Set olNS = Nothing End Sub

Recode with Redemption

Outlook Redemption provides a COM interface to Outlook objects that avoids the "object model guard" and exposes properties and methods not available through the Outlook model, such as sender address, the RTF body of an item, Internet message headers, MAPI tables, and many more. Several security features protect it from being used by malicious programs to send Outlook mail. Redemption is free for personal use. The redistributable developer version adds a Profman.dll component with the ability to enumerate, add, delete, and modify Outlook profiles using VB or VBScript.

IIs Redemption itself a security risk? Redemption's author, Outlook MVP Dmitry Streblechenko, responded in the outlook-dev discussion list to the topic In My World Redemption Is A Security Risk.

Using Redemption to send a message is quite simple. You save the Outlook MailItem object and then set the SafeMailItem.Item property to point to that MailItem:

objMailItem.Save Set objSafeMail = _ CreateObject("Redemption.SafeMailItem") objSafeMail.Item = objMailItem objSafeMail.Send

Additional samples are available at the Redemption web site, or you can search for SafeMailItem for more samples on this site. Redemption can be used with any programming language. Another third-party library solely for .NET application is MAPI33.

Deploy Outlook security settings

In a corporate environment, the administrator may choose to loosen Outlook security for some or all users. For implementation details, see:

• Customize programmatic settings in Outlook 2007
• Administrative Options for the Outlook E-mail Security Update

This may be an unsatisfactory solution for a number of reasons:

• In versions before Outlook 2007, this approach requires a Microsoft Exchange Server public folder.

• Loosening security to allow programmatic access to addresses, for example, means that all programs have access to addresses, including malicious programs.

• While Outlook 2003 supports trusted COM add-ins, the trust covers only Outlook objects. Since the Outlook 2003 object model omits many key features needed by developers (such as returning recipient selections from the Address Book), even a trusted COM add-in may encounter security prompts unless it is recoded to avoid blocked CDO properties and methods.

ISVs should not count on a COM add-in being trusted and should instead use one of the other strategies listed above.

If security settings are deployed in an Outlook 2003 environment, including both default security settings and exceptions, install this hotfix on all machines to allow them to get exception settings while in cached Exchange mode:

• Outlook 2003 hotfix package April 28, 2009

Trusted COM add-ins

Among the security settings that can be deployed is an option to trust particular add-ins. For Outlook 2007, add-ins can be trusted using Group Policy Objects or the Office Customization Tool. For standalone Outlook 2003 and Outlook 2007 users, all COM add-ins are trusted by default.

The key issue for developers is what is actually trusted: It's the Outlook.Application object that is passed by the add-in architecture. Therefore, in order to avoid Outlook object model security prompts, the add-in must derive all Outlook objects from this Outlook.Application object. In VSTO add-ins (Visual Studio 2008 and VSTO 2005 SE), that would be the Globals.ThisAddin.Application object. In shared add-ins using the IDTExtensibility2 interface, that would be the Application object passed as an argument by the OnConnection event.

For more information, see:

• OL2002: COM Add-Ins Are Not Trusted If They Are Created with Visual Studio .NET
• Important Security Notes for Microsoft Outlook COM Add-In Developers (Outlook 2003)

Suppress security prompts

For utilities that either bypass or suppress the security prompts, see: