Exchange Server 5.5 Service Pack 1

More than just another patch

By the time you read this article, Service Pack 1 (SP1) for Microsoft Exchange Server 5.5 will probably be available at http://www.microsoft.com/exchange. Microsoft doesn't produce service packs for Exchange very often because the product's code base has matured, so Exchange users have waited a long time for SP1.

SP1 includes important new features and bug fixes, most of which are already available from Microsoft's Product Support Services (PSS). Microsoft's inclusion of new features in SP1 isn't surprising. Exchange's next major functional release won't ship until after Windows NT 5.0 ships. Thus, Exchange 5.5 SP1 delivers features that help maintain Exchange's position as the most widely used messaging server for NT, while users wait for the next major Exchange release. Exchange's new features include the ability to send secure mail to users on other platforms and a message journaling function.

Interoperable Secure Email
Microsoft planned to overhaul Exchange's advanced security subsystem in version 5.5 but dropped the overhaul from the final release. Instead, Microsoft incorporated the security changes into SP1. These changes move Exchange from a proprietary security mechanism toward a security infrastructure that enables interoperability with other messaging systems. (For more information about email security in Exchange, see "Maintaining Secure Exchange Servers," October 1997.)

Secure MIME (S/MIME). Versions of Exchange before 5.5 SP1 use proprietary encryption and digital signature formats and implement mail security through Messaging API (MAPI) properties. When an Exchange server transfers a message to another platform, it strips the message of its MAPI properties, so previous versions of Exchange can't transport secure messages to other platforms.

SP1's security upgrades use S/MIME to create encrypted and digitally-signed messages that users on other platforms can access. Many email vendors, including Lotus, Novell, and Netscape, have agreed to build products that support the S/MIME standard, so Exchange can send secure messages to users on other platforms.

When users send encrypted messages through an SP1 server, their email client verifies that the recipient client uses advanced security. The email client translates the message content into encrypted body parts that look like standard MIME-encoded content. The Exchange server transports the message to its recipient. S/MIME is a MIME content type, so Exchange treats S/MIME content as a message attachment, like an audio clip or PowerPoint presentation. When the recipient S/MIME client receives the message, it decrypts the content from the S/MIME body parts.

Exchange has always been able to use the Internet Mail Service (IMS) to convert Simple Mail Transfer Protocol (SMTP) and MIME messages to or from Exchange's internal storage format. These IMS conversions work nearly perfectly, and they translate MIME content with a high degree of fidelity. But, the IMS is unacceptable for transporting digital signatures, because digital signatures must be flawless for recipients to accept them as valid. Exchange 5.5 introduces a Clients support S/MIME signatures option for the IMS, as Screen 1 shows. If you select the option, the IMS sends S/MIME signature information with the message content as one attachment. The IMS doesn't try to translate the attachment into Exchange internal format, but leaves the decryption of the S/MIME message and validation of the signature to the receiving client.

Older MAPI clients can't process S/MIME attachments. Users who receive a signed S/MIME message that their mail client can't process see an error message every time they read the email. By default, the Clients support S/MIME signatures option is off in Exchange 5.5 and SP1, so the IMS removes signature information before sending messages. Only after most of your users convert to an S/MIME client can you send signed S/MIME messages without risking recipient errors.

