Outlook Developer Home

Outlook Programmer's Library

Outlook Technologies

Outlook Forms

Languages

Samples

Other Technologies

Outlook "Object Model Guard" Security Issues for Developers

"Security" in this context refers to the Outlook Email Security Update, a feature in Outlook 2000 Service Pack 2 and later versions that triggers security prompts and blocks access to certain other features in an effort to prevent malicious programs from harvesting email addresses from Outlook data and using Outlook to propagate viruses and spam. End users experience these security features mainly when they receive messages with blocked attachments.

This page covers overall strategies for writing code to deal with the security prompts and reviews the differences among Outlook versions. For information on security issues related to Outlook forms development, see:

Microsoft Outlook Forms Security Issues for Developers

Object model guard

When an application accesses a blocked property or method related to addresses, Outlook displays this dialog, which the user must respond to before the application can continue:

The user has the option of allowing access for up to 10 minutes. However, this does not always work. We don't know exactly why, but in some circumstances, the user will continue to get address access prompts even after allowing access for a period of time.

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

Version differences

These articles explain the properties and methods subject to the "object model guard" in each Outlook version. Generally, they include any property or method that could be used to harvest addresses or send messages:

Note that Outlook 2003 by default 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
Outlook VBA code constructed to derive all Outlook objects from the intrinsic Application object from the built-in ThisOutlookSession module. If you're writing an Outlook 2003 run-a-script rule to run code against a particular message, you'll need to derive the message from the Application using the message's EntryID.
Outlook COM add-ins properly constructed to derive all objects from the Application object passed by the OnConnection event

Office XP Service Pack 3 adds four more properties to the list of those blocked in Outlook 2002 -- Body, HTMLBody, Inspector.HTMLEditor, and Inspector.WordEditor.

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 olMail As Outlook.MailItem strID = MyMail.EntryID Set olNS = Application.GetNamespace("MAPI") Set olMail = olNS.GetItemFromID(strID) ' do stuff with olMail, e.g. MsgBox olMail.Body Set olMail = Nothing Set olNS = Nothing End Sub

For another example, see To convert incoming HTML messages to Outlook Rich Text or plain text format.

Strategies

For developers building Outlook forms and COM add-ins and other applications that access Outlook data, there is no simple registry hack to turn off the security prompts, although some of the settings that govern forms security do have registry entries in Outlook 2003. While an Exchange administrator can loosen Outlook security for some or all users, this is generally an unsatisfactory solution for two main reasons:

Loosening security to allow programmatic access to addresses, for example, means that all programs have access to addresses, including malicious programs.
While Outlook 2002 and 2003 support trusted COM add-ins, the trust covers only Outlook objects. Since the Outlook object model omits many key features needed by developers (such as returning recipient selections from the Address Book), even a trusted COM add-in will encounter security prompts unless it is recoded to avoid blocked CDO and Outlook objects.

NOTE: If you are using Outlook 2003 to administer the Outlook Security Settings public folder, you may need Outlook 2003 post-Service Pack 1 hotfix package September 9, 2004.

Therefore, developers -- particularly ISVs working on programs for use in a wide range of Outlook environments -- should not count on a COM add-in being trusted. Instead, they need to take one or more of these approaches:

Handle the errors	This is the bare minimum: make sure that your application doesn't crash if a user clicks No when presented with a security prompt.
Recode the application in Extended MAPI	This is the most secure approach and the one that Microsoft recommends for use by applications that must support multiple Outlook versions. However, it applies only to COM add-ins and external programs; you cannot use Extended MAPI in Outlook forms or VBA. Full use of Extended MAPI requires C++ or Delphi. Read-only access to at least some MAPI properties is available through the MAPIOBJECT hidden object property on Outlook items, as described in How to avoid security prompts in Visual Basic programs for Outlook and implemented in the free MAPIProp library described in that article.
Trusted COM add-ins	In Outlook 2002 and 2003, Exchange administrators can explicitly trust specific COM add-ins. For standalone Outlook 2003 users, all COM add-ins are trusted. The add-in needs to be constructed so that all its Outlook objects derive from the Application object passed as an argument to OnConnection.
Recode the application with Outlook Redemption	This is probably the most popular approach among VB/VBA/Outlook forms developers. Redemption is a third-party COM library wrapping Extended MAPI. In addition to avoiding security prompts, it adds functionality not availability in the Outlook object model.
Send messages with CDOSYS or CDONTS	Microsoft provides these libraries for Windows 2000 or later (CDOSYS) and Windows NT (CDONTS) for creating and sending messages with SMTP. They totally bypass Outlook and MAPI and do not trigger security prompts. See: VBScript To Send Email Using CDO [FrontPage Scheduled Image Component]Forward message and retain sender with CDO for Windows
"Click" or suppress the security dialogs programmatically	Depending on which tool you use, you may still have to wait 5 seconds before clicking Yes for a send.

Handle the errors

The bare minimum for making your code compatible with the "object model guard" is to include an error handling statement in each procedure that calls a blocked property or method, e.g:

On Error Resume Next

Better yet, handle the specific error that occurs when a user clicks No on the security dialog and use a MsgBox to provide an explanation of the consequences, as in this snippet adapted from the sample at To automatically add an e-mail address as a Bcc:

On Error Resume Next Set objRecip = Item.Recipients.Add(strBcc) If Err = 287 Then strMsg = "Could not add a Bcc recipient " & _ "because the user said No to the security prompt." & _ " Do you want still to send the message?" res = MsgBox(strMsg, vbYesNo + vbDefaultButton1, _ "Security Prompt Cancelled") If res = vbNo Then Cancel = True Else objRecip.Delete End If Err.Clear End If

Trusted COM add-ins

In Outlook 2002 and 2003, Exchange administrators can explicitly trust particular COM add-ins through the Outlook Security Settings folder. For standalone Outlook 2003 users, all COM add-ins are trusted.

The key issue for developers is what is actually trusted: It's the Application object that is passed to the OnConnection event of the add-in. Therefore, in order to avoid Outlook object model security prompts, the add-in must derive all Outlook objects from this Application object.

For more information, see:

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

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

Note that Redemption does not provide access without security prompts to the Inspector.HTMLEditor and Inspector.WordEditor object properties, which are blocked in Outlook 2002 Service Pack 3 and later versions.

"Click" or suppress the security dialogs

A paper by two U.S. Air Force Academy professors, Reinforcing Dialog-Based Security, was the first demonstration of how to get around the object model guard prompts using VBScript code and the SendKeys method to "click" the buttons on the prompts. (SendKeys doesn't work, though, for the most recent versions of Outlook.) For utilities that use that or other methods to either bypass or suppress the security prompts, see:

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.
Dkms's XP File splitter	Source code included. The SetAddressingPermissions procedure shows how to use SendKeys with Outlook security prompts.
Express ClickYes	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.
Outlook Security Manager	Allows developers to turn security prompts off and back on with a couple of simple code statements.

Other Tools

MAPIProp

Free COM 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.

More Information


	© 2002-6 TurtleFlock, LLC All right reserved. About OutlookCode.com Send comments to webmaster@outlookcode.com Designed and Implemented by TerraLink USA FrontPage Integration by RobsonDesignWorks


get Sue's code \| forums \| share your own code \| registration