Preserve an Email Exchange as Source Material for a Documentary Pitch

Two files arrive in your research folder: msg-001.eml and msg-002.eml. Someone with the standing to say so has told you that you can work with them. You open the first, the thread reads cleanly in your mail client, and by the end of the afternoon you have a quotation you like for the pitch.

That is the moment to stop, because the thing you just read was not the thing you were given. What you were given are files. What your client showed you was one rendering of those files, assembled from parts, ordered by a threading rule, and quietly missing whatever the two files don't contain.

Three objects are in play here, and they are not interchangeable: the message, the representations of its body, and the earlier text it quotes. Keep the supplied files untouched, keep a separate index that records what you were handed, identify the parts of each message before you count anything, and treat quoted text as text inside a message rather than as the message it echoes. Everything below is one pass through that discipline, using two invented files.

Freeze the set before you read it

Copy the exports into a folder nothing else writes to, and leave the originals alone. Under a format description as ordinary as the Library of Congress's page on the .eml format, an individual message is commonly stored in one file, with attachments carried inside it through MIME or referenced from it. So the file is the unit you were given, and the file is the unit you preserve.

Give each one a stable local identifier — EX-001, EX-002 — and never recycle those numbers, even if a file turns out to be a duplicate. Keep the original filename alongside your identifier rather than instead of it, because the filename is something the sender or the exporter chose and may itself be worth recording.

Then write down, in one row per file, what you actually know:

Two things about that table. First, the permission column is a record of what you were told, in the words you were told it. It is not a determination that the correspondence is yours to publish. Whether a paragraph can go in a deck or a cut is a separate judgement, made by whoever is accountable for the film, and no technical step on this page settles it.

Second, the hash column earns its place by being narrow. Record the digest when the file reaches you and check it again after you copy it, and a match tells you the bytes are the same bytes. It does not tell you who wrote the message, whether the headers are truthful, whether something was removed before the file came to you, or what you may do with it. A matching hash supports a byte comparison. It does not authenticate a sender.

While you're inspecting, keep the message from reaching the network. Don't open the HTML body in a browser. Whatever it references — images, stylesheets, a one-pixel GIF — will be requested from somebody's server the moment a rendering engine touches it, and a request tells that server the message was opened. Your mail client's setting for remote content is the relevant control if you must look at the HTML at all.

The exchange this article uses

The two messages below are invented. The domains use .example, which is reserved for exactly this, and no part of what follows is a report of a real mailbox. The point of the example is the reading steps, not the people.

msg-001.eml — supplied as EX-001:

From: Nadia Fareed <[email protected]>      (secretary, orchard committee)
To: Owen Blake <[email protected]>           (parish clerk)
Subject: Orchard lease — survey visit
Date: Tue, 3 Mar 2026 09:12:44 -0500
Message-ID: <[email protected]>
In-Reply-To: <[email protected]>
References: <[email protected]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="outer-boundary"

Its body is an alternative: a text/plain part and a text/html part carrying the same sentences, plus one attached PDF named lease-2019-scan.pdf. The HTML part also contains a remote image reference — a tracking pixel on the orchard's domain. That reference is not a part in the file; it is a live address the file points at.

Plain text:

The surveyor can come on 12 March or 19 March. The parish said the lease
runs to 30 June, but I've only ever seen the 2019 copy. Can you check the
file before I confirm with her?

msg-002.eml — supplied as EX-002:

From: Owen Blake <[email protected]>
To: Nadia Fareed <[email protected]>
Subject: RE: Orchard lease — survey visit
Date: Tue, 3 Mar 2026 16:41:02 +0100
Message-ID: <[email protected]>
In-Reply-To: <[email protected]>
References: <[email protected]> <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"

> The surveyor can come on 12 March or 19 March. The parish said the lease
> runs to 30 June, but I've only ever seen the 2019 copy.

19 March suits the hall. The lease file isn't kept here — it's at the county
record office. I'll request a copy.

Two files. Three message identifiers. The distinction between those numbers is the rest of the article.

One message is not one body

Here is the shape of EX-001:

multipart/mixed
├── multipart/alternative
│   ├── text/plain
│   └── text/html
└── application/pdf   (lease-2019-scan.pdf)

Three leaf parts. Two of them are representations of the same message body. One is a separate document the sender attached.

Python's email package exposes three operations here, and the documentation is careful that they answer different questions. In the version current when this was checked — the page was displaying Python 3.14.7 — recursive traversal, preferred-body selection and immediate non-body-part iteration are three distinct calls.

