E-mail Records Management, Part 3: E-mail Retention

In my previous post, I described how organizations can define a set of e-mail classifications (i.e. managed folders) and how end users can use those folders to classify content. In this post, I’ll describe one of the main uses of this classification system: e-mail retention policies.

I mentioned in the last post that one of the first steps of an e-mail management plan is for a records manager to create a list of all the types of e-mail content within an organization. During this process, a records manager should also define the retention periods for each class of e-mail.

For instance, a records manager may decide that “Research and Development Design” e-mails should be kept for three years and then deleted. She may also define a broader and more generic class of content called “Long Term Business Need,” which might have the policy that e-mail must be kept for five years. Generally, the policies for e-mail will closely match the retention rules for managing documents in Microsoft Office SharePoint Server 2007. For example, both product specification documents and e-mail messages in the category “Research and Development Design” would be kept for three years and then deleted.

As you might expect, these e-mail retention rules are made concrete when a managed folder is assigned a retention policy for the mail inside it. This is done on Microsoft Exchange Server 2007 and the rules are enforced by Exchange, not Outlook. This allows an IT department to centralize the management and enforcement of the rules (e.g. deletion of the e-mail) without having to configure an application on each end user desktop.

The types of retention rules that can be defined are fairly broad. The event that triggers the expiration of an e-mail is based upon an auto-captured piece of metadata, such as the date the e-mail was sent. Exchange provides both move and delete as possible expiration actions (more on that below).

E-mail retention rules can also vary depending on the type of content in the folder. For instance, voice-mail messages might only be kept for 60 days, while e-mail message might be kept for a year. (As an aside, this allows policy decisions to be made based upon the medium and not just on the content itself. There was a really interesting comment thread that talked about whether that’s appropriate).

In addition, a records manager can also specify policies on non-managed folders, such as the Inbox and Sent Items folder. There is also a “default policy” that will be applied to all user-created folders. Generally, these policies should have a retention period shorter than the periods on the managed folders. This will encourage users to classify e-mail that they want to keep by moving it out of their Inbox and into a long term managed folder.

As it’s been described so far, the feature has only addressed the pure compliance scenario: non-important e-mail will be deleted; important e-mail will be kept for as long as there is a business justification for it. However, if we stopped there, we’d have introduced a major issue with our approach. This is the “So what did you do with my e-mail?” problem. Any e-mail records management solution should be sensitive to end users’ need to know what’s happening to their e-mail messages. We’ve done a couple things to address this.

Sharp-eyed readers of my previous post will notice one of the primary things we’ve done to make people comfortable with e-mail retention. We’ve provided records managers with a way to communicate the corporate policy on a folder. Within Outlook 2007, every folder displays a policy statement provided by the records manager:

Just like the Information Policy Bar in Word, Excel, and PowerPoint, this policy statement supports the communication of corporate policy directly within the Office applications. This is valuable irrespective of our policy enforcement features. Instead of having to visit a hard-to-find corporate intranet site or watch a video, users can learn about corporate compliance directly within the application they work with everyday.

Customers can also use a “recycle bin” approach as a backstop to prevent the accidental deletion of important e-mail. Before deleting an e-mail, Exchange can move it to a “Cleanup Review folder,” where it will sit for short amount of time (generally thirty days). With this approach, the user can visit her Cleanup Review folder, see what’s about to be deleted, and – if appropriate – move a particularly important e-mail to a managed folder with a longer term retention policy.

As you can see, our approach to managing e-mail is similar to our approach to managing documents in the Office SharePoint Server collaborative spaces. All files are classified based upon their content, and then an expiration policy is applied unique to the classification. In Office SharePoint Server document management, we focus more on user-collected metadata. With Exchange, we only have auto-populated metadata to work with. But it’s the same general concept for both.

In the next post, we’ll conclude our discussion of managed folders and talk about a couple of other types of policies that can apply to e-mail. Until then, keep the blog comments and questions coming!


