An Attachment Grows by a Third Inside the Email

Why a file cannot travel as itself

The mail protocols were written when a connection guaranteed seven bits per character and nothing else. A byte from a PDF or a photograph can be any of 256 values, several of which mean something to a mail server — a lone carriage return, a null, a line that happens to start with a full stop. Base64 sidesteps all of it by using only 64 characters that every system agrees about, at the cost of writing four of them for every three bytes. The arithmetic is not an implementation detail you can optimise away: it is the price of the guarantee that the file arrives identical.

It also explains why compressing before attaching helps and re-compressing an already compressed file does not. A folder of documents zipped down to a third of its size costs a third of the base64 too, because the encoding is applied to whatever bytes you hand it. A photograph or a PDF is already compressed, so zipping it saves nothing and the 1.3684 still applies to the full size.

Getting the files out, and the names right

Each attachment sits in its own part of the message, with a Content-Type saying what it is and a Content-Disposition giving the filename the sender chose. Both can be RFC 2047 encoded, so a French invoice can be named =?UTF-8?B?ZmFjdHVyZSBqYW52aWVyLnBkZg==?= in the raw file and Facture janvier.pdf once decoded — the extractor decodes it, which is the difference between a folder of readable names and a folder of gibberish. Filenames also survive spaces and accents intact, both of which some older extraction scripts mangle.

Frequently asked questions

Is the extracted file identical to the one that was sent?

Yes. Base64 is a lossless encoding, so decoding gives back exactly the bytes that went in — the checksum of the extracted file matches the original. That is why mail can carry a signed PDF or a piece of software without corrupting it, and why the size you see on disk after extraction is the real size rather than the encoded one.

Why is my mailbox bigger than the files I remember receiving?

Partly this, and it adds up. Every attachment you ever received is stored encoded, so a mailbox holding 3 GiB of files takes about 4.1 GiB. On top of that, a message you sent with an attachment is usually kept twice — once in Sent and once in the thread — and a forwarded message carries its attachments again. Extracting and deleting the largest attachments is generally worth more than deleting hundreds of small messages.

Can I get an attachment out of a message that will not open?

Often, yes, and that is one of the better reasons to have this tool. A message whose HTML defeats a mail client is still a well-formed MIME file, and the attachment sits in its own part with its own encoding; the extractor reads the structure rather than rendering the message, so a body that will not display does not stop the file coming out.