From 6692a2f631123b5e95eb5d8af68f5aacf4223870 Mon Sep 17 00:00:00 2001 From: kisfenyo Date: Mon, 29 Jun 2026 09:08:28 +0200 Subject: [PATCH] =?UTF-8?q?docs:=20REPORT=20=E2=80=94=20confirm=20inline?= =?UTF-8?q?=20CID=20image=20renders=20in=20Gmail=20(Resend=20preview=20unr?= =?UTF-8?q?eliable)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 4.8 (1M context) --- REPORT.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/REPORT.md b/REPORT.md index e2b3384..328bf4d 100644 --- a/REPORT.md +++ b/REPORT.md @@ -82,6 +82,16 @@ Test count: **+~17** controller test functions (mailrelay 9, stacks/mailenv 8); additionally exercise that app's own SMTP client (already spike-proven) — recommended as the final manual smoke once the catalog sync has the new templates. +- **Inline CID image — confirmed rendering in the real client (Gmail):** a well-formed + `multipart/related; type="text/html"` message with a CID-referenced inline PNG, sent through the same + pipeline, **renders inline in the Gmail inbox** (Resend "Delivered", From `vaultwarden@felhom.eu`, + signed-by `felhom.eu`, TLS). NOTE: Resend's dashboard *preview pane* unreliably shows CID images as a broken + `attachment-0` even when the delivered mail renders correctly — validate against a real inbox, not the Resend + preview (as the spike did). An earlier synthetic test that used Python's `MIMEMultipart("related")` (which + omits the `type="text/html"` container param) was filed by Resend's parser as a loose attachment and broke — + that was a malformed *test message*, not a pipeline defect; real app mailers (e.g. Vaultwarden) emit a + well-formed related part and render correctly. No code change resulted. + > **Demo box state:** global app-email left **ON** on guest 9201 (the validated working state). No customer apps > have the per-app toggle on, so nothing else changed.