Adam Harmetz

Program Manager

Comments (7)
  1. tpartridge says:

    So, does this mean that a records manager will need to create/maintain retention and disposition rules for email from within the Exchange Admin and then switch to a different admin application (SharePoint) to do the same for all other documents?  What happens if I save an MSG to a SharePoint site, do the rules there take precedent over the Exchange rules?

    Any plans to integrate these two administrative features into a single interface for Records Managers?

  2. Russell says:

    Have to say that this approach of managing the email format seperately from its other related content, and maintaining multiple rule systems seems a big weakness of MOSS 2007 if one was seeking to use it as a records management tool in a agency that had serious evidence, discovery and reuse requirements.  It has been discussed in other threads as Adam alluded to in the original post, but this is managing by format, encouraging the disassociation of recordkeeping context, and problematic to maintain.

    I believe that this will be a big barrier to MOSS 2007 meeting records management requirements for other than small to medium non-government organisations.  


  3. YoDJMC says:

    So if the records manager is creating a policy against an email, what policy is applied to any attachments? Whatever the argument about handling emails in special ways, the biggest challenge I feel is handling attachments – typically these are more likely to have specific meta data requirements, perhaps with the requirement for user captured data?

  4. NSherman says:

    I, too, am a bit concerned about the efficiency of having to manage two repositories. If I wanted to find all "stuff" relating to a certain person or project so that I could apply a litigation hold, would I have to go to two places? Would I have to review two places for all holds before I could authorize destruction? Having it separate, rather than together, seems to reinforce the mistaken idea that email and "regular" documents are two different things when it comes to retention.

  5. Sean Dillon says:

    I wouldn’t say the MOSS rules "take precedent" over the Exchange rules, they are really two different server infrastructures for managing two different types of digital content.  I would say you should/could use Exchange (w/o MOSS) for managing an organization’s *E-MAIL MESSAGES* using managed folders, retention, expiration, journaling, etc.  Exchange is not the place to manage other forms of digital content (documents, images, etc.) as records, that’s what MOSS provides.  Instead of managing e-mail records in Exchange, and all other digital content in MOSS, the strategy could be to use journaling in Exchange to move e-mail content over to MOSS, where *ALL* official records are kept.  Some organizations will want to do this for Exchange, but they won’t be using MOSS or vice versa.

    I’m not sure I would view having the flexibility of establishing Exchange policies AND/OR MOSS records management policies as a weakness; instead, I would say it gives organizations a choice to manage data where it makes the most sense given their information management requirements.  I think we do need to understand a little more about categorization of e-mail by content/context; that would help this discussion, as it might serve to show how MOSS could route those records appropriately within the records repository upon receipt of messages from Exchange based on the content/context of the message.

    Regarding attachments, I’m not sure if Adam is planning on discussing all the options you have around how/what to store from messages sent into the MOSS records repository or not?  I don’t want to steal his thunder, but know that there are a few different options here that might be of interest.

  6. Sean – Don’t worry about stealing my thunder, and thanks for the insightful comments.  =)  I agree with your comments about the need to provide compliance tools, no matter where the data lives.  Certainly flexibility was one of the key design tenants here – we are designing a platform that will meet the needs of millions of customers.

    I’m hoping that my recent fourth post on email records management (http://blogs.msdn.com/recman/archive/2007/02/08/e-mail-records-management-part-4-quota-management-and-sending-e-mail-to-the-records-center.aspx) answers the other questions in this comment thread.  We do indeed have a way of getting data from Exchange to SharePoint – where records can be managed consistently based upon the content, regardless of medium.

    Our design philosophy here was to provide tools to span the wide range of places where information might live and direct the important, high business value content to a Records Center, where it can be centrally managed.  

    Thanks all!

    Adam Harmetz

    Program Manager

  7. Hello folks, We can see many times in the Exchange Server 2007 documentation that we can keep information

Comments are closed.

Skip to main content