Issue Spotting in eDiscovery Part V: Email and Attachments

The following is Part V in a multi-part series on issue spotting in ediscovery. Being able to identify the issues with existing and any potentially lost data early in your case allows you to understand risks and craft an appropriate strategy for dealing with your client’s data, and what you need to request from the other side and third parties. Each type of data has its own issues to consider, and this series will highlight some of those issues and how you should factor them into your discovery strategy for a matter. Part I in the series, How and When to Start covered understanding the big picture and creating a discovery strategy. Part II in the series, Social Media discusses the unique issues to be considered when social media is implicated in discovery. Part III on Photos and Video talks through the considerations you’ll want to focus on when dealing with those types of data. Part IV discussed the issues to be aware of in handling data from instant and text messaging applications.

There’s no question that email is the most prevalent type of ESI in ediscovery and the most prominent source of ESI in civil litigation. It was the first true form of electronic communication—and review platforms have been built to handle email and its attachments effectively.

But the volume of email means that lawyers and legal professionals handling it need to be aware of issues to be considered when negotiating for, collecting and producing email. Volume of email has increased exponentially with the total number of emails growing from 300 billion per day in 2020 to 333 billion in 2022. Despite new and faster forms of communicating electronically, email remains the most prominent form of electronic communication for business communications. The average business person receives more than 120 email messages per day—a very conservative figure since most people have more than one email account. There are 260 business days in 2022, which means each person, on average, will receive 31,200 emails in a year.

As the volume of ESI increases, costs go up with it. And the increased pressure from clients to lower costs increases the need to identify ways to reduce that volume to get to what we need faster for a matter. Reducing volume and costs associated with handling data and review require lawyers and legal professionals to be able to spot the unique issues in dealing with email that need to be considered at the outset of a matter including each of the following:

• Changes in technology
• Attachments/family members
• Searching capability of native email platforms
• Email threading

Changes in Technology

Over the last five years — and particularly during the years of the pandemic — the move to the cloud has accelerated for organizations, and that includes email. While some organizations may retain their onsite email servers, most have not. The costs associated with managing those servers far exceeds the cost of moving to the cloud — whether that means Microsoft 365, Google Workspace, Amazon Workmail or other providers — and SaaS applications allow pushing new code to every user instantly rather than a roll out of updates that need to be done customer by customer.

But the move to the cloud doesn’t change a party’s obligations to produce data, it simply means that party needs to know and understand what needs to be done to pull data from the cloud based systems within the same 30 day time frame laid out in the Federal Rules. And sometimes, that can be time consuming. Know what your client has for email in terms of systems and age of data retained, and who to contact to preserve and collect data for litigation situations.

You’ll also want to test the data you receive from the cloud and ensure that what you agree to in any protocol for production can be met BEFORE you agree to it. Case law is riddled with parties who agree to language in protocols and then discover they can’t meet those obligations once they start looking at the data. Understand what metadata you have, know how attachments are provided, whether new characters are added into a header vs. what is recovered from a user’s computer, etc. You need to understand the intricacies of your email data and those can change with a move to a cloud based application.

Improved technology also means the availability of additional metadata fields. Know and understand what metadata fields you may want based on the type of case you have. One of our earlier posts in our ESI Protocol series detailed issues in metadata to be considered. This is a tool you will want to leverage.

Attachments/Family Members

With server based email, attachments are typically collected and produced together and the relationship remains in tact during the review and production process. Cloud based applications that now create hyperlinks to documents instead of attaching them as documents to the actual email raise new issues about parties obligations to provide those same relationships. Back in 2021, we saw the first glimpse into a key issue associated with attachments from cloud email providers in Nichols v. Noom covered on our Case of the Week series.

In that case, Noom used Google Workspace (then Google Apps) as their email provider. Google has a separate application for documents called Google Docs, that allows a user to share a link to the document vs. physically attaching the document to an email. In negotiating a protocol for production of data from gmail, the plaintiff agreed to allow collection of data using the Google Takeout feature knowing that Google Takeout would not collect the documents included in emails as hyperlinks. Noom produced the data per the parties agreement and then plaintiff discovered that thousands of documents contained links to documents. Although the documents were produced separately, there was no way to tie a particular document as an attachment to an email. Plaintiff asked for the production to be redone to show family relationships, and the court denied the motion. In essence, failure to understand the full scope of how the hyperlinks worked and the familial relationships before agreeing to production specs sunk their motion.

The lesson? You need to think about how hyperlinked documents will be produced in order to maintain the familial relationships we are used to in collecting server based email BEFORE you send requests or agree to a protocol that lays out production specifications.

Searching Capability of Native Email Platforms

It’s no secret among ediscovery professionals that email clients (Outlook, Apple Mail, Gmail, Spark, Thunderbird, etc.) don’t allow for the kind of searching capabilities that review platforms can provide. An apples to apples comparison of search term results from searching O365 across custodians will have different results than if you pull a set of time delineated data for those custodians into a review platform and then run the search. Simply put, the search functionality just isn’t great on email systems themselves. Think about how many times you can’t find an email you know is there if you could only remember the right thing to search for when looking. We’ve seen this issue firsthand in both Google Mail and O365.

That issue means that identifying and collecting data from these platforms needs to take those limitations into account and ensure that you are collecting a broader range of data than what needs to be produced, so that you can ensure the results of any search terms you are running are showing correct results.

Now, if you have extremely large matters with dozens or hundreds of custodians, there are other volume and cost considerations and the approach is completely different than if you are pulling 1-20 custodians’ data. My point is that the functionality that exists in review platforms is much greater than what you have on standard email systems to pull data. You just can’t use them to properly narrow the pool of what needs to be reviewed. Know it’s an issue and think it through carefully before you start identification and collection.

Email Threading

Email threading is now ubiquitous on review platforms and you should be using it whether you have 300 emails or 300,000. As volume increases, tools like email threading become even more valuable. Email threading groups a string of related emails together in a chain. For example, if I send a message asking for agenda items to four people, and all four respond individually, all of those messages will create a chain of emails, or a thread. A thread includes the original email and all responses and even forwarded emails.

Email threading provides context. And litigators now that context is key to the analysis of every issue as well as to the dynamics of relationships between witnesses. Email threading allows you to cull out responsive data, understand the relationship between parties and the tone of communications, learn when a witness knew about an event, and find key emails that would otherwise be buried in a thread that started on a different subject but morphed as it went on.

Using email threading effectively takes time and practice but it carries huge potential for cost savings and its ability to allow you to focus on the emails that matter in a case is gold.

Each of the issues outline above could warrant its own post on all the intricacies to be considered. If you work with legal support professionals, make sure they are considering each of the issues above in handling data, but it’s the lawyer’s job to know and and understand how to spot these issues in negotiating for production and requesting data.

Make a list of the considerations you need to work through BEFORE you start negotiating production specifications and BEFORE you sent out requests for production with instructions included. You need to know about the data you are requesting it. Another alternative is to include correspondence with counsel with the RFP’s asking to set up a call to discuss data related issues so you can amend instructions or get an appropriate protocol in place to cover the issues you need.