- Shipped
- September 2, 2026 at 8:18 AM UTC
- Author
- Kamo
- Commit
- 56acc01
A member sent themselves a message from an outside account with a file attached. The message arrived; the file was nowhere in it — no preview, no download link, and no control offering to reveal it. The attachment list carries an "inline" flag and the reading pane drops every part that has it, because an inline part is one the rendered body already paints and listing it underneath as well would be noise. A cid: reference out of the HTML is the only route a body has to a part, and that needs a Content-ID. The reader also raised the flag for Content-Disposition: inline, which RFC 2183 means far more weakly — "show this in sequence with the message" — and which brings no Content-ID with it. A part marked that way was hidden from the list while nothing in the body could paint it: sitting in the mailbox, unreachable from the UI. iPhone Mail attaches every photo exactly that way, so sending a picture from a phone was enough to lose it, and a PDF sent with an inline disposition went the same way. The reported message is a 73 KB image/jpeg, Content-Disposition: inline, no Content-ID. It now parses as a listed attachment with a download link, and the paperclip is back on the row — the flag also fed hasAttachment, so the message had advertised that it carried nothing. A Content-ID alone now decides it. The signature logos the flag exists for keep theirs and stay out of the list. The one-line parser change reached main early inside 5bd1e83, committed from another session working in this same checkout that swept it up; this carries its tests and the field's contract.