The discarded half of an email

How the text is hidden

RFC 2046 §5.1.4 orders the parts of a multipart/alternative by increasing preference, so a client renders the last part it can and every earlier sibling is a fallback a modern reader never sees — in practice the text/plain half sitting behind the text/html one. The parser resolves that winner first (following the last child even when it is itself a multipart, so a nested branch is collected as leaves) and marks every earlier sibling visible: false with invisibleReason: 'non-rendered-part'. Both halves are decoded per Content-Transfer-Encoding first, base64 and quoted-printable included, so a body that is opaque to anything grepping the file is still compared as text. The sender authors both halves; the reader meets one.

Why a model still reads it

The discarded part is ordinary MIME body text, not a markup trick a parser has to be talked into. An extractor that walks the message tree reads it like any other body, and one that prefers text/plain when a message carries it reads only the half the person was never shown.

What we do about it

alternativeDiverges compares the discarded half against its winning sibling by word coverage rather than containment: both halves are stripped of tags and HTML entities, lowercased and reduced to letters and digits, and the DISCARDED half alone additionally has > quote markers stripped and Gmail-style [image: …] markers folded to their words before the comparison. Alt text is counted as rendered for this comparison only.

How often it fires

1.6% of corpus-eml — 5,930 real .eml from 18 Apache lists and the SpamAssassin public corpus, measured 2026-09-02.

This is an alert-volume number and nothing else. It says how often the alarm sounds on documents as found — not how often it is right, and not whether what it found was harmless. Documents as found may themselves carry concealment. Read it against the population named above rather than as a property of documents in general.