Email — the tool that’s used by billions of people across the world to build relationships — predates the Internet itself, and its usage and user base continues to grow every day.

So, what has contributed to its ubiquity and widespread adoption?

In its simplest form, email is a global distributed system consisting of many different, interoperable client and server implementations that together allow any user to send a message to any other email user. This ability holds true regardless of which email service the user sends email from, and without each user needing to have a prior relationship with each other. The open nature of the email network means that today there are millions of email servers running around the world, and billions of email users.

Despite it’s ubiquity and foundational place in the business world, it can be difficult for modern productivity, sales and marketing applications to integrate with email. At Nylas, we’ve been building an email API that helps developers build a communication layer into their applications for over 4 years, and we’re excited to start sharing more of our email expertise with the world. This post is the first in our new “Email Experts” series, and will cover some of the basic technologies that make the email ecosystem work.

First up, some basics:

Servers

Email servers are run by service providers like Microsoft, Google, Fastmail, and your local ISP, and live in the public cloud, in business’s data centers, or even people’s homes (for those who want to host their own email). They are intended to operate in an always-on, always-reachable fashion—if they’re down, their users’ email won’t work.

Email servers are the backbone of the email network, and serve two purposes:

(1) Email servers store users’ mailboxes and mediate access to them

(2) Email servers accept outgoing mail and route the messages to other email servers

These are different enough tasks that they are typically handled by different server software—_that is, a mail provider will run _one piece of software to handle storage of users’ mailbox data and access to it, and a separate piece of software to accept outgoing messages and route them to the right place.

Clients

Email clients are the apps we all use to interact with email: mail apps on our phones and laptops, and also server-side software that needs to integrate with email mailboxes, but isn’t specifically a part of the email network itself. The Nylas API platform is an example of an email client that isn’t a user-facing app, as it is server-side software that connects to email servers and provides a simpler interface for folks who are building user-facing apps that work with email.

Protocols

The way that two different pieces of software communicate with each other is by using a standardized interface called a protocol. In the email network, email servers communicate with each other using a protocol called SMTP. All email servers communicate with each other using SMTP, because otherwise they wouldn’t be a part of the same network. But email clients are different. There are standard, open protocols for communication between email clients and servers, like IMAP, and there are also proprietary protocols that are specific to certain service providers. This was able to happen because users get the benefit of the email network regardless of which email client they’re using, because the network interoperability magic happens on the server side. Regardless of what protocol an email client uses to connect to its service provider, that email user is still able to send and receive emails from any other email user, regardless of which clients or client-server protocols the other email user uses. So email providers were free to require a proprietary protocol for clients to connect with their servers, but it was up to that provider to also create and ship mail apps for the platforms they wanted users to be able to connect from—which in practice, means that only the biggest providers attempted such a thing, while everyone else stuck to the open standards so they didn’t have to build their own clients too.

In practice, these days three families of email servers exist that every client developer needs to think about because the protocols they support for client communication are different.

• Servers that implement the open standard protocols for email, IMAP and SMTP. Dovecot is a popular open source implementation.
• Microsoft’s Exchange family of servers (including Office365, their hosted cloud Exchange service), which use a proprietary family of protocols.
• Google’s G Suite / Gmail. Google implements the open standards of IMAP and SMTP for compatibility, but has some significant differences in its mailbox semantics which means client developers have to special case a chunk of the code for interoperating with Gmail accounts regardless of the common underlying protocol.

In the next posts, we’re going to do more of a deep dive into the open standard protocols for communicating between email clients and servers: IMAP and SMTP.

This post was originally published on the Nylas Engineering Blog.