Exchange Server 2003 OWA Overview

Today's mobile information workers might not always have access to the traditional Microsoft Outlook client. Therefore, providing a smart browser-based client has been a primary goal for Microsoft. With the release of Exchange Server 2003 comes an updated version of Outlook Web Access (OWA). The most recent version of the OWA browser client is based on the same architecture as earlier versions but provides significantly enhanced functionality and addresses the major concerns customers have voiced with respect to the earlier OWA implementations. Security is typically the major concern when you consider granting users Web access to your company's Exchange systems. When you let users access Exchange in this way, you have little control over the devices they use or their security practices, so providing a secure client was one design goal for OWA developers. Performance, richness of features, and compatibility with Outlook 2003 were also prime concerns. Exchange 2003 OWA's compatibility with Outlook 2003 means that a user's physical environment will have a minimal effect on how he or she uses email. Let's examine some basic changes to the OWA UI and some of OWA's new security and spam-fighting functionality.

User Interface
Like earlier versions, Exchange 2003 OWA supports two different UIs: premium client and basic client (previously known as the rich client and reach client, respectively). As the name suggests, you get more functionality with the premium client, which requires Microsoft Internet Explorer (IE) 5.01 or later. You must use the basic client with all other browsers, such as IE 4.0 and Netscape Navigator, and with IE 5.01 on a Sun Microsystems Solaris or HP-UX system because these clients don't support the various features such as Dynamic HTML (DHTML) that are used to build the premium client. Also, for the same reason, certain functionality such as spell checking and themes are available only for the premium client. Other functionalities, such as Secure MIME (S/MIME) and compression, require IE 6.0.

Figure 1 shows the premium client's UI. (You can see its similarity to Microsoft Outlook 2003 beta's UI, which Figure 2 shows.) OWA premium supports a reading pane, two-line view, one-click follow-up flags, and a new navigation bar that shows folder hierarchy and shortcuts together. The basic client is similar, but with less detail and functionality. OWA now supports a long list of languages including right-to-left languages such as Hebrew. The Microsoft article "XGEN: Languages That Are Supported by Exchange 2000 Server, Windows 2000 Server, and Outlook Web Access" (http://support.microsoft.com/?kbid=325001) lists the languages that OWA supports.

Exchange 2003 lets administrators force OWA users to use the basic client or to use a logon form to choose which client they want to use. You might want to force users to use the basic client for consistency's sake or in situations that don't require the premium version (e.g., when users are traveling and must use a slow network connection). Another situation in which you might want users to use the basic client is when they attempt to access their mailboxes through a firewall that blocks WWW Distributed Authoring and Versioning (WebDAV) verbs. The premium client uses WebDAV verbs extensively, but the basic client doesn't use them at all.

To force all users to use the basic client, you can add the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSExchangeWEBOWA registry subkey on the Exchange server. Set the value of the ForceClientsDownLevel subkey (of type REG_DWORD) to 1 to enable this feature (a value of 0 disables the feature). In a front-end/back-end configuration, set this key on the back-end server, which generates the HTML coding and passes it to the front-end server, which then sends the HTML coding to the client.

Creating and Modifying Server-Side Rules
For a long time, Outlook users have been able to define rules by using the Inbox Assistant or, more recently, the Rules Wizard. A rule's criteria determine whether it's a client-side or server-side rule. Client-side rules generally require some knowledge about the user and can therefore fire only when a client is present and logged on to a mailbox. Examples would be a rule that executes an application upon receipt of a message with particular attributes or situations in which you need to authenticate to a mailbox to perform an action, such as moving an item to a public folder. Server-side rules can fire with no user interaction and therefore don't require a client to be present. One example would be a rule that moves a new message into another folder within the user's mailbox.

The premium OWA client now lets you define server-side rules, although the criteria available for defining such rules is limited compared with the Outlook Rules Wizard. You can define a rule based on sender, recipient, subject, and importance, with possible actions being move, copy, delete, and forward.

You need to be aware of some incompatibilities between Outlook-defined rules and OWA-defined rules. These incompatibilities depend on the version of Outlook you use, so you should check the OWA Help (which has also had an overhaul in Exchange 2003) to ensure you understand the implications. Any rules that OWA can't interpret or act on are displayed in gray type so that you can see where incompatibilities exist.

Attachment Blocking
Email attachments can be a major security hazard. Malicious users use attachments for many different kinds of attacks. Recipients often don't know what's in an attachment and can unwittingly execute a harmful file. OWA deals with attachments in much the same way that Outlook does and addresses the problem of attachments being saved and left on public kiosk devices.

OWA and Outlook classify attachments according to their file extensions and MIME types. A Level 2 classification means that the attachment might be unsafe. The attachment is accessible, but you must first detach it from the message and save it to disk before you can open it. A Level 1—classified attachment is considered unsafe and is blocked with no way for the user to access it. All other attachments are considered safe, and you can launch them directly from the message.

OWA in Exchange 2000 Server Service Pack 2 (SP2) introduced Level 2 attachment handling, and Exchange 2003 OWA extends this functionality with Level 1 handling. In addition, administrators can configure OWA to completely disable attachments on particular servers regardless of any level settings. This feature is especially useful for situations in which users access their email from a remote computer or kiosk and you don't want to run the risk that the user will leave the attachment open for public viewing. Web Table 1 (http://www.exchange
admin.com, InstantDoc ID 39790) lists the registry subkeys that control attachment handling.

