Normalize EML MIME Bodies Before Local AI Ingestion

Direct answer

An EML file is a serialized Internet message, not a UTF-8 text body. Before any downstream local-AI task, an importer must parse the message structure and create a clearly defined body view. This is an input-normalization contract only; it does not evaluate summary quality, decide what a thread means, or imply that Cove has an email client. Use a mature MIME parser with a pinned version instead of writing a universal parser from string splits. Preserve the selected source bytes and record the exact parts and decoding choices in a separate derived representation. Parse message headers separately from MIME body parts. RFC 5322 defines the Internet message header and body structure, including folded header lines. RFC 2047 encoded words apply to eligible header text; they are not a general body-decoding mechanism. Keep raw headers available for review, decode display values with the parser’s documented header handling, and do not use decoded sender or subject strings as authentication. A message may omit MIME headers, use uncommon but valid syntax, or contain malformed data; classify unsupported or malformed input instead of guessing a different message. Walk MIME parts according to Content-Type and boundary rules rather than concatenating everything after the first blank line. `multipart/alternative` parts are alternate representations of the same content, ordered by increasing fidelity; choose one supported representation under an explicit product policy and retain its part identity. `multipart/mixed` can contain independent body parts and attachments. `multipart/related` can bind a root body to inline resources, but a local text task should not fetch external images or silently include every related object. Nested multiparts, missing closing boundaries, unknown subtypes, and `message/rfc822` parts require explicit supported behavior or a visible unsupported result. Decode each selected leaf part in the correct order: first apply its Content-Transfer-Encoding to recover octets, then decode those bytes using that part’s declared charset. Base64 and quoted-printable are transport encodings, not character sets. Applying the charset decoder before transfer decoding can corrupt non-ASCII text; decoding a header’s RFC 2047 words as if they were body bytes is also wrong. If charset is absent, invalid, unsupported, or inconsistent with the bytes, preserve a recoverable error or a documented fallback label. Never silently replace undecodable bytes and present the result as exact source text. Keep attachments and body selection independent. A filename in a MIME header does not prove an attachment was parsed, and an HTML alternative is not permission to fetch URLs or execute markup. If a product supports only text/plain, select that part when its explicit policy allows it; otherwise show the supported alternatives and require the user to choose. If HTML is converted to text by a separate parser, keep that conversion policy and source part visible. Do not concatenate an attachment, inline image, calendar part, or nested message into the email body just because it is available in the MIME tree. Apply limits at multiple stages. Bound original bytes, headers, MIME nesting, part count, encoded input, decoded octets and final text. Base64 is a transfer encoding, not compression: its wire representation is normally larger than the decoded octets. Decoded text, temporary copies and deep multipart traversal still require independent memory/work bounds. Missing MIME declarations also have standards-defined defaults: absent Content-Type defaults to text/plain with US-ASCII, and absent Content-Transfer-Encoding to 7bit. Record when a default was applied rather than claiming the sender explicitly declared it; an unsupported declared charset or incompatible bytes remains a separate error. Do not automatically unpack or OCR attachments. Distinguish malformed input, unsupported encodings and valid empty bodies; close owned streams after the operation safely ends. Test synthetic messages with independent expected normalized parts: plain text, multipart/alternative plain plus HTML, multipart/mixed attachment, related inline reference, nested multipart, folded headers, RFC 2047 subject, quoted-printable, base64 UTF-8, another supported charset, malformed encoding, missing boundary, oversized input, and empty body. Assert the selected body’s MIME path, declared media type, transfer encoding, charset, output status, and attachment exclusions. Preserve the raw source for user comparison, do not log private message content, and scope conclusions to the pinned parser and tested fixtures.

A selected EML has both plain and HTML alternatives

An Android user selects an exported message with multipart/alternative content, a quoted-printable text part, a base64 UTF-8 HTML part, and an inline image reference. The model task needs readable body text but must not ingest the attachment tree or fetch image URLs.

Decision

Parse with the selected MIME library, choose one supported body representation under an explicit policy, decode transfer bytes before its charset, and preserve the part path.

Expected outcome

The derived text view is reviewable and linked to the exact source part; inline resources and attachments remain unprocessed unless a separate feature handles them.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Pinned MIME parser and supported message profile
• Alternative body, encoded headers and charset fixtures
• Raw-source preservation and bounded part traversal

Task quality needs a versioned corpus and acceptance rules. Fluent sample output is not an accuracy result.

Implementation workflow

1. Define the EML input contract. Accept only a user-selected message file, identify the exact parser/provider and version, and preserve original bytes. Do not imply inbox access or automatic attachment processing.
2. Parse headers and MIME structure. Use a standards-aware library for folded headers, encoded words, boundaries, nested parts, and `message/rfc822`. Record unsupported syntax rather than rebuilding structure with string splitting.
3. Select one body view explicitly. Apply a documented `multipart/alternative` policy, preserve selected part identity, and keep mixed attachments, related resources, and nested messages separate from body text.
4. Decode bytes before character text. Apply each leaf’s transfer encoding first, then its declared charset. Report absent or unsupported charset and malformed transfer data distinctly from an empty but valid body.
5. Enforce bounds and verify provenance. Limit raw and decoded sizes, headers, nesting, and part counts. Test synthetic fixtures, keep the original source unchanged, and record the selected MIME path without logging private content.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• The importer records parser/provider version, chosen MIME part path, media type, transfer encoding, charset, and normalization outcome.
• multipart/alternative policy selects a representation intentionally; attachments, related resources, and nested messages are not blindly concatenated or fetched.
• Transfer decoding precedes charset decoding, with distinct states for valid empty content, unsupported encoding, malformed input, and size-limit rejection.
• The raw EML remains unchanged and private message bytes do not enter routine logs; no email-summary or inbox-integration feature is claimed.

Decision table

Failure patterns to prevent

• Concatenating all MIME text parts
• Applying charset before transfer decoding
• Treating Base64 as compression or fetching HTML resources

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• Android privacy and security
• IETF RFC 5322 — Internet Message Format
• IETF RFC 2045 — MIME body formats and transfer encodings
• IETF RFC 2046 — MIME media types and multipart structure
• IETF RFC 2047 — encoded words in message headers

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions