Support email file formats: `.eml` and `.msg`

[walsha2]

Ability to parse .eml and .msg files would be great.

docling supports this:

MIME (.eml) and Outlook (.msg) email messages; attachment names can optionally be listed via EmailBackendOptions

[itsaaronngan]

I have this working on a fork. Would you like a PR?

Shape

Hand-rolled MIME on std + encoding_rs, no new dependencies. Follows csv.rs: parse(bytes) -> Result<Document, ConvertError>, produces the document model, does not touch the Markdown writer.

• RFC 5322 headers, continuation lines unfolded
• multipart traversal, depth-capped, prefers text/plain
• quoted-printable and base64 transfer-decoding
• RFC 2047 encoded-words, both B and Q
• charset via encoding_rs, mirroring csv.rs::decode
• Subject as H1, From/To/Cc/Date as a metadata paragraph
• extension-only detection, no detect.rs entry, per the CSV precedent for signature-less text formats

Registered in the node, wasm and python enums and in node/cli.js FORMATS.

A body that is text/html with no text/plain alternative returns Unsupported rather than emitting markup as prose. That case wants #52 or #53 landing first; I did not want to guess at HTML here.

Validation

142 real .eml files, Outlook/Exchange via Mimecast: 141 convert, median 4.0 ms.

The one failure is a calendar invite whose text/plain part is 2 bytes and whose content is text/calendar. It returns Unsupported rather than emitting the 2 bytes. Correct as far as I can tell, but it is a judgement call.

• cargo test --locked (307 passed, 1 ignored; 13 new unit tests)
• cargo clippy --workspace --all-targets --all-features -- -D warnings
• cargo clippy -p anydoc-wasm --target wasm32-unknown-unknown -- -D warnings
• cargo fmt --all --check

That corpus is private, so the fixtures are synthetic: seven handmade files under tests/fixtures/eml/, plus the fixtures_detect_from_content entry. Writing them turned up four bugs I had missed against real mail, the worst being that a whitespace-only line (one space, not empty) did not break a paragraph, so it rendered as a hard break with nothing after it. 3267 occurrences across the corpus, now zero.

Out of scope for this

• .msg, which is OLE-based and wants a separate frontend against cfb
• attachments; currently ignored, not listed
• fuzz/fuzz_targets/eml.rs, happy to add it if you want it in the same PR

Questions

1. Do you want this as a PR, or would you rather implement it yourself? Either is fine.
2. Headers as a metadata paragraph, or something else? A table reads as tabular data, which these are not.
3. Quoted reply chains: I preserve them verbatim. Stripping needs client-specific heuristics, which reads against what detect.rs says about heuristics.
4. text/calendar: leave as Unsupported, or extract?

Branch: https://github.com/itsaaronngan/anydoc/tree/main (three commits on top of v0.2.3)