An attachment we could not open

mime.uninspected-attachment

A file attached to an email that this engine could not parse, named in the response rather than passed over in silence.

How the text is hidden

classify walks the MIME tree and treats every non-text/* leaf with a non-empty body as an attachment; a text/* leaf is read as message content wherever it sits. Attachment bytes are already decoded by parsePart per Content-Transfer-Encoding, so the parser inverts its latin1 mapping and hands the bytes on rather than decoding a second time — the first cut re-decoded and turned a DOCX into noise that then read as an honest "we could not open it". The concealment being closed here is the envelope itself: until 0.221.0 the parser dropped every non-text leaf on a comment saying attachments were disclosed elsewhere, and nothing disclosed them anywhere, so a DOCX with white-on-white text that returned suspicious on its own returned clean and certified once attached to an email.

Why a model still reads it

An attachment is not hidden from the reader — it is hidden from a check that stops at the message body. A pipeline that hands an email to a model and extracts its attachments alongside puts a payload inside one into the model's context whether or not the check looked past the envelope.

What we do about it

Every attachment whose bytes are a format this engine parses is analysed by a recursive call, and its findings arrive with location.part prefixed attachment <name> → …, so an email inherits its attachments' verdicts. Anything that throws on parse — a photo, a calendar invite, a signature image — and anything beyond the embed-depth limit is collected by name and reason, and a single mime.uninspected-attachment finding lists them in its excerpt. It is informational, family disclosure, action disclosed: presence is disclosed, never graded, so the verdict stays clean and nothing enters summary.concealedRetained. summary.certified still goes false, because the attachment was not read.

How often it fires

Not measured. We publish a rate only where one has been measured against a named corpus of the right format, and no figure exists for this technique yet. Absence means unknown — never low.

what this does not catch

It names the attachment; it does not read it. A non-text part with a zero-length body is not listed at all, because classify requires a non-empty body. An attachment nested past the embed-depth limit is named with an embed-depth-limit reason rather than opened. Two neighbouring limits are reported as coverage gaps instead of as this finding: an S/MIME or multipart/encrypted body raises encrypted-message-body, and a message that exhausts the MIME part budget raises mime-part-budget-exceeded. Above all of it sits the format gate our published gap list records as open — looksLikeEmail refuses a message whose header block carries neither MIME-Version: nor Content-Type:, or whose header block extends past the first 8 KB it scans, and such a file returns UNSUPPORTED_FORMAT, so no attachment inside it is seen.

Check your own file

Three commands: a key, credit, a verdict.

Start with the API