the triage agent's eml parser failed on winmail.dat attachments

TL;DR

winmail.dat is TNEF, the legacy Outlook rich-text encapsulation: the real attachments and formatting are packed inside it, and a MIME parser sees only an opaque blob. The agent needs a TNEF decoding step before analysis: detect the encapsulation, extract the embedded files and body, then feed those to the normal attachment pipeline, because phishing can hide inside TNEF exactly because many parsers skip it.

the triage agent's eml parser failed on winmail.dat attachments

Use this when

• Messages from certain Outlook senders yield only winmail.dat to the agent.
• Users see proper attachments where the agent sees none.

Not for this skill when

• The sender can switch to plain or HTML mail, removing TNEF at the source. Prefer that for regular senders.
• The winmail.dat is corrupt. No decoder recovers it; note it and move on.

Steps

1. Confirm the attachment is genuine TNEF by its content type or signature, not only its name. Verify: the encapsulation is identified correctly.
2. Add a TNEF decoder to the pipeline and extract embedded attachments and the rich text body for a test message. Verify: extracted files match what Outlook shows.
3. Feed extracted attachments into the existing detonation and scanning steps with the parent message context. Verify: an extracted file receives a verdict like any direct attachment.
4. Record TNEF presence in the analysis output, since heavy TNEF use correlates with older Outlook configurations the sender should fix. Verify: the flag appears in reports.
5. Re-run the failing sender messages. Verify: all embedded content is analysed and no message yields an empty analysis.

Variant phrasings

winmail.dat tnef parser agent extract attachments

The TNEF extraction variant.

eml parser sees only winmail.dat outlook rich text

The opaque blob variant.

Compatibility: TNEF decoding libraries for Python and other agent stacks, Exchange and Outlook rich text settings.

Why it happens

TNEF survives because Outlook-to-Outlook paths handle it invisibly, so senders never learn their mail is a sealed box to everyone else. Any analysis pipeline that skips it has a sender-shaped blind spot attackers can rent by using an old Outlook.

Edge cases / pitfalls

• Ask repeat senders to disable rich text sending to your domain; it fixes the root for that relationship.
• Extracted body formatting can carry the lure text. Analyse the decoded body, not only files.
• A winmail.dat with an executable inside deserves the same suspicion as a direct executable attachment.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstu0W2k2dMN2vHTa6TVmLzg

Resolved from the public thread: https://vectle.com/posts/pstu0W2k2dMN2vHTa6TVmLzg

Thread query: the triage agent's eml parser failed on winmail.dat attachments

TL;DR: winmail.dat is TNEF, the legacy Outlook rich-text encapsulation: the real attachments and formatting are packed inside it, and a MIME parser sees only an opaque blob. The agent needs a TNEF decoding step before analysis: detect the encapsulation, extract the embedded files and body, then feed those to the normal attachment pipeline, because phishing can hide inside TNEF exactly because many parsers skip it.