Skip navigation

Message Classification

Computers are really good at some things, such as text-pattern matching. This has led to the rise of lots of applications based on pattern matching, from regular expression interpreters to keyword-based antispam filters. However, computers still aren't very good at the kind of linguistic and textual analysis required to reliably classify messages according to their content. "Message classification" usually refers to the activity of marking a message to indicate the nature of its contents. The markings used can be visible to the user or not, and they can be based on a standardized set of classifications (such as the US government's classification scheme for sensitive materials) or a custom set defined for a particular business or industry.

There are many automatic message classification systems on the market, most of which are optimized for particular environments. For example, Lockheed Martin built the RADIANT MERCURY system for automatically classifying messages for the US Navy; it's not available (or suited) for civilian use. These systems tend to be somewhat finicky, and many of them depend on having messages in a particular structure or format. In addition to these automated systems, several companies have developed client-side add-ons for Microsoft Outlook and other clients that let users select their own classification markings. (I helped develop one for Eudora, Outlook 97, and IBM Lotus Notes R4 back in the day.) The problem with client-side classification is that users might forget to, or decide not to, apply suitable classifications.

Despite these limitations, there's still a lot of demand for message classification tools. There are many cases where having message classifications applied is useful for business reasons. For example, having a method to mark messages "Attorney/Client Privileged" is important when determining which messages to include or exclude in a records discovery request. Likewise, it's useful to be able to mark messages that contain confidential or restricted information (although just marking them doesn't provide any real protection; for that you need something such as the Windows Rights Management Services toolset).

Exchange Server 2007 and Outlook 2007 provide two useful classification tools. Outlook 2007 can load a classification definition file (provided you enable a set of registry values on each client, as documented here) and display a classification menu that lets users apply classifications to individual messages as they see fit. The classification definition is a fairly simple XML file that must be generated on the Exchange 2007 server using the Export-OutlookClassification.ps1 script found in the Program Files\Microsoft\Exchange Server\Scripts directory. After you've generated the file, you can modify it and put it in a location where Outlook clients can access it. The process is a little rough in that you have to jump between the management shell on the Exchange server and Outlook on the clients to get it running; hopefully, Microsoft will provide better tools for this in a future release.

Client-side classification isn't enough by itself. With Exchange 2007, you can use transport rules to inspect and enforce message classifications. For example, you could create a transport rule that would NDR any message sent by members of the "Project X" group without a "Company Confidential" classification. Microsoft outlines the standard legal-oriented scenario in the Exchange 2007 documentation, explaining how to create a transport rule that will NDR messages sent to members of the "Legal" group if the messages aren't marked "A/C Privileged." There are lots of other interesting things you can do with transport rules, given that they can modify or redirect messages. For example, you could create a rule that would catch messages sent to external recipients that contain a certain word or phrase unless they had a particular classification.

Transport rules are terribly flexible, and next week I'll talk about a sticky situation that they can help resolve. I'm also throwing my Inbox open for your article and topic suggestions—if there's something you'd like to read about here, drop me a line!

TAGS: Security
Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.