Email Reply Reference Auditor

How to use Email Reply Reference Auditor

Inspect the connection evidence in an original local email export before assuming that a conversation is complete. Each actual EML file keeps a separate source identity, selected header source and exact Message-ID spelling. The audit exposes unresolved or ambiguous links, self references, directed cycles and uniquely connected file components, while preserving References and In-Reply-To as different witnesses. It neither sends mail nor reconstructs an authenticated mail-client conversation.

1. Choose one to twenty original local EML files, or load the original two-file example. This profile requires CRLF ASCII headers and modern dot-atom message identifiers.
2. Run the complete collection audit and inspect missing/duplicate IDs, source-field ordinals, ambiguous targets, self references, cycles and connected components.
3. Download the JSON evidence or link CSV. Resolve ambiguous source files yourself; do not treat a matched identifier as proof of sender identity, chronology or mailbox completeness.

Good to know

• At most 20 actual local files of 10 MiB each. Only the first 32,772 bytes per file are read, to locate a CRLFCRLF separator after at most 32,768 header bytes. Header lines are at most 998 bytes and 500 physical lines per file. Files are not uploaded. Body bytes that fall inside the bounded prefix may enter memory, but they are never decoded, mounted, followed or exported.
• Header text must be strict 7-bit ASCII, with HTAB and CRLF as the only controls. LF-only files, mbox envelope lines, raw non-ASCII/SMTPUTF8 headers, malformed field names, bare line breaks and duplicate selected fields are refused. One unsupported file refuses the whole collection rather than returning a misleading partial graph.
• The selected fields are Message-ID, References, In-Reply-To, Subject, From and Date. Original selected lines and byte offsets are retained; unfolding removes CRLF while preserving continuation whitespace. Subject/From/Date are raw evidence only: encoded words, addresses and dates are not decoded, authenticated, parsed or chronologically sorted. Other header fields and MIME bodies are outside the audit.
• A present Message-ID has exactly one <dot-atom@dot-atom> token; References and In-Reply-To accept at most 50 each. Every token is at most 320 characters including brackets. Comments, quoted/obsolete forms, internal folding and domain literals are outside this deliberately narrow profile. Missing Message-ID remains a separate file finding. All comparisons retain case and exact spelling; no domain or quoted-ID normalization is applied.
• Every reference token retains its field and source ordinal, including repetitions. A unique matching file creates a witness edge; duplicate Message-ID targets remain ambiguous and do not join components. Self references and directed cycle witnesses are reported. References may list ancestors, so every edge is not called a direct parent. Components are evidence connectivity, not complete RFC5256 THREAD results or guaranteed conversation history.
• At most 2,000 source-reference tokens and 1,000,000 readable report characters. JSON includes selected original header evidence, filenames and raw address/subject text; it is not an anonymization tool. Link CSV alone omits file-level issues and cycle details, which remain in the on-screen JSON audit. Formula-like cells are apostrophe-prefixed for spreadsheet exposure reduction. No network, persistent storage, body rendering, attachment extraction, identity verification or message sending is performed.
• Processing is local. Output is limited to 1,000,000 text characters unless a stricter file limit is stated.