Microsoft has engineered a major change in Outlook 2003 that will minimize the intrusion of Outlook security prompts for many users. These prompts appear when programming code accesses certain features that could let a malicious program harvest email addresses or send messages. In earlier Outlook versions, a means to avoid those prompts was available only to Exchange administrators willing to maintain a special public folder and Outlook security settings form and to deploy a new security registry entry to Outlook clients. Standalone users and users in Exchange environments without the security settings form had to endure prompts affecting everything from mail merge to customized Outlook forms to some PDA synchronization programs.
In Outlook 2003, properly constructed Outlook COM add-ins, published Outlook forms, and Outlook Visual Basic for Applications (VBA) code don't trigger security prompts when the code uses certain Outlook properties and methods. However, in Exchange environments in which the administrator has deployed the security settings form and registry entry, the security form settings still control the security prompt behavior. Users and administrators alike should be delighted with this "best of both worlds" approach, in which the administrator can still control the security behavior but standalone users regain control over their own VBA code and the many available Outlook COM add-ins.
Users, however, continue to get Outlook security prompts in VBA code in Microsoft Word, Excel, and other Office 2003 programs and in any programs external to Outlook that use Outlook programming objects. Why does Outlook VBA suppress prompts although other environments don't? In Outlook 2003, Microsoft implements Outlook VBA as a COM add-in. Therefore, like other Outlook COM add-ins, Outlook VBA doesn't generate security prompts. Note, though, that the security prompt suppression affects only Outlook objects. Developers who use Collaboration Data Objects (CDO) 1.21 in Outlook VBA or a COM add-in still see prompts when they use address-related or message-sending features in their code.
COM add-ins are a special type of application designed to integrate tightly with the hosting Office program. The key to developing an Outlook COM add-in that doesn't trigger security prompts is to construct it so that all the Outlook objects that the add-in uses are derived from the Application object passed in the OnConnection event that fires when the COM add-in is loaded. If the code creates Outlook objects in any other way, those objects' properties and methods will trigger security prompts. Outlook 2002 uses the same technique for "trusted" COM add-ins--that is, where the administrator uses the Exchange security settings form to specifically trust a COM add-in for all or a certain group of users. Consequently, a properly constructed Outlook COM add-in will work unhindered by security prompts when the Exchange administrator trusts it with a security form or when, in other environments, the user is running Outlook 2003.
In its article announcing the change, Microsoft notes that one of the reasons for suppressing the security prompts in Outlook COM add-ins is that Outlook 2003 blocks additional properties that earlier versions handled without security prompts. Specifically, any access to the body of a message or other Outlook item is subject to Outlook security in Outlook 2003. This blocking makes sense from a security standpoint because message bodies often contain email addresses. However, blocking the Body and HTMLBody properties without loosening restrictions on COM add-ins and custom forms probably would have broken the majority of Outlook COM add-ins and custom forms developed for internal corporate use. Developers of the many non-COM add-in programs that use Outlook objects definitely will need to take a look at how their applications behave under Outlook 2003.
"Important Security Notes for Microsoft Outlook COM Add-In Developers" http://msdn.microsoft.com/library/en-us/dno2k3ta/html/odc_olsecnotescomaddins.asp