from email import policy
from email.parser import BytesParser

with open("msg-001.eml", "rb") as fh:
    message = BytesParser(policy=policy.default).parse(fh)

for part in message.walk():
    print("node", part.get_content_type(), part.get_filename())

body = message.get_body(preferencelist=("plain",))
print("preferred body:", None if body is None else body.get_content_type())

for part in message.iter_attachments():
    print("non-body part:", part.get_content_type(), part.get_filename())

Run it and read the three blocks as three different answers. walk() descends the whole tree. get_body() returns one representation — whichever the policy prefers, and None if nothing qualifies, which is itself a finding rather than an excuse to go hunting for a substitute. iter_attachments() answers a narrower question about immediate parts that aren't the body.

No output is reproduced here, and none should be taken from this page. What matters is that if you count one number and then describe it as the number of messages, or the number of parts, or the number of things in the exchange, you will have picked the wrong answer to the wrong question. A parser's count is not an inventory.

One branch to keep for later: a forwarded message can arrive as an entire message inside a part, message/rfc822. The outer walk() will reach into it. The outer attachment list answers only the outer question. Missing and invalid content types complicate the picture further. The tidy five-node diagram above describes this fixture, not the format.

What a reply tells you about the message it answers

Put the declared identifiers beside each file and you can see what the supplied set claims about itself.

EX-001 carries Message-ID: <7f3c.20260303a@...> and lists an earlier message, <5d19.20251220@...>, in both In-Reply-To and References. The message that identifier names does not appear in the two files you hold. EX-002 carries its own identifier, declares In-Reply-To pointing at EX-001, and lists both the December identifier and the March one.

The reply's quoted block matches sentences in EX-001 word for word, and the declared reply link points at EX-001. That is a reasonable basis for saying the reply answers the supplied message. It is not a guarantee, and RFC 5322's identification fields — §3.6.4, in the October 2008 specification — describe roles for these headers, not enforcement of them. Anyone can type any value into any header.

What you now know is that the thread declares at least three messages and you were given two. You have an identifier from December 2025 and nothing else: no subject, no body, no participants, no quotation from it in either supplied file. Write it down as an unresolved link and leave the blank in place. The identifier is a trace, not a source.

Two more cases worth recognizing when they show up. A duplicate is not two messages: if the same Message-ID arrives in two files, you have one declared message and two artifacts, and if their bytes differ the copy matters — a re-export can differ from an original in ways you would want to notice. And a thread display that orders everything neatly is a rendering, not proof that the exchange is complete. Sorting is cheap. Completeness is a claim.

Then there is the time. The Date field in RFC 5322 §3.6.1 records the time the message's creator said it was ready for transport. It is not a receipt time, and nothing in the header records when anything arrived anywhere.

Normalized, the reply's stated origination time sits one hour and twenty-eight minutes after the original's. That is an arithmetic comparison of two stated times, and it is worth doing, because reading the raw offsets side by side invites exactly the wrong impression: the reply looks as though it came seven hours later.

Keep the original beside the normalized value rather than replacing it, and keep the offset rather than a zone abbreviation. On 3 March, -0500 and +0100 are both correct for the places involved; an abbreviation would mean something different a month later.

Cutting the excerpt

Suppose the pitch needs a line about the lease. The tempting version is that the orchard's lease ran to the end of June.

Look at what the message actually supports. Nadia wrote that the parish had said the lease runs to 30 June. That is a second-hand statement inside a message, and the sentence does not end there — she adds that she has only ever seen the 2019 copy.

That qualifier is not decoration. Cut it and you have turned a hedged report into a fact. Keep it and the excerpt does the work you want: it shows a committee secretary going on the record about her own uncertainty in the same breath.

So make a reading copy — a separate plain-text file, named for its source, EX-001.reading.txt — and put the passage there with its attribution:

The parish said the lease runs to 30 June, but I've only ever seen the 2019 copy. — EX-001, plain-text body (the HTML alternative carries the same wording); message dated Tue, 3 Mar 2026 09:12:44 -0500; supplied as EX-001.

Then deal with the attachment. lease-2019-scan.pdf is a separate document that a sender chose to include. Its contents are not her words, and reading it is a separate step, done somewhere safe and recorded as such. Its filename is also not proof of anything: it is the sender's label. Even after you read it, a 2019 copy tells you what that document says, not what the current arrangement is — and the question of whether it is the operative lease is a question, not a conclusion.

