Reading Other People s Mail

Under some circumstances, it might be necessary for you to grant one user access to another s mailbox. Of course, users can always allow another to read their mail by granting delegate access, but generally when the messaging administrator gets called in, it s for one of two reasons: managers suspect a user of doing something wrong, or someone needs access to the mailbox of a user who has left the company, died, or gone on sabbatical to Timbuktu.

There are legal implications of reading other people s mail; my own personal guideline is that I wouldn t do so unless I had a written request from a properly authorized officer of the organization, countersigned by the organization s legal department, and that I would grant that person access and then leave the area ” after all, the last thing I want is to see whatever incriminating mail might be in the mailbox. Besides the potential consequences of learning deep, dark secrets, there s a more practical consideration: people generally trust administrators not to abuse their powers (even though they can easily do so), because an untrustworthy administrator can do a great deal of damage. You have a responsibility to uphold that trust, and to do whatever you can to prevent unauthorized access, including not granting it carelessly to anyone who asks. (For more information on the actual legal repercussions of accessing other users mail, see Chapter 20, The Law and Your Exchange Environment. )

Using Message Journaling

Exchange 2000 Server and Exchange Server 2003 have the ability to journal messages, or copy them to a location you specify. This is useful for archiving and retention, but it s also useful for monitoring e-mail. Journaling applies to an entire mailbox database; once you turn it on for that database, all messages sent or received by mailboxes in that database are copied to the journaling location you specify. Of course, this presents a couple of challenges. First, be selective. If you don t need to capture mail for many users (for example, if you re just targeting a user or two for monitoring), put them in a separate mailbox database, then enable journaling on the new database. In fact, you can create a database just for journaling and move mailboxes into and out of it as your monitoring requirements change, and when no one s being monitored you can dismount the database altogether. Second, ensure that the destination location, which can be a mailbox or a public folder, can keep up with the volume of mail you ll be generating.

Enabling and using journaling is extremely simple: the only thing you have to do is select the Archive All Messages Sent Or Received By Mailboxes On This Store check box, then click Browse and select the mailbox or public folder that should receive the journaled messages (see Figure 9-1). Once you ve made this small change, you ll immediately see journaled messages begin to appear in the selected folder. Because these messages are copies of the original, you can modify or delete them without affecting the original users copies.

Figure 9-1: Turning on journaling allows you to see copies of all messages sent from or to mailboxes in the specified message store.

Granting Permission to Other Mailboxes

Sometimes journaling isn t the right solution. Because it only grants access to new messages that traverse the monitored mailbox store, journaling doesn t help if you need to read mail that s already been delivered. In that case, the simplest way to get access to the mail that must be inspected is to grant the inspector access to the target mailbox. As I mentioned earlier, this is something that you should be very careful about doing ”don t ever grant your own account such permissions, and do your best to distance yourself from the actual mailbox inspection.

The basic requirement to gain access to another user s mailbox is simple: the inspector s account must be granted Receive As and Send As permissions on the target mailbox. As you might remember from Chapter 7, Installing Exchange with Security in Mind, when granted together, these permissions effectively give complete access to the specified mailbox, so you shouldn t assign them lightly. The actual steps to assign the permissions are simple:

1. Open the Active Directory Users and Computers snap-in. Choose the View Advanced Features command and make sure that it s checked; if it s not, you won t see the Security tab that you need to assign permissions on the mailbox.

2. Select the mailbox account you want to grant access to, then right-click it and select the Properties command.

3. In the Properties dialog box, click the Exchange Advanced tab. In that tab, click Mailbox Rights; the Permissions dialog box (shown in Figure 9-2) will appear.

   
   Figure 9-2: Add Send As and Receive As permissions to the mailbox.

4. In the Permissions dialog box, click Add to add the inspection account, then grant Read and Full Mailbox Access permissions by selecting the appropriate check boxes. Click OK to close this dialog box; you ll be back in the Properties dialog box.

5. Click the Security tab, which displays the discretionary access control lists (DACLs) on this particular mailbox. Click Add to create an access control entry (ACE) for the inspection account, then select that ACE and select the Receive As and Send As check boxes to grant those permissions on the mailbox. Click OK or Apply when you re done.

   Tip  

   You can t make these changes unless the account you re using has administrative privileges in the first place.

There s a complication to this process. In Exchange 5.5, the site service account had permission to read any mailbox. To eliminate this security flaw in Exchange 2000, Microsoft did away with the all-powerful service account, and they also added to an explicit deny ACE for Send As and Receive As for administrator accounts; this change carries over to Exchange Server 2003. That means that if you add the Domain Admins or Enterprise Admins groups or accounts that belong to those groups as delegates to a mailbox, the explicit deny ACE trumps your explicit allow ACEs, and the privileged account won t be able to read the mailbox.

