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:
Desable security alerts with Outlook Security Manager
Outlook Security Manager is a programming tool that allows you to suppress security alerts invoked by the code of your application or add-in that interacts with Microsoft Outlook 2000 - 2013.
You will use just one object with three properties that enable or disable security warnings for Outlook Object Model, CDO and Simple MAPI. These properties are DisableOOMWarnings, DisableCDOWarnings and DisableSMAPIWarnings. Before accessing a protected Outlook property, calling a CDO method or Simple MAPI function in your code, you need to switch off the Security Guard via the corresponding property, and then turn it on again.
VB.NET code example:
Additional samples are available here: Disable "A program is trying to access e-mail addresses" and "A program is trying to automatically send email on your behalf".
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:
||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 more.|
|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 - 2013; .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.