I present to you, actually using a competent enough LLM to parse .eml and unit-tests to asses the possibility that we one day wire up the pretty promising [mail-parser](https://docs.rs/mail-parser/latest/mail_parser/) by Stalwart, that we actually already [ship](https://searchfox.org/comm-central/source/rust/protocol_shared/Cargo.toml#11) for some godforsaken reason, I have not yet tried to actually identify, as the primary MIME-parser: **Results** - Total files: 323 - Pass: 295 (91.3%) - Hard fail: 8 (2.5%) — upstream bug required - Soft fail: 20 (6.2%) — sane post-processing possible, no upstream bug needed - **Total fail: 28 (8.7%)** --- **Hard Fails — upstream bug required** *1. `text/html` inside `multipart/related` misclassified as `PartType::Text`* `text/html` parts inside `multipart/related` are returned as `PartType::Text` instead of `PartType::Html`, causing `html_body_count: 0` despite correct content being decoded. - `25-HTML+embedded-image.eml` - `27-plaintext+(HTML+embedded-image).eml` - `29-(HTML+embedded-image)+attachment.eml` - `30-plaintext+(HTML+embedded-image)+attachment.eml` *2. MIME boundary leakage from nested `multipart/alternative` inside `multipart/related`* MIME boundary markers from a nested `multipart/alternative` leak into the body text of the preceding part. The inner structure is not parsed; raw headers appear in body output. - `content-utf8-rel-alt.eml` - `test-rel-alt.eml` - `plaintext-with-key-and-windows-1252-encoded-eml-attachment.eml` - `plaintext-with-windows-1252-encoded-eml-attachment.eml` --- **Soft Fails — post-processing sufficient, no upstream bug needed** *1. cid-referenced images classified as `Binary (attachment)` instead of `InlineBinary` (18 files)* cid-referenced image parts inside `multipart/related` are returned as `Binary (attachment)` instead of `InlineBinary (inline)`. The Content-ID is correctly parsed and exposed, so a consumer can reclassify in post-processing by matching cid values against `src="cid:..."` references in the HTML body. - `05-HTML+embedded-image.eml` - `07-plaintext+(HTML+embedded-image).eml` - `09-(HTML+embedded-image)+attachment.eml` - `10-plaintext+(HTML+embedded-image)+attachment.eml` - `15-HTML+embedded-image.eml` - `17-plaintext+(HTML+embedded-image).eml` - `19-(HTML+embedded-image)+attachment.eml` - `20-plaintext+(HTML+embedded-image)+attachment.eml` - `bug1358565.eml` - `clickableContent.eml` - `content-utf8-alt-rel.eml` - `content-utf8-alt-rel2.eml` - `content-utf8-rel-only.eml` - `malformed_multipart_mixed_cid.eml` - `sample08.eml` - `sampleContent.eml` - `test-alt-rel.eml` - `test-alt-rel-with-attach.eml` *2. Fragmented multipart HTML bodies (2 files)* A single logical HTML body is split across multiple parts and returned as separate fragments. Mergeable in post-processing. - `partial-encrypt-for-alice-html.eml` - `partial-encrypt-for-carol-html.eml` As a bonus, if we were to implement the cid-matching against html as post-processing, we would fix 1-2 bugs we just marked as won't fix. -- Sidenote: No IMAP protocol handler good enough for us to pull it straight in exists, as-of-right-now.
Bug 2034726 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I present to you, actually using a competent enough LLM to parse .eml and unit-tests to asses the possibility that we one day wire up the pretty promising [mail-parser](https://docs.rs/mail-parser/latest/mail_parser/) by Stalwart, that we actually already [ship](https://searchfox.org/comm-central/source/rust/protocol_shared/Cargo.toml#11) for some godforsaken reason, I have not yet tried to actually identify, as the primary MIME-parser: **Results** - Total files: 323 - Pass: 295 (91.3%) - Hard fail: 8 (2.5%) — upstream bug required - Soft fail: 20 (6.2%) — sane post-processing possible, no upstream bug needed - **Total fail: 28 (8.7%)** --- **Hard Fails — upstream bug required** *1. `text/html` inside `multipart/related` misclassified as `PartType::Text`* `text/html` parts inside `multipart/related` are returned as `PartType::Text` instead of `PartType::Html`, causing `html_body_count: 0` despite correct content being decoded. - `25-HTML+embedded-image.eml` - `27-plaintext+(HTML+embedded-image).eml` - `29-(HTML+embedded-image)+attachment.eml` - `30-plaintext+(HTML+embedded-image)+attachment.eml` *2. MIME boundary leakage from nested `multipart/alternative` inside `multipart/related`* MIME boundary markers from a nested `multipart/alternative` leak into the body text of the preceding part. The inner structure is not parsed; raw headers appear in body output. - `content-utf8-rel-alt.eml` - `test-rel-alt.eml` - `plaintext-with-key-and-windows-1252-encoded-eml-attachment.eml` - `plaintext-with-windows-1252-encoded-eml-attachment.eml` --- **Soft Fails — post-processing sufficient, no upstream bug needed** *1. cid-referenced images classified as `Binary (attachment)` instead of `InlineBinary` (18 files)* cid-referenced image parts inside `multipart/related` are returned as `Binary (attachment)` instead of `InlineBinary (inline)`. The Content-ID is correctly parsed and exposed, so a consumer can reclassify in post-processing by matching cid values against `src="cid:..."` references in the HTML body. - `05-HTML+embedded-image.eml` - `07-plaintext+(HTML+embedded-image).eml` - `09-(HTML+embedded-image)+attachment.eml` - `10-plaintext+(HTML+embedded-image)+attachment.eml` - `15-HTML+embedded-image.eml` - `17-plaintext+(HTML+embedded-image).eml` - `19-(HTML+embedded-image)+attachment.eml` - `20-plaintext+(HTML+embedded-image)+attachment.eml` - `bug1358565.eml` - `clickableContent.eml` - `content-utf8-alt-rel.eml` - `content-utf8-alt-rel2.eml` - `content-utf8-rel-only.eml` - `malformed_multipart_mixed_cid.eml` - `sample08.eml` - `sampleContent.eml` - `test-alt-rel.eml` - `test-alt-rel-with-attach.eml` *2. Fragmented multipart HTML bodies (2 files)* A single logical HTML body is split across multiple parts and returned as separate fragments. Mergeable in post-processing. - `partial-encrypt-for-alice-html.eml` - `partial-encrypt-for-carol-html.eml` As a bonus, if we were to implement the cid-matching against html as post-processing for images, we would end up fixing 1-2 bugs we just marked as won't fix. --- Sidenote: No IMAP protocol handler good enough for us to pull it straight in exists, as-of-right-now.