Outlook administrators might be familiar with a registry setting called Level1Remove. As its name suggests, this setting removes a file extension from a Level 1 attachment and moves the attachment to Level 2 attachment handling. This setting is a client-side registry setting, and no equivalent OWA functionality exists. OWA doesn't use client-side settings because the server generates the HTML interface before passing it to the client.

Web Beacons
A Web beacon is typically a graphic and embedded URL reference within the body of an HTML email message; the URL points to an external location such as a Web server. When a recipient opens the email message, the email client processes the reference and automatically connects to the external location. Junk-email senders can use this automatic beacon processing to determine that a user's email address is live and subsequently start bombarding the user with spam. Malicious users can also use Web beacons to automatically direct email recipients to potentially harmful code on the sender's Web site. For a good overview of Web beacons, see "Spam Beacons," September 2003, http://www.exchangeadmin.com, InstantDoc ID 39501.

As with Outlook 2003, you can configure Exchange 2003 OWA to prevent the client from automatically accessing external content when you read a message. Users configure this setting from the OWA Options page; however, while reading a message, the user can choose to unblock the external content. Administrators can force the blocking of external content, which also removes the UI from the options page and doesn't let the user unblock during a read. OWA's criteria for deciding whether content is external is different from Outlook 2003's criteria. OWA considers anything not within the email message to be external, whereas Outlook 2003 allows links to content in the Intranet Zone.

To set content blocking, navigate to the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSExchangeWEBOWA registry subkey and set the Value of FilterWebBeacons (of type REG_DWORD) to 0 to present Web-beacon filtering as an option to the user in the options page, 1 to force filtering and remove the UI, or 2 to disable filtering and remove the UI.

You can also indicate how the blocked content should appear when users read the message. To do so, navigate to the same registry subkey and set the WebBeaconFilterMode value (of type REG_DWORD) to 0 to display filtered images as broken links or 1 to display filtered images as clear .gif files (the default).

Junk Email Prevention
Outlook has always let users create rules to help identify junk email. In earlier Outlook versions, the criteria for these rules are based on junk-email sender lists that the end user sets up. These rules are server-side rules, which means that the Exchange server identifies and filters junk mail based on the sender. With Outlook 2003, users can now configure a client-side rule that causes the client to scan message content and assign the message a junk-email rating. This feature is useful in situations in which spam slips through because the sender or recipient isn't on the user's lists. The user can set options that use this rating to determine how the client processes a piece of spam (e.g., delete it, move it to a spam folder). Note that this client-side rule for checking message content works only when Outlook 2003 is running against an offline store (e.g., cached mode). Network overhead costs would be too high to retrieve the body of all mail messages for scanning when running in online mode.

Additionally, users can set up and manage lists of known junk-email senders, safe email senders, and safe email recipients. (You can use the latter to designate that messages sent to particular mailing lists are always to be trusted.) Users can export and import these lists and thus share the email addresses of known spammers.

