Craig Ball writes that electronically stored information is not necessarily native data.
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.
He goes on to explain that e-mail’s native file is the container file in which the message is stored. At the enterprise level, that might be and MS exchange database (extension = .edb) or a lotus notes database (extension = .nsf). On workstations, the container file will likely be an outlook database (.pst). By the way, an outlook database is merely a modified MS Access database. The messages are just entries in database fields, so the “native format” of a message is something of an exercise in creative deduction.
And because of that, Mr. Ball states:
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 production of responsive, non-privileged e-mail in electronically searchable formats that preserve the essential function of the native source, sometimes called quasi-native formats.
I’ve not heard the term “quasi-native,” but it seems a reasonably serviceable name for the concept. The rest of his article discusses the way in which a quasi-native production would work.
