I could hear the frustration in her voice. “We keep going back and forth with the plaintiff’s lawyer. I don’t understand what he wants. Can you help us?”

Defense counsel was trying to satisfy an opponent bent on getting e-mail in “native file format.” With each disk produced, the plaintiff’s lawyer demanded, “Where’s the e-mail?” Now he was rattling the sanctions saber. Poring over copies of what she’d produced, defense counsel saw the e-mail. “Why can’t he see it?”

Reviewing the correspondence between the counsel, I spotted the problem. The e-mail was there, but in rich text format. Like many lawyers new to e-discovery, defense counsel regarded electronically stored information and native data as one and the same. They’re not.

The IT department had dutifully located responsive e-mail on the mail server and furnished the messages as RTF, a generic format offering easy access and electronic searchability. Any computer can read RTF, so it’s a reasonable choice. But it’s not the native format.

CONTAINER FILES

The native format for virtually all enterprise e-mail is a container file lumping together relevant, irrelevant, personal and privileged communications, along with calendar data, to-do lists, contact information and more. The precise native format depends upon the e-mail client and server.

The prevailing enterprise e-mail application, Microsoft Corp.’s Exchange Server, uses a container file with the file extension EDB. Lotus Notes stores its e-mail on a Lotus Domino server in a container file with the extension NFS.

These containers are the “native file format” for server-stored e-mail, but they hold not only all then-existing e-mail for a specific user, but also the e-mail and other data for all users. Furnishing these files is tantamount to letting the opposition rifle through every employee’s desk.

When enterprise e-mail is stored locally on a desktop or laptop system, it’s almost always in a container file, sometimes called a compound file. For users of Microsoft’s Outlook e-mail program (a “client application” in geek speak), the local container file is typically called “Outlook.PST” or “Outlook.OST.” There may also be a file holding older e-mail called “Archive.PST.” Collectively, these data are referred to as a user’s “local PST.”

Like their counterparts on e-mail servers, local container files weave together the user’s responsive and non-responsive items with privileged and personal messages; consequently, they’re more like self-contained communications databases than paper correspondence folders.

Because the native file format for enterprise e-mail is bound up with information beyond the scope of discovery, it’s the rare case where e-mail should be produced in its native format. Litigants must also be wary of producing native e-mail container formats because, until those containers are compacted by the client application, they hold information (like double-deleted files) invisible to users but potentially containing privileged and confidential material. It’s possible to “mine” local PSTs for hidden data, and metadata scrubber tools offer no protection.

How, then, do we realize the considerable benefits of native production for e-mail? The answer lies in distinguishing between production of the native container file and productionof responsive, non-privileged e-mail in electronically searchable formats that preserve the essential function of the native source, sometimes called quasi-native formats.

via How to Go Native Without Going South.

Related articles by Zemanta

• Microsoft allows outsiders a peek inside Outlook (news.cnet.com)
• Outlook lock-in could vanish with new open source projects (arstechnica.com)