10.6 Archiving messages | Microsoft Exchange Server 2003 Administrators Pocket Consultant

< Day Day Up >

U.S. SEC rule 17-4A requires brokers and dealers to retain physical records of documents relating to transactions. The retention period is either three or six years, depending on the category of record. The SEC issued an amendment in February 1997 to cover email and stated that companies must treat email messages in the same way as paper correspondence. This requirement means that any company working in the U.S. financial community must retain all email messages in physical (printed on paper) or electronic form.

Other government agencies in the United States enforce similar requirements. For example, the FBI requires any company under investigation to retain messages for at least six months. The "Sunshine Law" enacted by the State of Florida requires that all government correspondence should be available to the public. This is similar to the situation in Sweden, where reporters are able to examine the prime minister's mail to see if anything interesting has arrived. The U.K. Civil Evidence Act (1995) lays down legal guidance for the admissibility of email as evidence in court cases. Other countries are likely to follow the lead established by the United States, United Kingdom, and Sweden, which poses an interesting problem for anyone who relies on email systems as a vital mechanism for internal communications. Indeed, the rise in popularity of Instant Messaging (IM) almost as a "behind the scenes" communication mechanism is largely because people say things when they communicate electronically that they would never say in public. The major advantage of most IM conversations is that they disappear into the ether as soon as the conversation is over, unless you use one of the IM applications that log conversations to comply with legal requirements.

As a concept, message journaling is not difficult to master. The major challenge is to determine the best place in the system to intercept messages to make copies. It is important that journaling can capture all email passing through the system-messages sent to local recipients as well as those sent to external recipients via a connector. A client-based solution is unacceptable, because it requires you to install and maintain code on every client. Server-side capturing is necessary to achieve any degree of scalability.

Message journaling was first featured in Exchange 5.5 SP1. Because it was part of a service pack (which means that no user interface changes are normally possible), Microsoft implemented journaling through a set of changes made to the Information Store, IMS, and MTA to force all messages to pass along prescribed paths so they could be copied into an archive location. There was no user interface, the documentation was sparse, you had to enable journaling through a set of system registry entries, and you could only capture messages rather than the complete set of items that can flow through an Exchange server. The journal location was normally a disk directory; you had to move manually the contents of the journal location to a more permanent location (such as a CD) on a regular basis.

Exchange 2000/2003 archiving allows you to:

Archive or journal messages for a Mailbox Store: You can instruct Exchange to capture all messages that it delivers to mailboxes in a particular Store by changing the properties of the Store to enable archiving and specifying where to capture messages. Archiving begins as soon as you click on the OK or Apply buttons, so this is something you do not want to do unless you are ready to handle the volume of messages that an Exchange server can capture daily. The destination can be either another mailbox (anywhere in the organization) or a public folder. You can also direct the messages to a contact that points to an SMTP or other external address, if you really want to have messages flow to an external location-which might be valid if some archiving software processes the messages when Exchange delivers them. However, you must enable archiving on each Store, since no server policy exists for this purpose. Best practice is to use a mailbox specially designated to capture and store archived messages, and this is required if you want to capture messages sent to BCC: addressees. Make sure that you allocate sufficient storage to whatever destination you use to hold archived messages and be sure to clear out the messages that accumulate regularly. (See Figure 10.29.)

Figure 10.29: Enabling archiving on a Mailbox Store.
Capture incoming and outgoing messages: You can implement a transport sink to capture copies of all incoming messages as they pass through the transport engine. You will have to write the code in the transport sink yourself or seek a commercial product for this purpose.
Implement user-based Outlook archiving: Users can decide to archive their own messages to Personal Folder Files (PSTs) on a regular basis.
Deploy third-party products and add-ons: A variety of commercial products exists to add full-feature archiving and retrieval functionality to Exchange, including the KVS Enterprise Vault (www.kvsinc.com), Enterprise Email from Persist Technologies (www.persistcorp.com), and IXOS eCONserver (www.ixos.com). These products can capture large quantities of email traffic and utilize Hierarchical Storage Management (HSM) systems to enable fast access to specific messages. Apart from archiving messages, these solutions also focus on the benefits of clearing old messages out of user mailboxes to reduce the size of Store databases and thus the amount of administrative work required to maintain Exchange servers.

If you want to use the standard mailbox archiving, it is best to gather all the mailboxes that you need to capture mail for into a single Store or storage group rather than enabling archiving on many different Stores. Make sure that you allocate enough mailbox or public folder quota to the selected destination, since it fills up quickly, especially on a busy server. Encrypted messages pose a specific challenge for any archival system. Because the archiving software captures and stores messages in the same form as they pass through the messaging infrastructure, they end up in the archive in encrypted format. The archiving software cannot attempt to decrypt the content, because it has no access to the private keys used to secure the content. Administrators can recover keys for users who are enrolled in Exchange advanced security and can then use these keys to decrypt messages, but you can do nothing with messages secured with third-party tools such as PGP.

Before making any decision about what style of archiving to implement, make sure that the selected technology (Exchange or third party) meets any legislative requirements your company is subject to as well as the needs of the company. In addition, ensure that you incorporate archiving into the standard operating procedures for Exchange, so that operators check that archiving is working properly daily, that the archiving destination does not fill up, and that any transfer to a more permanent archiving location such as an HSM works. You should also consider procedures to recover messages from the archive and the conditions under which such recoveries are possible. For example, can a user request or initiate a recovery operation if the recovery requires an operator to locate and mount a tape or other removable media? Does the user need prior authorization from a senior manager? How do you factor archives into the organization's overall data retention policy? How long do you maintain archives and how do you dispose of the archives? Finally, how do you maintain user privacy and prevent administrators and other privileged access holders from having access to confidential information that is probably present in the archive? Answers should be in place for these questions before you implement any archiving strategy.

