How do emails actually work? While there have been extensions and adjustments, the structure and format of email messages remains extremely similar to how it was defined in the highly-influential RFC 822.

You may have heard of the technology known as “email.” In fact, email is used fairly often; somewhere along the lines of 2.8 million emails are sent per second.

How Email Messages Work

While there have been extensions and adjustments, the structure and format of email messages remains extremely similar to how it was defined in the highly-influential RFC 822. In short, emails have two parts, which dictate what a computer should do with that message:

The Body: What humans read.

What humans read. The Header: What the computer processes when sending the email.

The Header

When an email is sent, the header is parsed for specific words and symbols that have special meanings. As specified by RFC 5322, “[h]eader fields are lines beginning with a field name, followed by a colon (":"), followed by a field body, and terminated by CRLF [Carriage Return].” For example, these lines might appear within an email header:

MIME-Version: 1.0

Date: Mon, 25 Feb 2019 14:29:40 -0800

From: Some Guy <some.guy@256kilobytes.com>

Other header information includes sender and recipient information (to, from, etcetera), trace information (such as Return-Path), format and control information (such as MIME-Version), and various other email headers.

The parser knows that it has reached the end of the header when it encounters two consecutive carriage returns.

Note:You should be able to view the raw email source from your email client. For example, in Gmail, you can select “view original” from the options dropdown for any email.

The Body

The body of an email is hypothetically extremely straightforward, consisting of “simply lines of US-ASCII characters.”

In practice, email attachments, in-text images, rich text (such as bold and italic markup), and other non-plain-text features are facilitated through the use of Multipurpose Internet Mail Extensions (MIME) types.

This is done by adding a MIME field to the email’s header, which indicates that the body field has an additional layer of encoding, which can be decoded separately upon receipt of the message. Additionally, Content-Type and Content-Transfer-Encoding header fields are used to provide additional information about how the message should be decoded.

MIME messages are designed to allow binary data (including images and multimedia content) to be transferred over mediums that only allow ASCII characters. This allows a JPEG, for example, to be converted into a string of characters that looks something like:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAOEAAADhCAMAAAAJbSJIAAAAS1BMVEX/AAD/fX3/jIz/m5v/q6v/uLj/trb/gYH/eHj/ior/2dn/dHT/qan/z8///Pz/ra3/lJT/pKT/8/P/5OT/oKD/yMj/lZX/srL/mppphzYMAAABmElEQVR4nO3dTU4DMRAF4XbGk59JIAESwv1PChIbxIYIqdWqcX2+wKulJUuO59e35el2m+f53ns/fUzfLpufDu3fdps/vU8PuPYHnOfftkvcY92O0asnJGsDFL5UT0jWYqqekMxCPgv5LOSzkM9CvhEKL9UTkrXYVE9IZiGfhXwW8lnIZyGfhXwW8lnIZyGfhXwW8lnIZyGfhXwW8o1QeKiekKx9nXWzkM9CPgv5LOSzkM9CPgv5LOSzkM9CPgv5LOSzkM9CPgv5LOSzkM9CPgv5WuyqJyQb4cXQ+l99WUhnIZ+FfBbyWchnIZ+FfBbyWchnIZ+FfBbyWchnIZ+FfBbyWchnIZ+FfCMUrv+fGQvpLOSzkM9CPgv5LOSzkM9CPgv5LOSzkM9CPgv5LOSzkM9CPgv5Rii8Vk9I1uJUPSFZi149IZmFfBbyWchnIZ+FfBbyWchnIZ+FfBbyWchnIZ+FfBbyWchnIZ+FfC3O1ROStdhWT0jWYq6ekMxCPgv5LOSzkM9CPgv5LOQboXDtN+B9LMe2Zvv5EyTCB9hjiIitAAAAAElFTkSuQmCC

When converted to an image, this is a red square that looks like the following:

This type of encoding is based off Unix-to-Unix encoding (UUEncode).

Base64 encoding is in turn based off of this type of multimedia encoding for internet messages (emails). Tools like this base64 encoding tool can be used to encode arbitrary images and files, which can then be used for various purposes, such as embedding them directly into a webpage. For example, a base64 encoded image can be inserted into a webpage using this syntax:

<img src="[Put Base64 String Here]" />

In the context of web development, this technique is potentially useful because it allows images and other files to be included without the need for an additional HTTP request. However, this type of encoding does result in a filesize that is approximately 33% larger; it can also prevent web-browsers from caching these resources.

Share This Post