Email Redaction Across a Mailbox: Bodies, Threads and Attachments

A public body asked my team for email redaction because its officers were answering Freedom of Information Act (FOIA) and public records requests by hand. They exported whole mailboxes, several gigabytes each, and read through thousands of threads, calendar invites and attachments line by line. Each request took weeks, and mistakes still got through. A thread about a public project could also hold a coworker's cell number, a citizen's home address or privileged legal advice. All of it had to come out while the public record stayed readable. We built the mailbox connection for them on our integration framework, so the messages a request covers come out of Microsoft 365 and go straight into redaction. The same path serves litigation discovery and data subject access requests.

Most of what goes wrong in email redaction happens where one part of a message meets another, and very little of it makes any noise. A quoted copy of a redacted name goes unreviewed, or an attachment leaves exactly as it was sent. A list of messages turns out to have been incomplete, and in the worst case a file goes out labeled redacted with nothing masked in it.

What one message holds, and where email redaction leaks

A reviewer reading a message on screen sees less than the file holds, and the part nobody sees starts above the body. Routing headers record each server the message passed through, with host names and IP addresses, and the normal view in a mail client never shows them. Microsoft Graph, the API that tools use to read Outlook mail, returns that header set only when a request selects it explicitly. A release that ships the original message file carries every one of those lines along unread.

The details reviewers miss most often are the ones that repeat in every message of a thread until nobody reads them. A signature block puts a direct line and a mobile number into every message its owner sends. Each reply also carries a reflowed copy of everything before it, so one paragraph can appear half a dozen times in a long thread, laid out a little differently each time. Naba Ahtasham on my team, who works on document and email redaction, has mapped where PII in emails sits and what counts as personal data in each place.

Other details get missed because they sit somewhere other than the message a reviewer has open, however carefully it's read. Bcc recipients show up only in the sender's own copy in Sent Items, so a pull limited to the recipients' mailboxes never learns who else got the message. A link attachment points to a file in cloud storage that was never in the mailbox at all.

Rules my team took from quiet failures

When my team built the rendering for .eml and .msg files, we chose to render the visible header block and body as a PDF and redact that, instead of editing the message file itself. What a reviewer approves is then exactly what goes out, and the routing headers stay behind. The cost is that nobody can re-send the redacted copy as an email, since it's a PDF, and for a release I'd make that trade again. Under each redaction the text and image pixels are deleted outright, and the PDF is rewritten in full, so no earlier version of a page survives inside it.

Remote content is a common reason for that rendering to fail, because HTML bodies load logos, signature graphics and tracking pixels from other people's servers. One fetch that hangs can take the whole conversion down, and a message that never renders never reaches review, so nobody redacts it and nobody notices it's missing. The rule we set is that a valid email always renders, with its remote images when they can be fetched and without them when they can't.

Fetching remote content has costs of its own for anyone who renders mail for release. A remote image fetched today may not be the image the recipient saw, and fetching a tracking pixel can tell the sender the message was opened. Where either matters, as in an internal investigation, run the rendering with outbound network access blocked, and each message renders without its remote content.

The failure that taught my team the most was the one that produced a file that looked finished. A redaction job was handed areas to mask, masked none of them and returned without complaint, and the untouched file was then uploaded under the redacted label. Reviewers and recipients trust that label, so it stops the next person from checking. We now treat publishing as the act that claims a file is redacted: a job that masks none of the areas it was given publishes no redacted copy and sets no label. Detection data that can't be read fails the job instead of passing as nothing found, and a job that fails partway leaves the original as it was.

Threads, attachments and what the law changes

I'll leave exemptions to counsel, but a few points of law change what a mailbox pipeline has to do. Justice Department guidance on defining a record says an entire string of emails can count as a single record. It follows the 2016 appeals court decision in American Immigration Lawyers Association v. EOIR, which held that FOIA doesn't provide for redacting non-exempt information inside a responsive record, so quoted history stays in and is redacted wherever it repeats. The UK Information Commissioner's Office says mail moved to Deleted Items hasn't been deleted, which puts that folder inside a subject access pull. In litigation, Federal Rule of Civil Procedure 26(b)(5)(A) requires a party withholding privileged material to describe it well enough for the other side to assess the claim. For email, that usually puts a privileged attachment on the log as its own entry.

Attachments are where much of the sensitive material in a mailbox pull tends to sit, and our rendering leaves them out on purpose so each one reaches the redaction its own format needs. On the mailbox path the workflow extracts the attachments and sends them on, while attachments to an exported message file have to be uploaded as files of their own. Documents come back as redacted PDFs, and photos and scans are masked. Voicemails lose their spoken details to silence or a beep, with the transcript masked to match. Video is burned into a new rendition, and zip or tar archives are opened so each file inside becomes an item of its own.

