synology_apm_repo.sdk.units.content.saas_mail module

Content Layer — Mail’s .eml reassembly. Pure bytes -> bytes byte-splicing (FORMAT-SPEC.md: saas-addressing’s X-ABL-ID engine); the tree-navigation and object-fetching logic that calls this lives in units/saas/mail.py.

synology_apm_repo.sdk.units.content.saas_mail.build_eml(skel_bytes, fragments_by_id)

Reassembles one .eml from a skeleton’s raw bytes and its fragments, keyed by fragment_id (FORMAT-SPEC.md: saas-addressing’s X-ABL-ID engine — matching is by header value, never array/tree order). A part with no X-ABL-ID is left untouched; an unmatched fragments_by_id entry is simply unused, not an error — the skeleton is the sole authority on which parts were ever extracted. A message/rfc822 attachment is one opaque fragment, never recursively re-expanded.

Its spliced bytes for such a part won’t show through part.get_payload(decode=True): the email stdlib always re-nests a message/rfc822 body into a sub-Message on parse, which routes that part to its multipart early-exit (None) regardless of how the bytes got there — compare part.get_payload()[0].as_bytes() against the original fragment instead.