Say what you attached and where you put it. Don't fold a PDF into the sender's sentence, and don't fold the sender's sentence into the PDF.

When the two bodies disagree

Now change exactly one thing in the invented fixture: the HTML alternative of EX-001 says the lease runs to 30 July, while the plain-text part still says 30 June. Everything else is identical.

The preferred body now decides what your excerpt means. If you take the plain part, your line says June. If you take the HTML — which is what a default preference will hand you in many setups — your line says July. Two renderings of one message, and the reader of your pitch will never know a coin was flipped unless you say so.

Nothing in the supplied set resolves it. Owen's reply doesn't mention the date at all. The attachment is five years older than the message and hasn't been read. The December message is unavailable.

So the excerpt does not get to pick a side. It gets a note: the two representations of this body differ on the month, and the reading copy quotes the plain-text part as such. If the disagreement had been in the other direction — a difference in tone, or in who was addressed, or in a figure that matters — the same rule applies. Compare the alternatives where wording or meaning differs, then say which one you carried forward, and why.

That comparison is the whole argument for keeping the plain part around after you've chosen a preferred body. Choosing is not deleting.

The pitch line and the path back

Here is a defensible line for the deck:

The orchard's secretary wrote that the parish had told her the lease ran to 30 June, and that she had never seen a copy later than 2019. The parish clerk's reply said the file was held at the county record office; it did not address the date.

And here is the path backward from it, which is what makes the line usable rather than merely cautious:

• excerpt — the sentence quoted above, taken from the plain-text body of EX-001; the HTML alternative of the same message carries the same wording, and if it had differed, the difference would be noted here;
• supplied object — EX-001 = msg-001.eml, held since receipt, hash recorded at intake and re-checked after copying;
• representation — one of the two bodies of that message, not the message as a whole, and not the attachment;
• attachment — lease-2019-scan.pdf, accounted for separately and not read for this line;
• declared links — EX-001 names an earlier message from December 2025 that was not supplied and whose contents are unknown;
• time — stated origination 2026-03-03 14:12:44 UTC, a stated time and not a verified delivery;
• permission — development use as stated by the participant's terms, with publication review still open.

An orderly thread view would show you the same conversation in three neat panels. It would still not tell you whether the exchange is complete, whether the message is authentic, whether its contents are true, or whether you may publish any of it. Those are four separate questions, and the preservation work above is what lets you answer each one honestly instead of letting a rendering answer for all four.

The reader of your pitch can follow that path in either direction. That is the whole test.

Frequently asked questions

What should be preserved when email files are handed over for a documentary pitch?

Keep the supplied files untouched in a folder nothing else writes to, leave originals alone, assign stable local identifiers, record the original filenames, and hash each file at receipt and again after copying. The mail-client thread view is a rendering assembled from parts and threading rules, not the thing you were given.

What does a matching hash prove about an email file?

A matching hash supports a byte comparison only: the bytes are the same at those points. It does not prove who wrote the message, whether headers are truthful, whether something was removed before it reached you, or what you may do with it. It does not authenticate a sender.

Why can a reply not establish that an email exchange is complete?

In the example, the reply declares In-Reply-To pointing at the supplied message, and its quoted block matches that message word for word. That gives a reasonable basis for saying it answers that message, but identification headers are not enforced. The supplied set also names an earlier message that was not provided, so there are at least three declared messages and only two supplied files. An identifier is a trace, not a source.

What should be done when two representations of the same body disagree?

Do not let the excerpt silently pick a side. If the plain-text body says June and the HTML alternative says July, the supplied set may not resolve it; note that the two representations differ and state which one was carried forward and why. Choosing a preferred body is not deleting the other, because the comparison is what supports the excerpt.

Why normalize the stated dates instead of reading the raw offsets side by side?

Normalizing the stated origination times shows the reply one hour and twenty-eight minutes after the original, while raw offsets invite the wrong impression that it came seven hours later. The date field records when the creator said the message was ready for transport, not when anything arrived. Keep the original value and the offset, not a zone abbreviation.

Further reading

• Preserve the Web Source Your Film Pitch Depends On Before It Changes — Read this when the preserved material points at something outside the file; it covers capturing a state, recording a checksum, and testing a capture with the network off.
• Find an Archival Film Item and Request the Copy You Actually Need — Read this when a preserved identifier names something you do not hold; it treats a catalog record as a lead and shows how to request the item.