Anthony d07b0bd911 Emit a real BODYSTRUCTURE that describes attachment parts ...

The IMAP server was hardcoding BODYSTRUCTURE to a single
\"text/html\" entry regardless of the cached envelope. Thunderbird
parses the body itself and survived that, but stricter IMAP clients
use BODYSTRUCTURE as the source of truth for whether a message has
files to save — so multipart messages were rendering with no
attachment hints anywhere.

New module `mail::bodystructure` walks the cached RFC 2822 (reusing
the parser helpers — now `pub(super)` for sibling access), produces a
parenthesised RFC 3501 §7.4.2 structure with one entry per MIME part,
and propagates Content-Disposition so attachment parts carry their
filename. Single-part bodies still emit the previous shape verbatim
(no behaviour change for the common case).

Eight unit tests cover the happy path (text/html), multipart/mixed
with a PDF attachment (asserts `MIXED`, `BOUNDARY`, type/subtype,
disposition + filename), nested `multipart/alternative` inside
`multipart/mixed` (real-world MUAs), and the helpers (count_lines,
quoted, build_params, missing boundary).

2026-05-28 18:50:05 +02:00

..

examples

Restructure into Cargo workspace with Tauri desktop GUI (#1)

2026-05-27 14:03:15 +02:00

src

Emit a real BODYSTRUCTURE that describes attachment parts

2026-05-28 18:50:05 +02:00

Cargo.toml

Restructure into Cargo workspace with Tauri desktop GUI (#1)

2026-05-27 14:03:15 +02:00