Through this article, you will get a good insight into "How Email Systems like GMail and Outlook Are Designed?". The key is to understand that email is a default way of communication on the web and is not same as a instant messaging platform.

As we know already, using email is a common way we communicate to other people usually for work, advertising, record of transaction, or some other purpose to communicate. Although there are lots of high-quality email providers out there such as Gmail, Outlook, Yahoo, Apple, Proton, and many others, there is still a need for understanding what a email system needs, especially if you are working for a company that would like to communicate internally without anyone but the company staff members knowing or possibly improve it.

Components of an Email System

Mail User Agent (MUA) is the application which is used to write, send, and receive emails.
Mail Transfer Agent (MTA) handles all the incoming and outgoing mail.
Mail host is the server that will deliver and receive mail for a host/network.
The mail host will store the emails in mailboxes.
A domain name system (DNS) is required for determining where to deliver the email.
- A system that translates domain names such as: youtube.com, google.com, yahoo.com, and etc into internet protocol (IP) addresses like 105.104.204.101.
Simple Mail Transfer Protocol (SMTP) is perhaps the most important component where it's implemented as a server application that will process your emails, send it to the correct server and relay messages. It's constantly running waiting for to send new mail. SMTP will also verify outgoing email to ensure it's from a legitimate active user account.

Here is a basic example of what it looks like on the outside.

And for the internals, here is a typical example of how an email is processed from sender to receiver.

Example of Email Systems

Examples of Email Systems

1. Store and forward servers

   • An example is the Post Office Protocol (POP): a simple design where the server will keep messages until the user accesses that email and downloads them.
   • Pros: Able to access downloaded emails whenever (even when offline).
   • Cons: Having multiple machines make emails in different locations and if not backed up they are lost forever and mail operations (filtering/searching/etc) are done on the client's device.

2. Server-only mail repositories

   • An alternative and better method than the first example would be to store all the emails on the server instead of the client's computer.
   • Pros: Email view is consistent with all machines, typically has a centralized repositiory by the provider to store emails, and provide mail operations server side.
   • Cons: Poor network connection can prevent users from accessing their emails, all work is done server side causing a wide variety of mail features/operations almost infeasible to scale up.

3. Client-side caching systems

   • The standard approach where clients will keep a cached version of the email view on their machine while the servers will store permanently store the emails.
   • Pros: Can be disconnected and still access emails, emails are backed up, and allow the sophisicated mail operations/features (searching/filtering/new emails/etc).
   • Cons: Complex client-server sychronization protocol with lots of code along with runetime performance, and more features added to the server means less people can be supported.

Not categorized but a special mention would be an imtermediary step that is popular nowadays is using Internet Access Message Protocol (IMAP). IMAP is the alternative and popular approach compared to POP, where rather than automatically downloading the email on your device, the messages can be accessed on many devices. The message and attachments will only be downloaded when you want them to. IMAP can be used when offline as well. Most of the time, IMAP is used but POP is still used for people who use email on 1 or 2 devices and have slow internet connections.

Email System Tradeoffs

When building an email system, there are certain tradeoffs that are considered.
The tradeoffs that email system developers have to think about are: functionality, scalability, wide-area performance, data persistence, consistency model, and fault tolerance.

1. Functionality

• Functionalities that you as a user/server can do such as sorting, filtering, searching key text in email, deleting, notifications, and etc.

2. Scalability

• Able to hanlde multiple requests at once, handling millions of requests per day, and so on. The ability to handle a larger amount of work without losing it's performance nor compromising much else like functionality and etc.

3. Wide-area performance

• This involves the wide area network where devices in one area can connect with devices in another area. The perfomrance of this can be important for how fast actions can be performed while communicating data through the wide area network.

4. Data persistence

• Mailboxes such as "Inbox" or "Deleted" or "Starred" and etc are such virtual mailboxes that are maintained. There are millions and billions of emails that must be stored someone and that's typically stored by the email service provider but could be on your own device.

5. Consistency model

• Consistency store deals with the sequence of actions typically with asychonous functions such as reading and writing emails. If this model were to be violated then consequences inconsistent problems can occur such as overwriting something that should've been read first.

6. Fault tolerance

• Can the system continue even though one or more components of a system fails? Email Systems need to be robust and be as functional as possible even if part of a system fails since people expect an email system to be functional almost 99.9% of the time.

Email Adress

• A user of an email system will need to be obviously be provided the ability and funcitonality to send and receive emails. Before someone can send email, an email address is needed.
• All email addreses are unique
  • otherwise if the email addresses are not unique then DNS will consider both email addresses as the same IP address which is used to determine where to send/receive emails.
• Typically an email address will come in this format: Username/AddressName @ DomainName.
  • For example: team@opengenus.org where "team" is the username, @ symbol, and the domain name ("opengenus.org").
• The username will help identify a unque address using the domain name's IP address.

Email

Although you probably know what's in an email, it's still important to know the components that an email is used in composing an email.
A typical email is broken up into two sections, a header and a body.
The header section

• Mandatory sections
  • From: who sent the email
  • To: whom the email is for
  • Date: when was the email sent
• Option sections
  • Subject: what the email may be about
  • CC: who else to include in the email as a recipient of the email
    The body section
• The body section can contain text and other formatted text such as HTML and etc.
• The body section in what's allowed is based on what the service provider allows in the body of an email.

It's important to know the components of an email as these are the conventional standards of a typical email nowadays. Any user using the system will need to know a standard vocabulary that is understandable so the users can use the service correctly.

Email Design System

In the following picture above, this is called an email design system. This idea is brought up as a means of scaling emails. Companies that have lots of emails sent are often going to be formatting emails and they would have to personally test the emails on different devices to ensure that the output, attached links, and etc are all working as intended. Many companies have decided to implement their own personal email design system as a way to not only customize their emails but to create a customizable layout that can be consistent and easier to scale and test.
These componenets are often just the building blocks to an email and the user can simple select what components they may want to tailor their emails to create perhaps a consistently layout without having to personally write any more code.

Ending Note

There are lot more intricate components that are in the background of an email system that I did not cover, but I hope you have a better grasp of an overview of how an email system could potentially be created and the major components that make up our everday email service that we use.

Resources

• Ninja Mail by UC Berkeley
• Guide to using Mail by FreeBSD.