Why multipart email is a tree, not a list

A modern email with an HTML version, a plain-text fallback, and an attachment isn't a flat sequence of parts — it's nested: a multipart/mixed envelope (for the attachment) containing a multipart/alternative part (for the HTML/plain-text pair), each layer introduced by its own Content-Type header carrying its own boundary= delimiter. Correctly unpacking a real message means recursively walking into each multipart part and repeating the same boundary-splitting logic, since a part's Content-Type can itself be multipart/* with a different boundary string than its parent. This tool walks that structure recursively for exactly this reason — a naive single-level split would miss the alternative part nested inside the mixed envelope, which is precisely the shape most real-world email actually has.

Why transfer encoding gets decoded automatically

Email transport historically couldn't reliably carry arbitrary 8-bit binary data, so MIME parts declare a Content-Transfer-Encoding — base64 for genuinely binary content, quoted-printable for text that's mostly ASCII with occasional non-ASCII characters escaped as `=XX` hex sequences. Reading the raw encoded form is nearly useless for actually understanding what a message says, so this tool decodes both automatically for text parts, surfacing the readable content directly rather than a wall of base64 or `=E2=80=99`-style escape sequences that require running through a separate decoder to make sense of.