How do I establish whether messages really belong to the same email thread?¶
title: How do I establish whether messages really belong to the same email thread? subtitle: Use Message-ID, In-Reply-To, References, provider context and content together rather than relying on the subject line. slug: how-do-i-establish-whether-messages-belong-to-the-same-email-thread series: email-evidence section: technical-interpretation card_type: question_card pathway_order: 18 section_order: 5 status: draft public_safe: true video_ready: true word_count: 560 estimated_read_time_seconds: 232 audiences: - investigator - supervisor - fraud and compliance practitioner tags: - email evidence - thread - In-Reply-To - References - Message-ID sources: - title: 'RFC 5322: Internet Message Format' url: https://www.rfc-editor.org/info/rfc5322/
How do I establish whether messages really belong to the same email thread?¶
Use Message-ID, In-Reply-To, References, provider context and content together rather than relying on the subject line.
Script¶
Several emails appear together in a conversation view and share the same subject.
Does that prove they are one genuine email thread?
Not by itself.
Email applications group messages for convenience.
They may use the subject, participants, timestamps, Message-ID relationships or their own provider-specific rules.
A grouped display is a useful starting point.
The underlying messages still need to be preserved and compared.
Start with the Message-ID of each email.
A reply may contain an In-Reply-To field identifying the Message-ID of the message it answers.
It may also contain a References field listing Message-IDs from the earlier conversation.
Those fields help software and investigators reconstruct relationships between messages.
For a straightforward exchange, the pattern may be clear.
The first message has its own Message-ID.
The reply has a new Message-ID and identifies the first message in In-Reply-To and References.
The next reply refers back through the chain.
That supports the view that the messages were generated as replies within the same conversation.
But the fields are not infallible.
They are created by sending software.
A system may omit them.
A user may start a new email and reuse the old subject.
A forwarding or ticketing system may generate a new message structure.
An imported or reconstructed message may contain copied identifiers.
A hostile sender may also insert convincing-looking references.
So use the identifiers with the provider and mailbox context.
Preserve every native message rather than relying only on the collapsed conversation view.
Record each Message-ID, In-Reply-To and References value.
Compare the From, To, Cc and any available recipient information.
Normalise timestamps and identify which trusted systems handled each message.
Check whether the recipient and sending providers hold matching trace records.
Look for the messages in Sent Items, Inbox and other participants’ mailboxes.
Then compare the content.
Does each reply quote or respond to material found in the earlier message?
Does it contain knowledge that fits the sequence?
Are attachments added, removed or changed?
Did the subject remain the same, acquire repeated “Re:” or “Fwd:” prefixes, or change completely?
Quoted text needs care.
A person can edit the earlier message when replying or forwarding.
A later email displaying earlier words doesn’t prove that those words appeared exactly that way in the original.
The original preserved message is stronger than a quotation inside a later reply.
Also watch for branch points.
One recipient may reply only to the sender while another uses Reply All.
A BCC recipient may begin a separate conversation.
Some messages may share references but not have been delivered to every participant.
There may be several legitimate branches from the same original message.
The common mistake is:
“They have the same subject, so they are one thread.”
The opposite mistake is:
“One message has a different subject, so it can’t be related.”
People and systems change subjects, forward content and create new messages during the same real-world conversation.
A careful conclusion might say:
“These messages contain a consistent chain of Message-ID, In-Reply-To and References values, are present in the corresponding mailboxes, and match the provider timeline.”
That is strong thread evidence.
If only the subject and quoted text match, describe the relationship as apparent or claimed rather than technically established.
An email thread is reconstructed from the preserved messages and the systems around them.
The conversation view is the map shown by one application.
It isn’t the whole evidence.
Key takeaway
A conversation view is a useful presentation. The underlying relationship should be tested from each preserved message and its identifiers.
Related questions¶
- What can a Message-ID tell me?
- What can timestamps in an email header tell me?
- What can BCC information show, and who may hold it?
- Should I preserve the mailbox as well as the individual message?