In line with the goal of Outlook compatibility, OWA lets you manage your junk-email­sender and recipients lists and add senders to the list directly from an email message. This feature lets Exchange use server-side rules to filter incoming email based on sender or recipients. Unlike Outlook 2003, OWA can't invoke client-side rules, so it can't scan message content.

S/MIME Support
When security is a major concern, you'll likely want users to digitally sign or encrypt OWA messages. OWA uses a signed ActiveX control that users can download from the Options page to support signing and encryption. After users have downloaded this control, the New Message form uses the S/MIME protocol to create messages. Note that this functionality requires IE 6.0 and Windows 2000 or later—the download option won't appear unless these prerequisites are met. The base OS support is necessary because encryption and decryption occur through the standard Windows CryptoAPI application.

OWA uses the S/MIME 3 protocol for encryption and signing, but it also supports reading, replying to, and forwarding email messages that are digitally signed or encrypted according to the S/MIME 2 protocol. See Internet Engineering Task Force (IETF) Request for Comments (RFC) 2633 (http://www.rfc-editor.org/rfc/rfc2633.txt) for the S/MIME 3 message specification. Note that OWA supports the signing and encryption of email messages only—not calendar messages such as meeting requests.

OWA uses public key encryption to digitally sign and encrypt messages; therefore, a public key infrastructure (PKI) must be in place, and OWA users must be enrolled with valid certificates. OWA uses the recipient's public key (contained in the recipient's certificate) to encrypt messages. OWA retrieves these certificates from Active Directory (AD) or contacts stored in the user's mailbox. (Unlike Outlook, OWA doesn't provide any certificate management such as creating a contact from the message sender and storing the certificate with the contact.) OWA can encrypt email addressed to AD Groups and personal distribution lists (DLs) stored in a user's contacts folder. When a user adds recipients to a Create message window, Exchange resolves the recipients' addresses, retrieves their certificates, and uses their public keys to encrypt the message. Exchange performs all the certificate validation (such as checking the certificate revocation list—CRL—to ensure each certificate is still valid) so that the client doesn't directly interact with the PKI over the Internet.

If a recipient doesn't have a valid certificate, Exchange warns the message originator and gives him or her the option to send the message—even though the recipient won't be able to decrypt and read the message. When you view a recipient's properties from the Global Address List (GAL), which Figure 3, page 10, shows, you can see whether the recipient has a valid certificate and can read encrypted messages.

