|
|
Outlook Forms 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.
The main issue for Outlook developers, the
security prompts, affects VBScript behind Outlook
forms as well. For information on dealing with the
security prompts, see:
This page covers strategies for dealing with
other security issues related to Outlook custom
forms and reviews
the differences among Outlook versions.
Trusted forms |
One-off forms |
Blocked ActiveX controls
| Forms in other mailboxes |
More information |
Trusted forms
|
In Outlook 2003, code on published Outlook
forms that have not one-offed (see
below) is
trusted. Normally blocked properties and
methods will not trigger security
prompts, as long as all objects are derived from the
intrinsic Application and Item objects
available to form VBScript code. |
|
|
 |
One-off forms
|
Code will not run on items created from
unpublished or one-off forms, and in Outlook
2002 SP3 and Outlook 2003, some
ActiveX controls are
blocked. The one-off issue affects:
- Items created with saved .oft file
templates
- Items created with forms that were
published with the Send form definition
with item box checked
- Items created with properly
published forms that later one-offed
because of code behind the form or the
additional of a custom property
To ensure that a form does not one-off:
-
Make sure the Send form definition
with item box on the (Properties) tab
of the form is not checked. Whenever
you publish a message form, Outlook will
suggest that you may want to check the
Send form definition with item box to
ensure that the recipient will have the
form, especially if you're sending to
someone via the Internet. In the current
Outlook security environment, this
suggestion is obsolete and misleading.
Ignore it unless your form has no code
behind it.
-
For in-house corporate use with
Exchange Server, publish a message form
to the Organizational Forms library.
Publish other types of forms to
Organizational Forms or a public
folder's forms library, as appropriate
for your application.
-
For collaboration via the Internet,
publish your form to your Personal Forms
library. Save it as an .oft file and
send it to other people who need to use
it with instructions to publish it with
the same form name that you used. It is
also possible to publish forms
programmatically; see
Distributing Microsoft Outlook Forms.
-
On a custom message form, on the
(Actions) tab, set the custom form for
the Forward action to the same class as
the original form. In other words,
publish the form, then go to the
(Actions) tab, set the Forward action's
form to the same class, and publish a
second time.
Many things can cause one-off
forms. If you are still getting one-offs
after publishing as described above, see
Saving and
Publishing Microsoft Outlook Custom Forms -
One-Off Forms
for possible causes.
|
|
|
|
Blocked ActiveX Controls
|
Outlook 2002 SP3 and Outlook 2003 add restrictions on
which ActiveX controls will run on one-off
forms. In Outlook 2003, only the basic form controls (text
box, combo box, etc.), message body control, recipient control, and
Outlook View Control will load on a one-off form. In Outlook 2002
SP3, ActiveX controls not marked safe for
scripting will not load.
If a blocked control is present, when the user attempts to display the page
showing that control, they'll see this error message:
To help prevent malicious code from running, one or more
objects in this form were not loaded. For more information,
contact your administrator.
The ideal solution for this issue is to avoid one-off forms
completely. If you must use a one-off and you are using Outlook 2003, you can use a registry entry
or policy to control the behavior. (This option is not availble in
Outlook 2002 SP3). To use a registry entry, add a DWORD value named AllowActiveXOneOffForms to the HKCU\Software\Microsoft\Office\11.0\Outlook\Security
value and set it to one of these values:\
| 0 |
|
Load only the frm20.dll controls, the
Outlook View Control, Outlook Recipient Control, and the
docsite (message body) control |
| 1 |
|
Allow only controls marked as "safe for
initialization" to load |
| 2 |
|
Allow all ActiveX controls to load |
You can also use a policy to control this setting -- HKCU\Software\Policies\Microsoft\Office\11.0\Outlook\Security
with the same DWORD value and allowable values.
For more information see the Office 2003 Resource Kit article,
How Policies Work, which also has a good description of the
concept of “safe for initialization” ActiveX controls.
Note that published forms are not affected by this issue. If
you're seeing the error message above, that's a certain indication
that the form is now a one-off. |
|
|
 |
Forms in Other Mailboxes
|
Outlook
2002 SP3 and Outlook 2003 include a setting -- turned off by default -- to allow
forms in shared mailboxes to run script. In Outlook 2003 (but not
Outlook 2002 SP3), you can change the setting
by choosing Tools | Options | Other | Advanced Options and
checking the box for Allow script in shared folders. You'll
see that there is also an option for Allow script in public
folders. The corresponding registry values are in the HKCU\Software\Microsoft\Office\11.0\Outlook\Security
key -- SharedFolderScript and PublicFolderScript, both DWORD values.
Outlook 2002 SP3 does support the registry
values, but change the key from 11.0 to
10.0.
Note that these settings affect both script in custom forms for
items in public folders and script in folder home pages for such
folders.
For more information, see:
|
|
|
|
More Information
|
|
|
|
