Email is playing an ever-larger part in lawsuits; in many cases, you need to protect email as you would any other personal or business document. Each organization needs to work with its legal advisers to determine how to address the mix of issues ranging from free speech and privacy to ownership and liability. Some companies keep a complete record of external communications, and other companies simply add to every message a disclaimer stating the company's email policies.
If you need to implement either or both of these solutions, Microsoft's Internet Mail Service (IMS) Extension DLL (imsext.dll) can help you. When you're using an Exchange Server 5.5 server, imsext.dll lets you add text to the end (append) or to the beginning (prepend) of your inbound or outbound SMTP mail. You can also journal inbound and outbound SMTP mail. (Don't confuse imsext.dll with imcext.dll, a tool that came with Exchange Server 4.0. In Exchange Server 4.0, you needed imcext.dll to give your Exchange server the ability to route mail, but Microsoft added that function natively in later Exchange versions.) Let's see what imsext.dll can do for you and how you install and configure this tool.
Disclaimers
A common reason that companies want to append or prepend text to messages is to add a disclaimer. Before Microsoft released imsext.dll, you could add systemwide disclaimers only by using custom programming or third-party products. Here's a typical disclaimer attached to an email message:
This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. This communication represents the originator's personal views and opinions, which do not necessarily reflect those of XYZ Company. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify postmaster@xyzcompany.
Disclaimers you add with the IMS Extension DLL are all or nothing. Unlike the journaling function, you can't turn disclaimers on or off for selected users.
Journaling: Exchange Server vs. Imsext.dll
Since Exchange Server 5.5 Service Pack 1 (SP1), Exchange has let you journal, or copy, mail to compile a record for later reference. (For more information about journaling and archiving in Exchange, see Mark Ott and Greg Dodge, "Enabling Message Journaling on Exchange Server," December 1999, and "Manage Saved Messages with the Exchange Archive Agent," February 2000.) However, Exchange implements the journaling function through the Message Transfer Agent (MTA). If your IMS is on the same server as your mailboxes and you want to capture the SMTP traffic, you must modify the IMS's behavior so that it routes all mail through the MTA instead of directly to user mailboxes.
In addition, SP1 journaling functionality captures all mail sent to and from a user, including internal communications. If your goal is to capture only the mail that the user sends or receives through the IMS, SP1 message journaling might not be the most efficient way to accomplish the goal. SP1 message journaling incurs a lot of storage overhead because it keeps all internally and externally generated messages. Imsext.dll lets you journal only mail that goes into or out of your system via the IMS. Imsext.dll journaling also lets you journal accounts selectively, whereas the SP1 journaling function journals all users.
DLL Installation
To implement any of imsext.dll's functionality, you must first install the DLL and configure the IMS to use it. Copy the DLL from the platform\Exchange\Web directory in the Microsoft BackOffice 4.5 Resource Kit CD-ROM to a directory on your Exchange server. Generally, the \exchsrvr\connect\msexcimc\bin directory is the best place.
Next, you need to register the DLL. To do this, open a command prompt, change to the directory where you saved the DLL, and type
regsvr32 imsext.dll
Now, you need to make the IMS aware of the DLL. The imsext.dll documentation tells you to use the custom routing program field on the IMS Routing tab, which Screen 1 shows, to hook the DLL into the system. Microsoft originally intended this hook to expand the system's ability to smarthost, or accept and reroute mail, for other systems. However, this method causes the IMS to lose some functionality that can help prevent unauthorized relaying. The sidebar "The Advantage of Installing Imsext.dll Through the Registry" explains what happens when you install the DLL through the IMS Routing tab.
If you've applied at least SP1, you can use an alternative activation method, in which you add a value to the IMS parameters in the Registry. This activation method lets the system complement instead of replace the existing functionality. When editing the Registry, take all the usual precautions; make sure you have a good backup of the Registry before proceeding.
To complete the DLL installation using this alternative method, use regedt32 to access the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\MSExchangeIMC\Parameters Registry key. Select the Parameters key, then create a new string value named NonRoutingExtensionDll. Double-click this value, and set the value data to be the filename and full path to imsext.dll. If you use the path I recommended, the full path is C:\exchsrvr\connect\ msexcimc\bin\imsext.dll.
DLL Configuration
You configure this DLL's functionality by editing the HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\MSExchangeIMC\Parameters Registry key. Create a new key called Extension below the Parameters branch, as Screen 2 shows. For each function you want to activate, you create a value below the Extension key. Table 1 lists the Registry keys that you use with the DLL. I'll explain how to configure the DLL to append text to all outbound mail and how to journal outbound mail for all users or just a few users. When you understand these configurations, you can use the resource kit's documentation to configure other combinations.
Adding Text to Messages
To append text, such as a disclaimer, to all outbound mail, you create a string value called OutboundAppend and set the value of OutboundAppend to contain the text you want to add to the end of your SMTP mail. If you want to add formatting to the text, you must use Rich Text Format (RTF) commands. Table 2, page 4, displays some common RTF commands that you can use. For more RTF codes, the Microsoft article "WD: Rich Text Format (RTF) Specification 1.5 Appnote (GC0165)" at http://support.microsoft.com/ support/kb/articles/q86/9/99.asp contains a link to GC0165.exe, which contains the full RTF specification.
A backslash (\) signals the start of a formatting string, and for this simple RTF example, a space signals the end. You must include a single-space between the RTF string and the text that it's controlling. For example, if you include the RTF string
\par\bThis message will self-destruct in 5 seconds\b0
and don't include a space between the bold on command (\b) and the word This, the system interprets \bThis as a formatting command. Because \bThis isn't a valid command, the system ignores these characters, and the resulting text is message will self-destruct in 5 seconds.
If the recipient is designated to receive mail with RTF, the IMS preserves the RTF commands (e.g., bold, underline, italics); otherwise, the IMS converts the message to plaintext and preserves only formats such as tab and new line. To make appended text stand out from the original message, include at least a few blank lines at the top of the appended text. To configure the other appending or prepending options, you just use other Registry values (i.e., OutboundPrepend, InboundAppend, and InboundPrepend). However, don't combine too many options because each one adds processing time to the message handling and too many additions can degrade overall system performance. Also, be aware that added text affects MIME digital signatures—the text alters the message after it's signed and, therefore, invalidates the signature.
Imsext.dll Journaling
Journaling is a little more complicated to configure. As with the text-addition functions, you must edit the Registry for the initial configuration. The first step is to decide where you want to store the journaled messages and where you'll send any nondelivery reports (NDRs) that Exchange generates if a journaling operation fails. The ultimate destination can be a mailbox (or a distribution list—DL) or a public folder. A good practice is to direct the NDRs to a DL. That way, you can easily change who is responsible for monitoring the reports. You can also specify a DL as the destination for journaled messages. A DL gives you the flexibility to change the journaling destination en masse if multiple users are journaling to the same location.
Consider these important points. First, journaling messages through the IMS preserves single-instance storage if you store the message in a mailbox on the same server. If you journal to a mailbox on a dedicated server or to a public folder (even on the same server), you'll duplicate items and will need to plan your storage appropriately.
Second, you use any standard email client to access the journaled messages. So, no matter where you store the journaled copies, you need to set the permissions on the mailbox, DL, or public folder so that it's not openly accessible. You might also want to hide the mailbox or folder so that it's not visible in the Global Address List (GAL). If you're using tools such as the Microsoft InterOrg Synchronization connector or Compaq's Lightweight Directory Access Protocol (LDAP) Directory Synchronizer Utility (LDSU) to synchronize your directory with other systems, make sure that the addresses of the journal recipients aren't included in the synchronization to the other systems. Widespread publication of journal destinations could jeopardize their security.
After you've decided on a destination for your journaled mail and created the mailbox, DL, or folder, you must determine the mailbox's, DL's, or folder's distinguished name (DN). Exchange uses DNs to uniquely reference each object in the Information Store (IS). You determine the DN by combining the organization and site names with an object's directory name and the name of the container or container tree where it resides. If you don't have the correct DN, you'll generate NDRs and excessive application log activity or—worse—you might journal mail to the wrong mailbox!
To make sure that you have the correct DN, use the Microsoft Exchange Administrator program's raw mode to access the object's properties. Raw mode is especially valuable if you want to journal to a public folder. A public folder's DN ends in a long sequence of letters and numbers that you can learn about only by viewing the DN attribute in raw mode. However, using raw mode is akin to editing the Registry, so be careful when you use it—if you don't know what you're doing, you can easily corrupt your system.
To enter raw mode, start Exchange Administrator with the /r switch (admin.exe /r). Highlight the journal destination (i.e., the mailbox, DL, or public folder object that will contain the journaled messages), and select File, Raw Properties. Scroll through the list of Object attributes, and select Obj-Dist-Name. On the right side of the object's Properties sheet, the DN appears in the Attribute value field, as Screen 3 shows. Select and copy this text, and save it to Notepad; click Cancel to exit the Raw Properties view. Repeat this operation for the DL that will receive any NDRs that the journaling process generates.
Specifying Outbound Journaling for All Users
To journal outbound messages for all users that the IMS serves, use regedt32 to open the newly created Extension subtree (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\MSExchangeIMC\Parameters\Extension). Create two new string values named OutboundJournal and OutboundJournalNDR. Using the DNs that you copied to Notepad, set the values of these keys to the DN of the journal destination and the journal NDR DL, respectively. For example, set OutboundJournal to /o=ORG/ou=SITE/cn=Recipients/cn=journal and OutboundJournalNDR to /o=ORG/ou=SITE/cn=Distribution Lists/cn=MSXadmins. After you set these values, restart the IMS.
To configure inbound journaling, you simply add the InboundJournal and InboundJournalNDR Registry entries. If you journal in both directions, you can use one journal recipient for inbound messages and another for outbound messages, or you can use the same recipient for both inbound and outbound messages. If you use the same recipient, just specify the same string value in the appropriate Registry key.
Journaling Specific Users
Journaling specific users requires a slightly different approach. In the Registry, you specify the field in the user's mailbox properties that will hold the DN of the journal recipient. When the IMS receives mail, the DLL checks whether the user's mailbox properties define a journal recipient. If the properties define a recipient, the DLL will journal the mail to this recipient. This arrangement lets you specify a different recipient for each user or group of users. To implement this arrangement, follow these steps:
- Decide which field in the mailbox properties will hold the journal recipient's DN. Good choices are one of the first 10 custom attributes or the administrative note. Make sure that the field you choose is not being used for another purpose and that it doesn't already contain data. If anything other than a valid DN is in this field, the DLL will generate an NDR.
- Run Exchange Administrator in raw mode. Choose View, Raw Directory to display the Schema container in the container tree to the left. You must be extremely careful when working with the Schema container. Select the Schema container to display the fields from the Directory Store in the Object attributes window. Locate the field that you've selected to hold the journal recipient's DN. For example, locate and select Custom Attribute 10. From the File menu, choose Raw Properties. Select MAPI-ID from the Object attributes window, as Screen 4 shows. Write down the decimal number (e.g., 32822) in the Attribute value field, then click Cancel to exit the Raw Properties view. If you use the Administrative Note property (i.e., select Admin Note from the Object attributes window), the MAPI-ID property would have a value of 32842.
- Use regedt32 to create the OutboundJournalNDR string value below the Extension key. OutboundJournalNDR specifies the destination DL, mailbox, or folder for NDRs resulting from the journaling operation. Set the value of the key to the DN of the DL that will receive any NDRs (i.e., the second value you copied into Notepad).
- Before creating the OutboundRecipJournalProp Registry key, you must convert the MAPI-ID property from decimal to hexadecimal representation. The easiest way to do this is to use the scientific calculator function of calc.exe. Run calc.exe, and enter the number that you recorded from the MAPI-ID property (i.e., 32822). Click Hex, which results in a hex value of 8036. The DWORD (double word) values in the Registry are 4 bytes, or two words, long. The DLL expects the MAPI-ID property to be in the high, or left, part of the DWORD value. The low, or right, part needs to be zero (0000); therefore, the number that you enter into the Registry when you make the definition is 80360000. If you did the same conversion for the Admin Note MAPI property ID, 32842 would become 804A0000.
In regedt32, create the OutboundRecipJournalProp DWORD value below the Extension key. Outbound-RecipJournalProp specifies the MAPI-ID property of the field in the user's profile in which you will specify the journal recipient. Double-click the new value, and enter 80360000 into the Data field, making sure you've selected Hex, as Screen 5 shows.
- For each user you want to journal, use Exchange Administrator to enter the DN of the journal recipient into the user's mailbox properties. In this example, you enter /o=ORG/ou=SITE/cn=Recipients/cn=journal into Custom Attribute 10 of each user you want to journal. If you specify nothing in this attribute, the DLL doesn't journal the user's mail. If other data (e.g., the employee's birth date) is stored in this attribute, the IMS will generate an NDR.
If you want to journal many users, you can use Exchange Administrator's import function to update this information en masse. If you're using a custom attribute field to store the DN, you must use the DS Site Configuration properties to rename the field because the import and export functions don't recognize Custom Attribute 10 as a valid import header. If you rename the field to Journal Recipient or a similar label, you can reference this field in an import field.
- Stop and restart the IMS to activate the changes. If you decide later to journal other accounts, you simply enter the DN of the journal recipient into Custom Attribute 10. You don't need to restart the IMS unless you to edit the Registry settings.
Other Recommendations
When you use these functions, you need to monitor the system to see how much they affect performance and storage. If you decide to implement journaling, you probably won't want to journal everyone into the same mailbox or folder, but you also won't want to create a separate journal recipient for every user. Create several journal recipients and use DLs to route the journaled messages. Develop a scheme for deciding which journal recipient to journal a mailbox to. You might decide to journal by division, job function, management level, or some other category unique to your company. Just keep the scheme simple and flexible—especially if people change positions or divisions frequently.
Be sure to obtain management's approval before you implement any of these functions, and make sure that management informs users if the company decides to journal. If you add disclaimers, run the text past your legal advisers to make sure the message is adequate and appropriate. You're probably implementing these features because you believe that they'll protect the company. However, remember to protect yourself, too; management, not IT, must set company policy, especially with regard to policing user activities.
