Pedro Paiva

Email learning series

How email works: the components behind a message

By Pedro Paiva

Our application sends a welcome email to reader@example.net. Later, the reader opens it on a phone. Between those two actions, several pieces of software do different jobs. Sending the message and opening the mailbox are separate parts of the system.

In the SES introduction, we followed what happens after a send request succeeds. Here, we’ll look at the components behind that journey, including the reader’s side. All addresses and domains in this example are fictional.

An old system with familiar roles

Email’s architecture has evolved over decades. In 1982, RFC 821 specified SMTP, the Simple Mail Transfer Protocol, for transferring mail. Later standards developed ways for personal computers to retrieve messages from a server and manage mailboxes remotely: POP3 and IMAP.

Today’s services are much larger, but the basic division remains useful: a client prepares a message, servers move it toward its destination, and a client helps the recipient access it. RFC 5598 describes these as separate architectural roles. They don’t have to be separate machines. One provider can run several of them, and one program can perform more than one role.

The client starts the conversation

An email client is the software a person uses to compose, read, and organize messages. A desktop mail app is one example. The standards call this a message user agent, or MUA.

Our web application also prepares messages, although nobody presses a Send button in a mail app. After registration, it creates a welcome email with a recipient, subject, and body. It then hands that message to a sending service rather than contacting every recipient’s mail server itself.

The first server-side role is submission: accepting a message from an authorized sender. The component responsible for that is a mail submission agent, or MSA. For an ordinary email client, submission commonly uses SMTP with authentication. A provider can also offer an API for applications. In our example, the application calls the SES HTTPS API; an SMTP client could use SES’s SMTP interface instead.

Those are different interfaces to the sending service. Using an HTTP API at the first step doesn’t mean that the message travels over HTTP between mail providers.

Servers move the message; a mailbox holds it

Once submitted, the message needs to reach the mail system responsible for example.net. A message transfer agent (A server component that transfers email toward its destination, typically using SMTP. Often abbreviated MTA.) handles this part. A sending system can look up the destination and transfer the message directly, or the route can include additional relay servers.

SMTP is the protocol used for this server-to-server transfer as well as for SMTP-based submission. Its conversation tells the sending side whether the receiving side accepts or rejects the transfer. Submission and transfer have different authorization and operational requirements, even though both can use SMTP.

The receiving server is the entry point to the recipient’s mail system. After accepting a message, that system still has work to do: apply its rules and get the message to the recipient’s storage. The role that performs final delivery is a mail delivery agent, or MDA. The exact internal arrangement varies by provider; the receiving SMTP server, filters, and delivery component may be parts of one service.

The mailbox is where the recipient’s messages are stored. It can contain an inbox and other folders, including a spam folder. It isn’t the same thing as the receiving SMTP server or the reader’s phone. The phone can disconnect while the server continues receiving and storing mail.

As the introductory article explains, server acceptance alone doesn’t tell us which folder a message reaches or whether anyone reads it. We’ll keep that distinction while adding the mailbox-access step.

A map of our welcome email

This is one possible route, with internal relays and filters omitted:

Application or sender's email client
  |
  | SMTP submission, or SES HTTPS API
  v
Sending service (AWS SES here)
  |
  | SMTP transfer
  v
Recipient's receiving mail server
  |
  | Final delivery inside its mail system
  v
Recipient's mailbox
  ^
  | IMAP access or POP3 retrieval
  v
Recipient's email client

The last connection is a client accessing stored messages, not another SMTP delivery hop. The two arrows represent interaction between the client and mailbox service: the client requests information or changes, and the server responds. They don’t mean that POP3 and IMAP have identical capabilities.

AWS SES occupies the sending-service box in this example. It handles onward SMTP transfer after our application submits the welcome email. The recipient uses their own provider’s mailbox service to read it.

SES also has a separate email-receiving feature, which can route incoming mail to processing actions such as storage in Amazon S3. That doesn’t make SES an IMAP or POP3 mailbox server for the reader’s email client. Sending, processing inbound messages, and providing an interactive mailbox are different services.

IMAP and POP3 start from stored mail

IMAP (The Internet Message Access Protocol lets a client access and manage messages and folders on a mail server.) supports working with a mailbox on the server: fetching messages, searching, organizing folders, and updating flags such as whether a message has been seen. A client can keep a local copy and synchronize with the server later. This is useful when the reader checks the same mailbox on a phone and a laptop.

POP3 (The Post Office Protocol version 3 lets a client retrieve messages held by a mail server, with more limited server-side mailbox management than IMAP.) focuses on retrieving messages from a server. It doesn’t provide IMAP’s folder-management and synchronization model. Downloading a message doesn’t inherently mean it must disappear from the server: POP3 includes explicit deletion commands, and clients can be configured to leave messages there. Retention also depends on the service’s policies.

Neither protocol is the usual mechanism for submitting a new outgoing message. An email client can use IMAP to read incoming mail and SMTP to submit outgoing mail, even when both connections go to the same provider.

Webmail adds another interface. When the reader opens a mailbox in a browser, the browser talks to the web application over HTTPS. The provider handles mailbox access behind that interface; the browser doesn’t have to speak IMAP or POP3 directly.

Where would you look when something goes wrong?

Suppose the reader says, “Your welcome email never arrived.” That could mean the message never reached their mailbox, landed in spam, or reached the mailbox but hasn’t appeared on their phone.

Start by checking the sending side: did SES accept the request, and what delivery or bounce information is available? If the recipient can see the message in webmail but not on their phone, the investigation shifts to the phone’s mail app and its mailbox connection or synchronization.

Sending a reply is a separate operation. A mail app might read messages successfully through IMAP while failing to send through SMTP because its outgoing settings or credentials are incorrect.

Each component handles a different step. Identifying the step that failed helps you decide where to investigate.

References