10.6.1 Internal snooping (but nicely)

Government inspectors and other investigators love to review the contents of Mailbox Stores, public folders, and archives during discovery actions. These operations are carried out under legal order and according to strict standards, and there is normally nothing that you can do except comply with the order and make the necessary data available.

Sometimes, it may be necessary for you to do some snooping of your own-always with prior authorization and backing from your management and usually in response to a management request. For example, let us assume that your company has received a complaint that someone is sending messages to a domain that you do not really want to correspond with, such as lotsofgirlsforfun.com. Alternatively, you simply want to ensure that users do not send messages to competitors. The easiest way to keep an eye on outgoing traffic is to enable message tracking on all servers and analyze the data that Exchange captures. This will reveal who is sending messages, the message subjects (if you enable tracking of subject data), and where the messages go. Commercial products can even produce detailed reports showing where traffic goes, ordered by domain and traffic volume and analyzed by week, month, or other period. If you do need to track message traffic for an extended period, you may have to increase the retention period for the message tracking logs (normally between seven and ten days), so you need to set aside disk space for this purpose.

A more proactive approach is to install content scanning software on your network to examine messages as they pass en route to external destinations. You might want to watch for key phrases relating to trade secrets that you want to protect, inappropriate language, or anything else that might damage the reputation of the company or expose it to legal action. Most scanners operate on SMTP gateways and two holes exist. First, you will not be able to interpret encrypted messages. Second, you will not be able to examine any message sent from one Exchange server to another within the organization if the messages flow across routing group connectors. Different scanning products have different capabilities, and it is entirely possible that some products will be able to satisfy your needs, so take the time to investigate current capabilities and ask some questions to identify likely products and then test them thoroughly. A product that includes a scan for viruses, blocks suspicious attachments (you may not want to send out ZIP and EXE files or anything called "STRATEGY.DOC"), and checks contents of messages is ideal.

If you find that someone is sending messages to an undesirable destination and you find out who this person is, you can then proceed to recover messages to determine what the user has sent. If you have implemented an archiving solution, you can retrieve the information from the archive (a commercial application is much easier to use in this respect than Exchange's own archiving functionality). If not, you will have to access the user's mailbox and hope that the incriminating messages are still there or that they can be retrieved from the deleted items cache. If the message is not in the mailbox, you can restore a backup to a recovery server and access the mailbox there.

It is easy to grant yourself the permissions necessary to open another mailbox. Either grant your own account Send As and Receive As permissions for the mailbox or create a separate account and mailbox for inspection purposes and allocate the permissions to it. Log on to the account, create a MAPI profile to point at the mailbox, and you now have access and can read to your heart's content. OWA is also a good choice to open mailboxes without requiring a profile. However, if the other user opens the mailbox, he or she may pick up signs that someone is poking around. For example, if you read a new message and fail to set its status back to unread, users may wonder why they never saw that new message. You can change the status of unread messages to "read" unwittingly if the reading pane is active. You may forget to delete the welcome message that Outlook creates when a new profile logs on to a mailbox for the first time. Users may see some notifications (delivery and read) in their Sent Items folder and wonder why Outlook generated these receipts if they never read the corresponding message. The same is true of calendar responses. Someone else may mention that he or she received a response from the user when it was known that the user was out of the office and did not read mail. You have to be careful; software such as GrinningShark's^[4] "WatchYourBack" product suppresses notifications.

Of course, if users have their email delivered to a PST on their laptop's hard drive, you will have difficulties checking their email with Outlook or OWA unless you can gain access to the PST.

The last situation is where you have a need to scan a complete server for content. Perhaps someone has taken an action alleging that your company has infringed a patent and a judge has ordered you to produce any email relating to the technology that may be the problem. Again, if you have an archiving solution in place, it should be easy to locate the relevant messages. If not, you can turn on full-text indexing for Mailbox Stores and go looking. Implementing indexing for a large Mailbox Store is not something to rush into, because it can affect server performance and generate a very large index, but if that is all you can do, you can certainly use a full-text index to locate messages. If you can focus in on a restricted group of users, you might be able to use the ExMerge utility to scan for messages with particular subjects or attachments. However, this is using ExMerge for a purpose well outside its normal scope; also, it is a crude instrument because it will not search content. The sole advantage of ExMerge is that it is free, but you can get much better functionality from commercial offerings such as GFI's MailEssentials for Exchange.^[5]

By far the most intrusive snooping is when you deploy software such as Spector Pro from www.spectorsoft.com. This technology can record IM conversations, the full content of email, Web sites that users visit, and even online chat. It supports email systems as diverse as hotmail and Exchange (Outlook). I do not like such technology and would only deploy it in dire situations when I absolutely need to find out what is happening and when I have absolute protection from lawyers.

Accessing anyone's mailbox is not something that you should rush into, and people are not going to be very happy if they discover that you have been rummaging around in their mailboxes. Searching a mailbox is a huge breech of user privacy, which can result in legal action of its own if you do not protect yourself by seeking authorization before doing anything. You may also want to leave the actual investigation to someone else, such as the person who requested access and has a good reason to look for specific messages. You can set up the account, allocate the necessary privileges, explain how to look for the information, and leave the investigator to do the work. This way, if anything happens, you will not be the person who looked at the contents of the mailbox and you can defend your position.

Best practice is to proceed only under very specific circumstances that comply with local legal standards for data protection and user privacy. Legal standards differ from country to country and it is not safe to assume that the procedures used in the United States will resist legal scrutiny elsewhere.

^[4] . www.grinningshark.com.

^[5] . www.gfi.com.

< Day Day Up >