Render inline mail images in the body, drop the ones nothing references

[KrisBraun]

Why

A mail client embeds an image it attached to a message by pointing at its MIME part — <img src="cid:...">. Mail connectors treated every such part as an ordinary attachment, which produced two problems.

Inline images never rendered inline. An image the body still references was listed as an attachment below the message rather than appearing where the sender placed it, and since connectors report no dimensions for these parts it rendered in a fixed preview box at nothing like its real size. The Outlook connector filtered inline parts out altogether, so a screenshot pasted into a message never appeared at all.

Trimmed quotes left orphans behind. Connectors cut quoted history out of a reply's body, but classified attachments against the raw message. A sender's signature image is re-embedded by every reply in a chain, so each message carried a part whose only reference sat in the quote that had just been removed. Those orphans became an attachment on every message in a long thread — frequently a blank placeholder the reader had never seen, because the sender's own mail gateway had already stripped the image.

What changed

Parts are classified against the body that survives trimming:

Part	Result
Referenced by the retained body	fileRef carries the part's contentId; Plot renders it inline where the sender put it
Not referenced	Dropped — nowhere to render it, and listing it shows a file the reader cannot place
No HTML body to test against	Left as an attachment rather than silently discarded

That last row matters: a plain-text message carries no cid: references to match against, so absence of a reference is not evidence the part is an orphan.

SDK

• contentId on ActionType.fileRef — set it only when the note's content still references the part. A non-null value tells Plot to render the image in the body instead of appending an attachment chip.
• contentId and inline on ImapMessage.attachments. A multipart/related image routinely omits Content-Disposition entirely, so a bare Content-ID is itself the signal that the part belongs to the body.
• referencedContentIds and normalizeContentId on the signals entry point, so every mail connector shares one rule rather than three approximations of it.

Connectors

• Gmail reads Content-ID / Content-Disposition per part and classifies against the post-trim body.
• Outlook requests contentId in the attachments $select and replaces its blanket !isInline filter. This is what makes a pasted inline image appear at all.
• Apple Mail carries the BODYSTRUCTURE Content-ID (body-fields index 3) and disposition type through to ImapAttachment.

Tests

Each connector gains coverage for the three outcomes — referenced, orphaned, and no-HTML-body — plus parser-level tests for Content-ID extraction and the bare-Content-ID inline case. google 363, outlook 145, apple 456, all green; plot lint clean in all three.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AZjF9kXrBHeX4415ifBXvZ