What is an EML File And What Happens When a Message Becomes One

An EML file is one message written to disk in exactly the form it arrived in. Whatever saved it added nothing and took nothing away. That single decision explains why almost every program on every platform can read one. It also explains every difficulty the format causes once you have more than a few hundred of them.

Most descriptions of the format stop at portable and plain text. Both are true and neither is useful once a folder of forty thousand of them lands on your desk. The interesting part of EML is not what is inside a file. It is what happens when a message becomes a file at all. Readable headers on the first line are what mark one out from the other mail formats, most of which announce themselves quite differently.

What Makes an EML a File Rather Than a Message

A message travelling between servers is a stream of bytes with a defined structure, set out in RFC 5322. Saving it as an EML writes that stream to disk unchanged. No conversion happens, which is why the format has no version and no variants to worry about.

Everything that makes a file a file then has to come from the file system instead, because the message carries none of it.

Where EML Files Come From

You rarely go looking for one. They arrive from a handful of routine actions. Knowing which produced yours tells you what to expect from the naming.

A folder holding EML files from more than one of those routes will have no consistent naming at all, which matters more than it sounds. Nothing inside the files can tell you what order they belong in, so the names are the only ordering you have.

What the Filename Costs You

Naming a file after the subject line is the obvious approach and it is what most clients do. It also runs straight into rules the message never had to obey.

Microsoft documents the characters a Windows filename cannot contain. Several of them are ordinary punctuation in a subject line.

Re: Q3 figures
50/50 split?
<urgent>

Re Q3 figures
5050 split
urgent

An EML is still a delivered message. Everything that arrived with it arrived too, including attachments nobody scanned and links nobody checked. Reading the file as text is safe enough, since nothing executes. Double clicking it opens a mail client that will happily render the HTML and offer to open what is attached, which is a different proposition.

Then there are the reserved names. Windows still treats CON, PRN, AUX, NUL, COM1 through COM9 and LPT1 through LPT9 as reserved, extension or no extension. A message with the subject NUL cannot become a file called NUL.eml. The program saving it has to notice that or fail.

Collisions follow from all of this. Reply chains share a subject, so twenty messages in one thread produce twenty attempts at the same filename. Programs append a number, which is fine until you sort the folder and find the thread scattered.

The Path Length Problem

This one tends to surface during a backup, which is the least convenient time available.

Microsoft defines MAX_PATH as 260 characters, covering the drive letter, the folders, the filename and a terminating character. This is a Windows API limit rather than a file system one, since NTFS itself handles far longer paths without complaint.

Modern Windows can go beyond it, though only when LongPathsEnabled is set in the registry and the program itself declares that it supports long paths. Both are needed. Plenty of programs still declare neither, File Explorer among them in places.

A long subject line makes a long filename. Put that inside a nested export folder inside a user profile and the total climbs quickly.

The symptom does not name the cause. Windows reports the file as missing, the path as invalid or the copy as failed. It rarely says the path was too long, which is why people conclude the archive is damaged when the messages inside it are perfectly intact.

What an EML Does Not Carry

The format holds the message completely. What it cannot hold is anything about the message's place in a mailbox, because a message never had a place in a mailbox until a client put it in one.

None of that is a flaw. It is the same trade the format makes everywhere. Carrying nothing beyond the message is what lets any program read one. It is also why the surrounding folder has to carry everything else.

Whether an EML Can Be Proved Genuine

Since anyone can edit one in a text editor, the obvious question is whether an EML is worth anything as evidence. It depends entirely on what rode along inside it.

Both signatures travel inside the message, so exporting to EML carries them along. A file saved years ago can still be checked today, which is the strongest argument for keeping mail in this format rather than in a container that rewrites what it stores.

A failed check is not proof of tampering. ProPublica made this point when publishing its own verification method. If DKIM validates, the message matches what was sent. If it does not, three explanations remain open. The message may have been altered. A mail system may have reformatted a header in transit. The signing key may simply have been rotated since. Failure means you do not know, which is a different finding from knowing something was changed.

Why EML Is Still the Archival Choice

Everything so far has been a cost. For anything meant to last, those costs buy something no container format offers.

archive.pst
  index          <- damaged
  Inbox          unreachable
  Sent           unreachable
  Clients        unreachable

Mail/
  0001.eml       fine
  0002.eml       <- damaged
  0003.eml       fine
  0004.eml       fine

1. The structure is published. A message saved in 1995 opens today because RFC 822 described the structure in 1982, RFC 2822 refreshed it in 2001 and RFC 5322 carries it now. No vendor has to still exist for any of that to hold.
2. There is no version to get wrong. Unlike container formats, EML has no variants, no revisions and nothing that changed between releases of a product.
3. One damaged file costs one message. Corruption in a container can take a whole mailbox. Corruption in an EML takes that message and leaves the rest untouched.
4. It is auditable. Anyone can open one and see the full headers, which is why legal and forensic work keeps coming back to it.

What This Means at Volume

All of the practical advice for EML comes down to accepting that the file system is doing a job the format left open.

1. Keep the folder path short. You cannot control how long a subject line was. You can control how deep the folder sits, which is the half of the budget still available to you.
2. Zip the folder before moving it. An archive travels as one file, which sidesteps the path limit and the per file overhead in the same step.
3. Record the folder structure separately. Nothing in the files will remember it. A plain text list of what was where costs a minute and answers a question that becomes unanswerable later.
4. Treat repeated filenames as expected. A thread shares a subject, so a run of numbered duplicates usually means a conversation rather than a fault.

Reading a handful is a job for any mail client. Reading forty thousand without importing them anywhere is a different problem, which is what our browser based viewers exist for. Turning them into a single container is a separate job again, as is reshaping them so a spreadsheet can work through the lot. Both fall to the mail converters.