What this analysis does
Choose a real .eml message and Mailybox combines client-side message structure inspection with header-level authentication and transit analysis. The body remains in your browser while route and identity evidence are derived from the header.
A complete message carries more evidence than its header. MIME structure, attachment metadata, encoding choices and the visible link surface all describe how the message was constructed, which frequently distinguishes an ordinary message from one assembled by tooling.
Structure is evidence
The MIME tree records how the message was built. A mismatch between the plain-text and HTML alternatives, an unusual nesting depth, or an attachment whose declared content type disagrees with its actual content are all structural observations that no header analysis produces.
Encoding choices are similarly informative. Base64 applied to content that would normally be quoted-printable, or character-set declarations inconsistent with the actual bytes, indicate generation by tooling rather than by a mail client. Neither is proof of anything on its own; both are worth recording.
- The MIME tree shows how the message was assembled.
- Declared content types can disagree with actual content.
- Encoding anomalies suggest programmatic generation.
Links are inspected, never followed
The link surface is extracted and reported without any remote content being retrieved. That boundary matters: fetching a URL from a suspicious message can confirm an address is live, trigger tracking, or in some cases execute the very action the message intended.
The pattern most worth recording is a visible link text that names one destination while the underlying href points elsewhere. It is trivial to construct and remains one of the most reliable indicators in a message that otherwise reads normally.
Handle the evidence carefully
A complete message contains the body and any attachments, which frequently include personal or commercially sensitive material. Redact what is not needed for the technical question before analysis, and keep the original file unmodified wherever the analysis might later support a formal process.
When a message may become evidence, hash the original before doing anything else. A recorded hash taken at collection time is what allows the file examined later to be shown to be the file that was collected.
Hash and manifest the original messageRead the forensics workflow guide
Example: an attachment that misdeclares itself
Evidence supplied
A message with an attachment declared as a document whose content signature does not match the declared type.
How to read the result
The analysis records the mismatch between declared and observed type as a structural finding, alongside the MIME tree and the extracted link surface, without opening the attachment or retrieving any remote content.
Known limits
- Analysis is static; no attachment is executed and no remote resource is retrieved.
- Structural anomalies indicate how a message was built, not the intent behind it.
- A message that has passed through gateways may have been modified before collection.
Common questions
Are attachments opened or scanned for malware?
No. Metadata and declared types are inspected statically. This is not a malware scanner and does not execute content.
Is the message retained after analysis?
The supplied evidence is used to produce the response and is not kept afterwards. Redact sensitive content you do not need analyzed.
Where do I obtain a complete message file?
Most clients offer a save or download original option. Forwarding does not preserve the original headers and structure.