By Robert Tallman
Dear ED Therapist:
We are currently gathering data based on a discovery order. The problem that we are facing is that we have some variability in our data population, and we were wondering if you had some suggestions or thoughts on how we can achieve some consistency without being over burdensome on our users. Our main concern is that we have a disparate collection of email applications in house. Some are using Outlook, others are using Eudora, and some are actually using a mixture. Obviously, we want to optimize our collection efforts and focus our teams on reviewing the data rather than collecting, what can we do?
Sincerely,
Linus VanBurent – Boston, MA
Dear Linus,
Ah yes, Eudora. You have hit upon a key factor in electronic discovery that many individuals overlook, and one that can increase the time and cost involved with actually reviewing documents. It’s a situation that does require some significant thought and planning.
In nearly every matter, the most time intensive portion is not electronic processing or keyword searching or even document conversion, but rather document review. The reason this is so significant is because many times there is not enough thought put into the amount of time the review will take. A successful collection strategy, paired with a well-thought-out review strategy, will usually always yield a successful and profitable review for all parties involved.
With your situation, we have several variables to consider:
General Observations:
E-Mail can be a testy animal in that no two applications are really the same. Granted, most e-mail applications adhere to the RFC822 Standard of e-mail structure and coding, however this does not guarantee that all e-mail will be the same. It is a standard, not a rule; thus each developer has the freedom to embellish on this standard to create their own application entity. This is wonderful in that it provides for a basis to work from; however it does allow for variability that can cause challenges. Most major applications adhere to this: Microsoft Exchange, Lotus Notes, Novell GroupWise, and last, Qualcomm Eudora.
The challenge is that if you look at the four programs mentioned above, all of them have chosen a different methodology and architecture in their design, yet they all follow the RFC822 standards.
- Microsoft Exchange – Encapsulated Archive – PST
- Lotus Notes – Encapsulated Archive – NSF
- Novell GroupWise – Database Clustering
- Qualcomm Eudora – Encapsulated M-box concept – MBX
Each one of these formats requires attention to how they are collected. Microsoft Exchange and Lotus Notes are relatively straight forward in that you once you have collected the relevant PST or NSF files or exported the content from the host Server, you essentially have all of the relevant e-mail and attachments. The latter is quite important because e-mail loses its value significantly if the attachment is lost or cannot be rendered. Novell GroupWise is more challenging due to the fact that all of the relevant Clusters need to be acquired to successfully achieve an accurate collection. Then we come to Eudora. I left this last since it has many variables associated to it. When looking at Eudora, there are distinct differences to its architecture that need to be addressed and taken into account.
When working with Microsoft Exchange or Lotus Notes, the representative archives are all encompassing in that they contain all attachments, along with sent and deleted e-mail, that has not been formerly or physically removed from the system. In these cases, the files are suffixed .PST and .NSF respectfully. Typical collection strategies incorporate workstation collection by file type and database collection from the server with ultimate exports occurring to gather specific custodial e-mail.
Addressing Eudora is a little different. Eudora uses an M-box format, where each folder that a user has, inbox, sent, deleted, are stored as separate files on the system and suffixed with an .MBX extension. Based on this, it is really not much different than Novell GroupWise that uses cluster arrangements similar to individual files. Where the challenge arises is in the fact that the custodian has the option of picking “where” they want the attachments to reside. Eudora by default will store the attachments within the Eudora file path. This too can vary as it is part of the installation options.
Because Eudora offers configurable options, such as the destination path of attachments, the attachment is not physically stored/attached with the parent e-mail. The e-mail references a path to the attachments directory that was part of the Eudora configuration when the e-mail was received. As time progresses, the custodian has the option to change this path to suit their needs or desires. Thus, for example, a custodian may create a separate attachment directory per year, retaining all attachments for 2004, 2005 and now 2006. This configuration is actually quite logical and has many benefits for the client. The challenge lies with the individual executing the collection, who must now search multiple extension options as well as try to decipher a custodian’s file saving habits. Finding the .MBX files is the easy part; determining the exact location of “every” attachment presents a high degree of challenge, especially if the custodian had the privilege of customizing their attachment location.
Additional challenges to this setup are that the file structures are Drive and path dependant. If the application and its associated files are not restored to their original paths, accessing the e-mails and attachments are nearly impossible. There are several e-mail conversion applications that exist that can convert .MBX format e-mail to PST; however these are still limited and require backing up to the first step in the process – collection.
And, because of Eudora’s flexible architecture, employees can use Eudora as an SMTP client to connect to virtually any SMTP server. This requires adding another level of checking to validate the backend server infrastructure and determine the path necessary for collecting that segment of the data. Most companies have Microsoft Exchange or even a UNIX/Linux or MAC e-mail servers on the backend of Eudora clients. When Eudora is involved, it’s extremely important to do some investigative work and employ the assistance of the IT team to help facilitate a collection.
Collection Points:
If your company has accurate records and knows for a fact that nothing has been changed, collecting the two main default repositories into which Eudora installs should be safe and all relevant information should be accessible for collection. The next task will be to restore this collection to a hard drive that mirrors the structure of the collected custodians PC.
If unsure of the status, or if there have been changes to the application over time, then the safest path is to either:
- Image the drive and restore it for processing on an alternate PC
- Run a conversion utility to process the .MBX content to PST that will successfully retain the attachment hierarchy and association.
Since this scenario also employs the configuration of having mixed e-mail content on the workstation, I would recommend pursuing the same options as required for a Eudora stand-alone.
Conclusion:
Eudora e-mail is a very strong and highly used e-mail program. With the flexible options that are built into Eudora come some important complexities to consider when collection of those records is required. When faced with collection of evidence that involves Eudora, it’s extremely important to understand how to properly collect the data required by the requesting party. Some of the key variables IT needs to consider in the collection process include:
- Workstation OS and level
- e-mail application level
- e-mail Server level
- Trends or policies implemented or enforced
- User shares to which attachments or archives could or have been saved
This is not a simple task; but it also does not it have to be complex. Understanding these complexities, planning ahead and relying on an experienced electronic discovery vendor, like Fios, can help you collect all of the relevant information required in a legally defensible manner with minimal impact on the daily operation of your organization.
May your collection be successful!
Sincerely,
ED Therapist
If you have a question for the ED Therapist, please feel free to send an email to: EDtherapist@fiosinc.com
Or write us at:
Fios, Inc.
Attn: ED Therapist
921 SW Washington Street, Suite 850
Portland, OR 97205
Filed under From the Experts.