Where Do Attachments Go Inside an MBOX?

Inside the message. An attachment is a MIME part within the same message, its binary content encoded as base64 text so it can travel through mail infrastructure that only handles text. There is no attachments folder — an MBOX file is self-contained, and every photo and PDF you were ever sent is sitting in it as characters.

What that looks like

A message with a PDF attached has an outer multipart/mixed container holding two things: the body (often itself a multipart/alternative with plain-text and HTML versions) and the attachment part. Each part declares its own type, and the whole thing is separated by a boundary string.

The attachment part carries a Content-Disposition: attachment header with the filename, a Content-Type saying what it is (application/pdf, image/png), and then a few thousand lines of base64.

Three things follow, and each explains something people notice:

Your file is bigger than the mail you received. Base64 costs about a third in size. A 6 MB photo occupies around 8 MB of the mailbox. Multiply that by twenty years and you have most of the explanation for a 40 GB archive.

Searching for text inside a PDF finds nothing. The document is base64 in there, not words. body: searches the message body; it cannot see inside an encoded file. Search for what the message said — or use has:attachment with the sender and a date range, which is how you actually find things.

Nothing runs while it sits there. Encoded text is inert; the risk starts when you decode one, save it and open it, which is the ordinary safety question rather than an MBOX one.

Attachments versus the images in the message

Not the same thing, though both are MIME parts.

An inline image — a logo in a newsletter — uses multipart/related and is referenced from the HTML as cid:something, so it displays in the layout instead of appearing as a file to save. It travels inside the message like an attachment does, and it takes up the same space.

A remote image is neither: it is an ordinary https:// link, fetched from a server when the message is opened. Nothing about it is in your archive, which is why old newsletters render with holes — and why a reader that fetches them tells the sender you just opened a message from 2015. Mbox Viewer resolves cid: references so formatted mail renders correctly offline, and blocks the remote ones.

Getting them out

Which is usually the actual goal: not to read the mail, but to recover the invoice attached to it.

Open the message and save the attachment, or preview it first — Quick Look with the spacebar on a Mac. For more than a handful, batch export writes every attachment from a selection into one folder in a single pass; narrow the archive by from: and has:attachment first and the selection is the result of your search. You can also drag an attachment straight out to Finder or Explorer.

Two things worth knowing before you do it in bulk:

• Filenames collide. Twelve senders over ten years called their file invoice.pdf. Export into a folder per sender or per search, not everything into one.
• The message is the context. A folder of 400 loose PDFs with no dates and no senders is worse than the archive you started with. If what you need is provable, export the messages as EML or PDF too, so each file has the mail it arrived with.

The format where they are missing

One historical exception, and it catches people restoring old backups: Eudora. It stored mailboxes as plain mbox under a .mbx extension, but it detached attachments — writing each one into a separate attachments folder and leaving a line in the body reading Attachment Converted: followed by a path.

So a recovered .mbx shows attachments as references to files that are not in it. If they still exist, they are in the Eudora directory next door. Copy the whole thing, not just the mailboxes — and if someone hands you only the .mbx files, the attachments are already gone.

The upside of all this

Everything being inside the file is why an MBOX archive still opens decades later. There is no attachments directory to lose, no database to migrate, no server that has to still be running. The mail and the files that came with it are one object, in text, readable by anything.

It is also why the file is enormous. That trade — bulky but self-contained — has kept a lot of email alive that would otherwise be gone.