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:
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 = "firstname.lastname@example.org"
but this one will:
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.
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:
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:
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:
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.
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:
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:
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:
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:
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:
Suppress security prompts
For utilities that either bypass or suppress the security prompts, see:
|Outlook Security Manager
||Allows developers to turn security prompts off and back on with a couple of simple code statements. .NET, ActiveX and VCL editions come in one package.|
|Advanced Security for Outlook
||Free add-in that allows you to determine what program is triggering security alerts in Outlook and always allow access without security prompts for specific programs that access the Outlook object model or use CDO 1.21 or Simple MAPI. |
||Clicks the security dialog buttons automatically, but can be set to start in a suspended state. Developers can activate and suspend automatic clicking of the security dialogs programmatically. (HINT: Use &H2 instead of WM_CLOSE) Free. |
Programming tool to switch security warnings off and back on with a few lines of code. Works for Outlook 2000 - 2010; .NET, ActiveX and VCL editions are delivered in one package.
Component designed to read MAPI properties of CDO and Outlook Object Model objects for Microsoft Outlook 2000, 2002/XP, 2003. Visual C++ source code included.