Locking Down Outlook Object Model Security, Part 2

This is the second part of a guest commentary about the effect of the Outlook E-mail Security Update on the Outlook development environment. Several readers responded to my opinion in last week's Commentary that " . . . the default should be to distrust (and block) all programmatic access to the methods and properties that the object model guard blocks in the Outlook E-mail Security Update. The warning dialog box shouldn’t appear, and all programmatic address access or sending should fail silently." Interestingly enough, many readers' unhappiness with the Outlook E-mail Security Update relates to the Attachment Security component rather than the Object Model Guard.

Despite the continued spread of the SirCam worm (see http://www.windowsITsecurity.com/Panda/Index.cfm?FuseAction=Virus&VirusID=1104 ), many correspondents were disturbed that they can't open .exe attachments in Outlook with the Outlook E-mail Security Update installed! Those who need to circulate .exe attachments can try the following options:

If you use the Outlook E-mail Security Update, do you take advantage of the Administrative form to deploy default or custom programmatic security settings in your organization? In addition to the well-known problems with PDA synchronization, has the Outlook Object Model Guard disrupted any of your existing applications?

Outlook 2002 will ease your pain if you use the Trusted COM Add-ins feature of the Administrative form. Here’s how it works: You can "trust" a COM Add-in by adding it to the list of Trusted COM Add-ins, thus giving it unrestricted access to the entire Outlook Object Model, including properties and methods typically blocked by the Outlook Object Model Guard.

Be aware that you must use an Exchange Server mailbox to deploy Trusted COM Add-ins. If you use a Personal Folders (.pst) file for mail delivery, you can't use the trust mechanism for COM Add-ins.

If you have existing Outlook forms applications that make blocked Object Model calls, you must consider the costs and benefits of rewriting VBScript behind forms to take advantage of trusted COM Add-ins. Although rewriting this code can be an expensive proposition for companies that have deployed Outlook forms applications, your Trusted COM Add-in can expose public properties and methods that give your forms code trusted (unblocked) access to the Outlook Object Model.

Unfortunately, the trust mechanism works only for Outlook 2002. If you’re developing for Outlook 2000 and want to access blocked methods and properties of the Outlook Object Model or Collaboration Data Objects (CDO) (which has no trust mechanism for any version of Outlook), consider a third-party alternative such as Redemption.

Let me know what you think of these alternatives, and how you plan to deploy them in your organization.