The attachments to look for first in any release are the ones that resist being routed that way. They include a message attached to another message along with its own attachments, a link to a cloud file, an archive inside an archive, and password-protected Office files and zips. Hidden worksheets, comments and speaker notes also survive in Office files that look clean on screen. Each of those, and the check that catches it, is taken apart in how to redact email attachments.

Approval, the original and a record of every redaction

Nothing should leave the organization until a person has approved it, and on the mailbox path that approval is a step where the workflow pauses until someone signs off. Actions that can't be undone, such as sending mail or deleting it permanently, shouldn't be left to an automated agent's judgment by default. The case for human-in-the-loop approval sorts every mailbox action by whether it can be reversed and shows where a person has to approve.

Review happens before that approval, and it is where the record of each redaction begins. A reviewer corrects what detection found, drawing in what it missed and removing false positives. Each redaction then carries its exemption code on the page, from the default US FOIA, UK FOIA and US Privacy Act lists or from the organization's own.

VIDIZMO Redactor keeps the original by default and releases a redacted copy, because an appeal against a withholding is decided against the original. Its redaction report records what was redacted, by whom and when, and exports as CSV. For litigation teams, production numbering and family ranges stay in the review platform, and Redactor hands back the redacted files together with that export.

Checks to run on any email release

A release can be tested after the fact whatever tool produced it, including ours, and none of the checks below needs access to anyone's code. Run them on a sample from every custodian, since problems gather around particular mailboxes and formats and the first few messages rarely show them.

Our answers to the tenant questions, and what to license

An IT director connecting anything to a Microsoft 365 tenant needs to know what it reads, what it can change and where the copies go, so here are our answers. The connector reads the mailboxes your administrator names, on a schedule and with nobody signed in, so it runs on a Microsoft Graph application permission called Mail.Read. Microsoft's permissions reference labels it "Read mail in all mailboxes" and requires an administrator's consent for it, and until someone narrows it, that is what it grants.

The narrowing happens in your tenant, where your Exchange administrator scopes the grant with RBAC for Applications in Exchange Online to a management scope or administrative unit holding only the mailboxes in question. The administrator then removes any unscoped Mail.Read grant for the same application in Microsoft Entra ID. Microsoft adds the two grants together, so an unscoped grant left in place still reaches every mailbox.

A records pull needs nothing beyond reading, and the connector asks for more only when you configure it to. It takes Mail.ReadWrite if you set it to move or delete messages after ingestion, and Microsoft notes that even that permission doesn't include sending mail. For any mailbox under a legal hold or a records schedule, I'd leave messages in place, which keeps the pull to reading alone. It never needs Mail.Send, because it sends nothing. Agents are a separate question, and an agent in one of our workflows can send mail only if the workflow's author has deliberately allowed it. The lock that holds across the whole organization is Microsoft's, since an application never granted Mail.Send can't send mail, whatever a workflow asks of it.

Pulled messages become records in the library of your VIDIZMO deployment, stored beside their redacted copies. The portal's roles decide who can open them, whether someone searches the library or asks an agent about it, and the library's own retention decides how long they're kept, apart from anything Exchange keeps. The deployment runs as SaaS, in your own Azure subscription or on your own servers. An air-gapped deployment can't reach Microsoft Graph, so it redacts exported .eml and .msg files instead.

A tenant in GCC High sits in Microsoft's cloud for US Government, which has its own Graph and sign-in endpoints. Those are separate from the worldwide endpoints that commercial and GCC tenants use, as Microsoft's national cloud reference shows. We build each customer's mailbox connection on our integration framework, as we did for that public body, and for a GCC High tenant we build it against those endpoints. Our Microsoft Teams connector already offers Global, US Government (GCC High) and US Government (DoD) as a setting.

Two products are involved, each licensed on its own and both enabled on the same VIDIZMO portal. Redactor does the redaction, and AI Intelligence Hub holds the mailbox connection, runs the workflow that pulls messages and attachments, and pauses it for approval. Exported .eml and .msg files need Redactor alone. For federal buyers, FedRAMP compliance comes through a FedRAMP-authorized hosting partner that runs and maintains our software inside its authorized environment, with onboarding in about three months. Our software is aligned with NIST SP 800-53, the control catalog FedRAMP baselines are built from, and VIDIZMO does not hold a FedRAMP authorization in its own name.

The rest of an administrator's list covers paging, throttling, a pull that comes back partial, a sign-in that lapses halfway through and message identifiers that change when a custodian files mail. How a connection behaves on each of those depends on your tenant, so I'd put them to any vendor in writing, us included. Test attached messages and cloud links on a sample of your own mail as well. Naba Ahtasham explains what a sound answer to each looks like when Microsoft 365 email redaction runs straight from the Outlook mailbox.

The email redaction use case shows where Redactor fits for FOIA and subject access requests, legal production and third-party sharing.