Split MBOX into EML Files

Nothing here is converted. An mbox is messages written into one file one after another, each introduced by a line beginning with the word From and a space, and what sits between two of those lines is already a complete message in the form every mail client calls .eml. So this is not a converter — it is a pair of scissors. Each message is copied out byte for byte and given a filename.

Which is why the cut is the entire job, and it is not obvious. A message body may contain a line that begins with the word From, because people write sentences. Split on /^From / and one day you will take a message apart in the middle and write two files, one of them a fragment with no headers that no mail client will open — and nothing will report an error. The rule used here needs four things to agree before a line is accepted as a separator: it starts a line, a blank line comes before it or it is the first line of the file, what follows looks like a sender and a date, and the very next line is a header field. The last is what a sentence almost never has under it. Lines that pass the first three and fail the fourth are counted on screen, so the judgement is visible rather than assumed. The blank line is the condition an archive occasionally breaks, so if requiring it would report the whole file as one message, it is read again without that test and the note says so.

The mail store that wrote your archive tried to prevent this by putting a > in front of any body line beginning with From. There are two conventions for it — one escapes From alone, the other escapes an already-escaped line as well — and no file records which it used, so undoing it exactly is not possible in principle. One > is taken back off by default, which is right for archives written the second way, right for Gmail Takeout and Thunderbird, and costs one character in the rare case of a person quoting a line that genuinely began >From. Turn the switch off and each file is byte-for-byte what the archive holds — which is what you want if the files are evidence and their hashes have to match somebody else’s copy.

A large archive comes back as several zips, and that is deliberate. A zip has to be built in memory before a browser can save it, so one holding every message of a 4 GB export is what runs the tab out of memory — the failure people report from the desktop tools that promise it. The messages are grouped into batches of at most two thousand, or 150 MB, whichever comes first, and each batch has its own download button. A directory of a hundred thousand files is also slow to open in Explorer and Finder both, so the batches are worth having on the disk as well.

The names are the message number, padded so they sort in order, followed by the subject with anything a file system objects to removed. Letters of any script are kept — an archive of Arabic or Japanese mail should not come out as forty thousand files called message — and the number is what guarantees no two collide, since a hundred replies on one thread all carry the same subject.

Attachments come through untouched, because they were never touched: they are part of the message, still base64 inside it, and copying the message copies them. If what you want is the attachments rather than the messages, run one message through the attachment extractor instead. To read the archive before deciding what to do with it, use the viewer.

Press Load a sample. Three messages, one batch, one button. Press it and you get sample-eml.zip holding:

1-The-March-invoice.eml · 2-Re-The-March-invoice.eml · 3-Café-closes-at-four.eml

The colon in Re: The March invoice is gone from the second name, because Windows will not have a colon in a filename. The accent in the third is not gone, because there is nothing wrong with it. Each file is between 346 and 589 bytes — the message exactly, with the From separator line above it left behind, since that line belongs to the archive rather than to the message.

Open the second file. Its last line reads From here on the new rate applies. In the archive that line is stored as >From here on the new rate applies. — the > was added by the mail store so the line would not look like the start of a new message, and it has been taken back off. Turn the switch off, download again, and the > is there in the file.

The same sample also demonstrates what the cut avoids. The second message contains the line From 2019 to 2024 the rate held at the same figure, which begins a line, has a blank line above it and a four-digit year after it. That is enough for most mbox splitters, and most of them would write it out as a fourth file — a fragment starting mid-sentence, with no From, no Date and no Subject. Here the line under it is checked, it is not a header field, and the note above the buttons counts the near miss instead.