Security Certificates. In SP1, the Microsoft Certificate Server (part of the Windows NT 4.0 Option Pack) replaces the Key Management Server (KMS) as Exchange's certification authority. The Microsoft Certificate Server can act as the certification authority for all the mail platforms in an enterprise, issuing certificates in X.509 V3 format, which complies with the latest industry standard. Many vendors, including Netscape and Lotus, either support the X.509 V3 format now or plan to do so in the near future, so other messaging systems might understand certificates you create with SP1, and SP1 might understand other systems' certificates. This interoperability lets message recipients on other systems access your encrypted or digitally signed emails. You can also use keys that commercial certification authorities such as Verisign (http://www.verisign.com) issue. Expect to pay a small annual fee to commercial certification authorities for keys that are suitable for use with email.

You don't have to wait until the recipients of all your encrypted messages run Outlook 98 to use X.509 V3 certificates. Before your client sends an encrypted message, it determines whether the recipient client holds an X.509 V1 or X.509 V3 certificate and selects the correct format for your message.

Like previous versions of Exchange, SP1 stores public key information in certificates that are mailbox properties in the directory. Internet clients such as Outlook Express (since the release of Internet Explorer--IE--4.0) can connect to Exchange via Internet Message Access Protocol 4 (IMAP4) or Post Office Protocol (POP) 3 and send S/MIME-encrypted messages via SMTP. However, these clients must store and retrieve key information locally.

Outlook Express stores private key information in the Windows protected store. Outlook 98 stores private key information for X.509 V3 certificates in the Windows protected store, but it stores X.509 V1 certificates in .epf files. Outlook 98 can read and upgrade existing .epf files and use .epf files to import keys from and export keys to other PCs, so it can send encrypted messages via older versions of Exchange. Outlook 98 also supports the industry-standard .pfx format (also known as Public Key Cryptography Standards--PKCS--12) for import and export operations, so you can use Outlook 98 to export your private keys to a non-Microsoft client such as Netscape Communicator. Screen 2, page 160, shows Outlook 98's security settings.

To encrypt messages, Outlook 98 fetches public key information about message recipients from X.509 V3 certificates in the Exchange directory on an SP1 server. However, for correspondents who use other messaging systems, Outlook 98 users must store copies of security certificates in their local Contacts folder or offline address book (OAB). Outlook Express must store all public key information in its address book or fetch keys from a Lightweight Directory Access Protocol (LDAP) directory. The easiest way to obtain another user's public key is to receive an S/MIME message from the person and insert the certificate information into a contact record, but you have other options. You can use direct LDAP lookup or LDAP referral lookup to find an address through a certification authority across the Internet. You can set up interorganizational LDAP replication of key information. Or, you can manually import keys to and export keys from the Exchange directory via Comma Separated Values (CSV) files.

The Microsoft Certificate Server can issue Certificate Revocation Lists (CRLs). SP1 also supports Certificate Trust Lists (CTLs), secure mechanisms that let administrators centrally publish a trust policy that defines the set of organizations that the administrator's organization trusts. When one organization trusts another, clients in the two organizations accept signed messages from one another. However, a message sender's client still needs the recipient's public key to send an encrypted message, so you'll need to set up an arrangement clients can use to acquire other users' public keys.

You manage SP1 certificates through the Exchange administration program. The KMS provides secure key recovery when users lose their keys, distributes new keys that the Microsoft Certificate Server creates, and prompts users to obtain new certificates when their existing certificates' expiration dates draw near. The KMS also distributes keys you obtain from an external certification authority. You import keys from commercial certification authorities into the Exchange directory by creating a CSV file and using the Exchange administration program to import the data, or by writing bespoke code through LDAP, MAPI, or Active Directory Service Interfaces (ADSI). SP1 includes changes to the KMS user interface (UI), but it does not change the KMS's general approach to enabling a user for advanced security, including bulk enrollment.

Message Journaling
Rule 17A-4 of the US Securities and Exchange Commission (SEC) requires broker-dealers to retain physical records of transaction documents for 3 years or 6 years, depending on the record type. The SEC issued an amendment to rule 17A-4 in February 1997 that requires companies to consider email physical correspondence, which means every company in the US financial community must retain all email messages in paper or electronic form. Other US government agencies enforce similar requirements. The FBI requires companies under investigation to retain email messages for 6 months. Florida requires all government email correspondence to be available to the public.

These regulations pose interesting challenges to messaging vendors, who must develop procedures for retaining copies of all a system's email messages in journals. Those vendors' foremost challenge is determining where in the system to intercept messages to make copies of them. Journaling systems must capture all interpersonal email, including messages to local recipients and messages users send to external recipients via a connector. Journaling software must ignore system messages, such as replication messages for the directory and messages that users post directly to public folders. Setting up a journaling system on client machines isn't desirable, because such a setup would require you to install and maintain code on every client on your network. SP1 offers a server-side journaling solution for Exchange.

Journaling setup. SP1 captures messages for journaling through Exchange's Message Transfer Agent. MTA handles all messages to external recipients, and you can set Registry parameters to redirect all local mail (which passes through the Information Store by default) through the MTA. You must set these parameters on each server that you designate to journal messages. To route messages through the MTA, set the key HKEY_LOCAL_MACHINESYSTEM CurrentControlSet ServicesMSExchangeIMCRerouteViaStore to a value of 1. You must also disable the Information Store's local delivery by setting the key HKEY_LOCAL_MACHINE SYSTEMCurrentControlSet ServicesMSExchangeISParameters SystemNo Local Delivery to a value of 1.

Next, you must designate where you want journaled messages to go. SP1 can send messages to a mailbox or public folder. To set up a journal location, go to HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ServicesMSExchangeMTAParameters, add the value entry Journal Recipient Name of type REG_SZ, and set the value to the string that contains the distinguished name (DN) of the journal location (for example, /o=Digital/ou=Dublin/cn=recipients/cn=Archive). For more information about setting DNs, see "Maintaining Secure Exchange Servers," October 1997 or Craig Zacker's sidebar, "How to Name and Place Objects in the Directory Information Tree," October 1997.

Finally, you must decide whether you want Exchange to journal messages on an organization-wide, sitewide, or server-specific basis. (Keep in mind that journaling is not effective sitewide or organization-wide until you install SP1 on all relevant servers, because only the servers with SP1 installed will participate in the journaling process.) By default, Exchange sends all the journal messages for the server you make the Registry changes on to the address or folder you designate in the Journal Recipient Name entry. If you want to set up journaling on a sitewide basis, go to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSExchangeMTAParameters, add the value entry Per-Site Journal Required of type DWORD, and set the value to 1. If you want to set up organization-wide journaling, set the value to 0.

Journaling procedures. When SP1's MTA captures an interpersonal message, it makes a copy, marks the copy as a journal copy, and redirects the copy to the journal location. Journal copies have low priority, so Exchange always processes other message traffic first. Exchange does not decrypt journal messages, so encrypted messages reach the journal location intact. If a regulatory authority needs to read an encrypted journal message, the message's original recipient must provide his or her private key to decrypt the content.

You need to carefully monitor messages in your journal location so that the journal doesn't exceed storage limits. In addition, you must hide the journal location from the Global Address List (GAL) so your users can't access or alter the journal's contents. From time to time you might need to move the journal's contents to a more permanent location, such as a CD-ROM. Exchange doesn't automatically perform this transfer process; you have to establish separate procedures to export messages from the journal location. For example, you might arrange to move messages periodically to a backup tape and then delete them from the journal.

Because SP1 is new, no substantial body of data exists to help you assess the potential impact of journal message routing on your system's performance. According to Microsoft tests, journaling places an additional load on servers, but that load doesn't severely affect most servers unless they are already under heavy stress. I expect journaling in Exchange to generate server loads similar to server-based virus checkers' loads, but journaling's effect will vary from server to server. If your system is working close to capacity, routing local messages through the MTA will increase the time Exchange requires to deliver messages. Otherwise, users are unlikely to notice a degradation in delivery times.

Before you implement journaling, you need to make sure the server that hosts the mailbox or public folder that will serve as your journal location has enough disk space to hold your server's, site's, or organization's messages. Because email recipients read and quickly delete many messages, you might have trouble predicting how much disk space journaled messages will require. To calculate your system's journal space requirement, observe the journal's growth during the first days or week after you enable journaling. If you can project that your system will handle approximately the same volume of messages throughout the year as it did during the observation period, you can calculate the space your journal requires for storage of a year's messages.

Despite its functionality, SP1's message journaling isn't very user friendly. Microsoft has built journaling technology into Exchange but has left a door open for other software vendors to create complete applications that improve on Exchange's journaling.

SP1's Other New Code
SP1 includes other new features, such as IBM PROFS, IBM SNADS, and Lotus Notes connectors for Alpha processors. SP1 includes a migration tool that moves Lotus Notes personal databases into Exchange. It also includes Outlook 98 for Macintosh.

The service pack contains a wizard that transforms Outlook forms into HTML so users can view them via Outlook Web Access (OWA), the Active Server application that connects Web browsers to Exchange. SP1 also includes enhancements to OWA. Users can now use a browser to change their NT password, access their local Contacts folder, and check names on a message before sending it (a function similar to MAPI clients' Ctrl+K shortcut).

SP1 updates the Exchange administration program to provide a UI for controlling outside efforts to deliver unso- licited email or relay messages through your system. Exchange 5.5 includes a feature that can block unsolicited email, but you control the feature through Registry settings.

The MTA in SP1 supports both Eicon and CIREL X.25 connections. CIREL is a popular standard in France. Currently, CIREL doesn't interest most members of the wider messaging community, but Microsoft based Exchange's CIREL implementation on standard Windows Sockets (Winsock). By building more code to support standard interfaces such as Winsock, Microsoft has taken a step toward increasing users' choice of Exchange connections.

SP1's Move Server utility can change a server's naming context within an organization--for example, moving a server from one site to another or from one organization to another. It's too early to say how effective such a utility will be in practice, but I will explore the possibilities in a future article. SP1 updates the Information Store so that a server can report how much free disk space it has as a daily event log entry, which helps you avoid running out of space.

Finally, SP1 contains Exchange routing objects, which are objects that work with the Event Service to implement simple parallel and serial routing workflow applications. The service pack includes documentation, updated code, and a routing wizard (which Screen 3 shows) to enable workflow for a folder. These routing features are also available from Microsoft's Web site (http://www.microsoft.com/ithome/resource/exchange/active/default.htm). Microsoft introduced this functionality in Exchange 5.5 and enhances it in SP1 by adding a routing engine that can deliver items to users according to defined paths. You can apply the code to any Exchange 5.5 server.

Some of SP1's new features are still undergoing extensive development. Nevertheless, these features are useful for helping systems administrators work around poor organizational design. SP1's interoperable secure mail and message journaling capabilities fill important holes in Exchange 5.5. In addition, the service pack's inclusion of simple workflow routing for Exchange helps Microsoft chip away at another of Lotus Notes' advantages.