EML to Text

An .eml file is already text, which is why people open one in a text editor and then wonder why half of it is gibberish. What they are looking at is a message that has been through four transformations on the way, and undoing them in order is the whole job.

The body is usually in there twice. Most messages are multipart/alternative: a plain-text part and an HTML part carrying the same words. The plain part is preferred here, because it is what the sender wrote before a mail client dressed it up. Where there is no plain part — increasingly common — the markup is stripped and the words, the list items and the link text are kept.

Quoted-printable is why an apostrophe reads as =E2=80=99. Mail was built to carry seven-bit ASCII, so anything else travels as escapes. Each = followed by two hex digits is one byte; each = at the end of a line is a break the sender’s software inserted to keep the line under seventy-six characters, which is why a word can arrive split in half. Both are undone, and the bytes are then decoded using the character set the part declares rather than the one your computer prefers.

format=flowed is why a paragraph arrives in ragged strips. A line ending in a space is continued on the next one; a line that does not is where the writer pressed return. Reading it without that rule gives you a message broken every seventy characters. The rule is applied only when the part actually declares it, because applying it to an ordinary message would join lines that were meant to stay apart.

The images never load, and that is the point. Every image is taken out of the markup as a string before anything parses it, so the address of a one-pixel tracking image never reaches code that could request it. The count of one-pixel images is shown in the status line — not as a verdict, since a one-pixel spacer is a real thing from an older web, but so you know what was in the message. What it means is explained in the argument against uploading an email at all.

If the words come out as Café rather than Café, the message declared one character set and was written in another, and the encoding repair tool undoes that separately.

Press Load a sample. It is a fake invoice, built the way the real ones are: the sender name says a bank, and the message is a three-level MIME tree with a subject in encoded words, a body in quoted-printable, an inline logo and a one-pixel image on a server somewhere else.

The status line reads read as text/plain and tracking pixels 1. The first says the message had a plain part and that is what was used. The second says the HTML half of the same message would have called track.example-bank.test the moment it was displayed — and that the 120 × 32 logo beside it was not counted, because it is a logo.

The header block at the top now reads Subject: Invoice 1042 — payment due Friday rather than =?UTF-8?Q?Invoice_1042_=E2=80=94..., and the From line shows the display name in Arabic instead of a run of base64. The last line names three attachments, including one whose filename arrived split across two parameters.

Then read the message itself. It says Pay now: https://example-bank.test.secure-billing.test/pay/1042. The domain is secure-billing.test; everything before it is a subdomain chosen to look like a bank. In the HTML version those words are a button labelled Pay now and the address is not on screen at all. Turning a message into text is not only a convenience.

Switch Include to body only and the header lines go, leaving the message on its own — the shape to use when the text is going into a ticket rather than being kept as a record.

Links in HTML does nothing to this sample, because the sample has a plain part and the option only applies when the words had to be taken out of markup. On a message that is HTML only — most marketing mail — it is the difference between reading Pay now and reading where Pay now goes.

If what you want is a filed copy rather than the words, the same message as a PDF keeps the headers on the page.