The sender also must have a valid digital certificate to be able to sign a message, and the S/MIME control interacts with Win2K to ensure that the sender has a certificate. You can store the certificate in the local certificate store (or anywhere that's accessible to the CryptoAPI application) or on a smart card, assuming a Windows-supported smart card reader is available on the machine OWA is running on. If OWA can't find a valid software-based certificate, it prompts the user to insert any hardware-based ID he or she might have available.

Users can use default options for signing and encryption or use the two buttons that appear on the Create message form. The options the user selects are stored in the http://schemas.microsoft.com/exchange/smimesign and http://schemas.microsoft.com/exchange/smimeencrypt properties in the user's mailbox. Administrators can also force message signing and encryption by setting the alwaysSign and alwaysEncrypt registry values (of type REG_DWORD) to 1. You'll find these values in the HKEY_LOCAL_MACHINESYSTEMCurrent-ControlSetServicesMSExchangeOWA subkey on the Exchange server.

The S/MIME control interacts with the Create message window. Messages created through this window have a different message class from other messages. (Email clients such as Outlook use a message's class primarily to determine how to display the message—for example, IPM.NOTE.SMIME instead of the usual IPM.NOTE.) Other message classes you'll see when the S/MIME control is in use are IPM.NOTE.SMIME.MULTIPARTSIGNED (e.g., when an attachment exists) and REPORT.IPM.Note.SMIME.MultipartSigned.IPNRN (e.g., for a read receipt generated from a secure message). Outlook uses the same message classes, so processing S/MIME messages with Outlook or OWA is fully supported.

The presence of the S/MIME control opens the door to other processing because fully formed MIME messages are now built on the client and submitted to the server. This approach lets you drag attachments onto a Create message window and simplifies attachment processing. Without the S/MIME control (which is available only with the premium client), you must browse for attachments and select the ones you want to add to or remove from the message. With the S/MIME control, you can use one click to attach a file, or right-click a file and remove it by using the context-sensitive menu that appears. You can also drag images directly into the body of a message, copy images from Web pages, and even drag a message from the folder view in OWA and embed it directly into your new message.

Forms Authentication
Users must enter their logon credentials (username, password, domain) to access their mailboxes and other resources over the Web. A browser caches these credentials and sends them to the Web server with each HTTP request. Otherwise, users would be continually prompted for credentials as they navigated around the Web—clearly not a desired scenario.

The credentials are cached for as long as the browser session (e.g., iexplore.exe, netscape.exe) exists, and the session exists until all windows opened during the session are closed. Herein lies the problem.

Consider the scenario in which a user uses OWA from a public kiosk, then walks away. If the user hasn't closed all the browser windows—something that's physically impossible on some kiosks—anyone could use the browser to navigate back to the user's mailbox without entering any credentials. The common human frailty of forgetting to log off correctly is the main reason for the introduction of forms authentication.

Until the release of IE 6.0 SP1, you had no guaranteed way to programmatically clear the cache without installing an ActiveX control on the client. Exchange 2003 OWA takes advantage of IE 6.0 SP1's cache-clearing functionality, which automatically flushes the cache when a user clicks the logoff button. This feature works fine in situations in which an administrator is in control of the browsers being used, such as inside the corporate environment. But what about situations in which administrators have no control over the browser being used, such as at public kiosks?

Forms authentication technology targets this public kiosk situation. The technology includes three main functional areas that address the vulnerabilities inherent in kiosk browsers.

Forms authentication works best in a front-end/back-end server setup. Although you can use the feature directly against a back-end server, a user might be redirected to the logon page if the user browses public folders for which the content is on a different server from the one that hosts the user's mailbox. I'm working on an in-depth article about forms authentication technology for a future issue of the newsletter, so I won't go into detail here about the mechanism behind the technology.

From the logon page, users can choose which client (premium or basic) they want to use and whether they're using a public device (e.g., an Internet cafe) or a private one (e.g., a home computer). The choice of public or private determines the inactivity timeout period, with the public device's inactivity period being shorter than the private one.

Gzip Compression Support
Gzip compression is built into Microsoft IIS 6.0. Therefore, Exchange 2003 OWA can take advantage of Gzip only when Exchange 2003 is running on a Windows Server 2003 system and when you're using a suitable browser, such as IE 6.0. Gzip compression also requires that you enable forms authentication—which helps ensure that the browser can securely handle compressed files. You can configure Gzip compression to compress static or dynamic data. Static content includes files such as Cascading Style Sheets (CSS) and scripts. Dynamic content is the HTML code generated in response to a request such as listing the contents of your Inbox.

Gzip compresses static content greater than 1KB in size on the server at first use and stores the compressed files in the IIS Temporary Compressed Files folder. Gzip compresses dynamic content as it's generated (such as listing the user's Inbox or reading a message).

Gzip works well for dial-up users. Because of its reliance on forms authentication, it compresses only Secure Sockets Layer (SSL) traffic. Hardware compression that modems perform can't compress SSL data, but Gzip compression is completed before the SSL layer, resulting in a smaller overall payload.

You use Exchange System Manager (ESM) to enable High compression (Static and Dynamic), Low compression (Static only), or None. (A drop-down list with these options is available when you enable forms authentication.) High compression adds about an extra 10 percent of the CPU load to the front-end server; low compression adds almost nothing to the load because after Gzip compresses the files, it caches them for subsequent reuse.

OWA for the Masses
The most recent OWA version offers many other functional improvements not covered here, such as spell checking, address-book enhancements, the ability to segment user options, and the ability to render simplified views of your Inbox and Calendar folders for inclusion inside portals such as those that Windows SharePoint Services delivers. I'll take a look at some of these enhancements in future articles.

Exchange 2003 OWA delivers on its promise of being a secure, easy-to-use, feature-rich Web client. The strength of OWA will drive Exchange 2003 deployments and encourage more customers to implement OWA internally and externally.