EML to PDF

An email becomes a PDF when it has to be filed, attached to a claim or handed to somebody who does not have your mailbox. The header block is the part that matters — who sent it, when, to whom — so it goes on the page above the message rather than being thrown away with the envelope.

This sets the message as a document. It is not a photograph of it. The headers are laid out as a block, then the body is wrapped and paginated as text. Tables keep their words but not their rules, colours are gone, and the sender’s logo is not there. That is a real limitation and it is worth saying plainly rather than discovering afterwards.

It is also a deliberate one. Reproducing the layout means asking a browser to render the message, and the pictures in an HTML email live on the sender’s server — fetching them is what tells the sender the message has been opened, down to the minute. The choice is between a document that looks like the email and reports back, and one that says what the email said and reports nothing. Every converter that uploads your message makes the first choice on your behalf.

The plain-text part is preferred over the HTML one. Almost every real message carries both, and the plain part is what the sender wrote before a mail client dressed it up. Where there is no plain part, the markup is stripped and what is left is the words, the links and the list items.

Attachments are named, not carried. A line above the message lists each one with its size, so the record shows what came with it. Putting the files themselves inside a PDF would make a container out of a document; take them out separately if you need them.

One more honest limit. A PDF draws text in a font, and the fonts every reader already has cover Latin and little else. Embedding one that covers Arabic, Greek, Cyrillic or Chinese would mean downloading a font file, and this page downloads nothing for the same reason it uploads nothing. Characters outside that set become a question mark, and the number replaced is reported with the result rather than left for you to find. If the message is not in a Latin script, take the text out instead — a text file has no such limit.

A supplier disputes an invoice, and the thread that settles it is one message from February. You save it out of your mail client as invoice-1042.eml — 84 KB, because there is a signed PDF attached to it.

Choose the file. The status line reads read as text/plain, which means the message had a plain part and that is what will be used. Leave the paper on A4 and the headers on the main ones. Press Make the PDF.

You get invoice-1042-message.pdf. At the top, the subject in bold; beneath it From, To, Date, Subject and a line reading Attachments: statement.pdf (61 KB); then a rule, then the message. Two pages, numbered 1 / 2 and 2 / 2 at the foot. The result panel says Pages 2, Attachments listed 1 and Characters replaced 0.

That last number is the one to look at. Zero means every character in the message could be drawn. If it came back as 340 on a message written in Arabic, the document you are holding has 340 question marks in it, and no amount of squinting at page one would have told you.

Now switch Headers to every header line and make it again. The block grows from six lines to forty — Received, Return-Path, DKIM-Signature, the lot. That is the version to file when the question is whether the message is genuine rather than what it said, and the argument for not sending it to a stranger applies with more force to that version than to any other.