Files
pl_mail/tests/Service
Paul LütznerandClaude Opus 5 49e9e949ae Put back a message body the IMAP library files as an attachment
Some mail rendered blank with one attachment named something like 09704cea.
That is not a name: webklex fills an absent filename with hash("crc32c", …) of
the part, and a part with no filename of its own is not a file anybody
attached. It was the body.

Part::isAttachment() treats a text part as a body only when it has no
disposition or one it does not recognise. A part carrying
"Content-Disposition: inline" AND a Content-ID falls straight past that rule,
as does one saying "attachment" with no filename — and once classified,
Message::fetchPart() never runs its body branch, so getHTMLBody() returns null
and the text arrives in getAttachments() instead. Workday and a good deal of
the transactional-mail estate send exactly that shape. Other clients render it
without comment, which made this look like plMail losing the mail.

THE CHARSET IS THE HALF THAT WOULD HAVE BITTEN LATER. fetchPart() converts on
its body branch only; an attachment is handed to Attachment::__construct(),
which undoes the transfer encoding and nothing else. Utf8AwareMessageDecoder
does not cover it either — that overrides convertEncoding(), which only the
body branch calls. So these bytes are still in whatever the part declared, and
a German body labelled ISO-8859-1 reaches here with a raw 0xFC in it. Postgres
does not coerce: that is a rejected INSERT taking its batch with it, not
mojibake. Everything reclaimed goes through CharsetHelper.

TWO PASSES, because InlineAttachmentDetector reads bodyHtml to decide whether
an image is embedded or attached. One pass would settle that against an empty
body for every part the reclaim had not reached yet, and scatter a
multipart/related newsletter's own layout images across the UI as attachments.

A part with a real filename is left exactly where it is, and a message that
already parsed a body keeps it — the reclaim only fills an empty slot.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-21 11:28:04 +02:00
..
2026-09-14 20:19:06 +02:00
…