Security notes for COM add-in developers

Microsoft Outlook Visual Basic

Security notes for COM add-in developers

COM Add-ins Using Default Security

In Microsoft Office Outlook 2003, all COM add-ins that run on a computer that is not configured to obtain security settings from a Microsoft Exchange Server are considered trusted by default. This implies that the add-ins that run on clients that are not Exchange clients and the add-ins that use default security in Exchange environments are trusted automatically. As in Microsoft Outlook 2002, Microsoft Office Outlook 2003 trusts only the main Application object that is passed to the OnConnection event of the add-in.

COM Add-ins Using Security Settings from an Exchange Server

There has been no change in the way Outlook 2003 trusts COM add-ins in an Exchange environment when the security settings are obtained from the Exchange server. An add-in will be considered trusted only if it is registered in the Security Settings folder. As in Outlook 2002, Outlook 2003 trusts only the main Application object that is passed to the OnConnection event of the add-in.

Improvements to Outlook Object Model Guard and the Impact

Outlook 2003 inherits the Outlook 2002 object model guard behavior and, in addition, blocks code that attempts to access the Body and HTMLBody properties of various Outlook items. This allows users to verify that the program or add-in accessing the Body and HTMLBody properties of these items is trustworthy, before they allow access to the contents of the items. Although this change forces the display of security warnings in existing COM add-ins that access the Body or HTMLBody properties of items, this will help prevent malicious code from running unknown to the user.

You can avoid the display of security warnings by deriving all objects, properties, and methods from the Application object passed to the OnConnection procedure of the add-in. Outlook 2003 trusts only the Application object passed to the OnConnection procedure of the add-in. If you create a new Application object, for example, by using the CreateObject method, that object and any of its subordinate objects, properties, and methods will not be trusted and the blocked properties and methods will raise security warnings.

New Object Model Blocks

The following are the additional properties that have been blocked in Outlook 2003:

  • The IMAddress property of a ContactItem object.
  • The HTMLBody property of a MailItem object.
  • The Body property of the following objects: ContactItem, MailItem, PostItem, AppointmentItem, TaskItem, TaskRequestItem, TaskRequestAcceptItem, TaskRequestDeclineItem, TaskRequestUpdateItem, DistListItem, JournalItem, MeetingItem, ReportItem, RemoteItem, NoteItem, or DocumentItem.

Also, if you use a third-party add-ins, custom solutions, or other programs that integrate with Outlook 2003, you may receive one or more of the following warnings:

  • "A program is trying to automatically send e-mail on your behalf. Do you want to allow this? If this is unexpected, it may be a virus and you should choose No. "
  • "A program is trying to access e-mail addresses you have stored in Outlook. Do you want to allow this? If this is unexpected, it may be a virus and you should choose No. "

These warning messages are commonly associated with software that is designed to synchronize Outlook data with handheld computers, but may occur with any type of add-in or custom solution.