There are two ways to resolve this problem. The first, and best, is not to use administrative accounts for mailbox inspection ”leave that to the human resources or legal departments, or to someone in the target s management chain. If that won t work, you can remove the deny ACE on the mailbox database, but this is an inferior solution because it allows administrators to give themselves Send As and Receive As permissions on any or all mailboxes in that database.

Tip  

Remember, when a delegate opens a mailbox, if the delegate reads a message that has a receipt request attached (including delivery receipts and return receipts), the client might generate a receipt. This leaves a trail indicating that the mailbox is being monitored ”each sender gets two responses to receipts! To prevent this embarrassing problem, make sure the people who are granted delegate access turn off their mail client s ability to return receipts, and consider using a product like Grinning Shark s Watch Your Back ( http://www.grinningshark.com ) to give the mail inspectors fine-grained control over receipt generation.

Using the Archive Sink

Microsoft provides a prebuilt event sink that you can use to archive e-mail going to, or sent from, a particular server. This is a nice complement to the message journaling feature, because by careful mailbox moving you can specify individual mailboxes to monitor. However, the archive sink requires more effort on your part, because you have to download it, install it, and configure it before you get any benefit from it. The first step is easy: visit http://www.microsoft.com/exchange/tools/2003.asp and download the archive sink itself or the entire tools bundle.

The first step in effectively using the archive sink is to understand how it works. The sink takes advantage of two separate events that can be fired during transport processing of a message: OnMessageSubmission and OnPostCategorize. The differences between these two are subtle, but important:

• OnMessageSubmission can be fired only once per message. It occurs when the message is first submitted to the SMTP engine for processing. These messages are sometimes referred to as precategorizer , or just precat , messages, because they haven t yet passed through the categorizer stage of the queuing engine. By default, when you install the event sink, all messages are archived when this event fires.

• OnPostCategorize events occur after the message has been categorized. The categorizer is responsible for expanding recipient addresses (including distribution groups) and determining which recipients are local and which are located on other servers. By default, the sink doesn t archive these messages; the reason for this decision is that a message can be bifurcated (or cloned) as part of the categorization process. This is most commonly required when a message is being sent both to local and Internet recipients. After the bifurcation , each copy of the message fires an OnPostCategorize event. If you set the archive sink to catch messages based on this event, you might end up with multiple copies of some messages.

There s no difference in the message contents between these two approaches. The archive sink creates files named ARCH_X.eml, where X is a random hex number, for the archived messages. Messages caught by the OnPostCategorize filter will be named ARCH_POSTCAT_X.eml instead, so you can easily separate messages that might be duplicates.

Installing and Uninstalling the Archive Sink

The archive sink is implemented as a Win32 dynamic-link library (DLL), but Microsoft has provided a VBScript (archivesink_setup.vbs) to ease installation and removal of the sink. The most important thing to understand about the installation process is that the sink can be installed on multiple SMTP virtual servers, but to do so you have to rerun installation once for each virtual server. The overall syntax of the installation script is simple. You need to provide three pieces of information:

• A command, which can be Install, Uninstall, or Display.

• The ID of the virtual server, which will be an integer. If you only have one SMTP virtual server, the ID will be 0.

• The optional location of the archive directory. This must be a complete path to a local directory; if you specify a Universal Naming Convention (UNC) path, you ll find that no messages are archived. If you omit the path , the sink will archive messages in the system temporary directory (usually %windir%\Temp).

The setup script creates a number of registry keys that provide the default behavior sink behavior: messages are archived at submission, and system messages (like those used to replicate public folder traffic) are ignored.

Configuring the Sink

There are several registry values created by the script; all of them are stored under the following key:

 HKLM\SOFTWARE\Microsoft\Exchange\ArchiveSink 

Each SMTP virtual server will have its own subkey , so the default settings will actually be under

 HKLM\SOFTWARE\Microsoft\Exchange\ArchiveSink. 

The most significant keys are these:

• The Smtp Messages value specifies where SMTP messages will be stored. The corresponding Mapi-Gateway Messages value specifies where MAPI messages should be archived.

• The DWORD Enable Smtp Messages value is set to 1 by default, indicating that the sink should catch SMTP messages. Likewise, the Enable Mapi-Gateway Messages key controls the archiving of MAPI format messages.

• The Archive System Messages DWORD is set to 0 by default; set it to 1 if you want system messages archived. Be forewarned that this will cause your archive directory to fill up with lots of uninteresting replication messages.

• The Enable Precat and Enable Postcat DWORD values control which events the sink uses to catch messages. By default, the precat flag will be set to 1 and the postcat value to 0; if you want to turn on the postcat sink, you ll have to manually reset the value.

• The Enable Message Logging DWORD flag is set to 0; if you set it to 1, the sink generates an Extensible Markup Language (XML) file for each message. The file contains a list of the envelope recipients, including BCCs, the Internet Message-ID field, and the subject.

You can edit these keys to get the behavior you want, but you ll have to stop and restart the IISAdmin service before the changes take effect.