Email Protocols

Introduction: how email works

Electronic mail, or email, is a basic Internet service. A user composes a message, enters a recipient's address, and sends it from a mail client. A message contains headers and a body, while MIME can encode attachments. Delivery requires several software components and protocols operating across successive mail servers.

Delivery of a single email may involve several servers. The system uses a store-and-forward model: a message is temporarily stored at an intermediate node and forwarded when the next server is available. A server can queue a message and retry after a transient error. This model lets mail processing continue when part of the network is temporarily unavailable. Mail protocols define separate procedures for sending a message, relaying it between servers, and reading mailbox contents.

Roles of email components

Email handling uses three software-agent roles on clients and servers. They separate message composition, transfer, and final placement in the mailbox.

• 1. Mail user agent (MUA): the client

  The MUA is the program the user operates directly. It can be a desktop application such as Microsoft Outlook, Apple Mail, or Thunderbird, or a browser-based interface such as Gmail or Outlook.com. The MUA helps compose messages, read incoming email, manage folders, and communicate with mail servers to send and retrieve messages. It may also keep a local copy of downloaded data. From the user's perspective, it handles message creation and reading.

• 2. Mail transfer agent (MTA): the relaying server

  The MTA is server software that receives email from an MUA or another MTA and relays it towards the destination server. After receiving a message, the MTA examines the recipient address, uses DNS records, especially MX records, to determine the next mail server, and forwards the message. It may queue the message and retry after a transient error. An email may pass through several MTAs.

• 3. Mail delivery agent (MDA): placing messages in mailboxes

  The MDA performs final delivery on the server side. After an email reaches the recipient's destination server, the MDA places it in the correct user's mailbox. Depending on the implementation, it may also filter spam, scan for malicious software, and apply sorting rules to a selected folder.

The sending protocol: SMTP (Simple Mail Transfer Protocol)

The Simple Mail Transfer Protocol, or SMTP, defines the commands and responses used to send and relay email between clients and mail servers. It is used for server-to-server transfer and for message submission by a client. Acceptance by one server does not by itself mean final delivery.

Key characteristics of SMTP

• Push Protocol:SMTP is a "push" protocol. It transfers messages from a sender to a receiver. An MUA sends a message to its MTA, which sends it to the next MTA. POP and IMAP retrieve messages from a mailbox.
• Connection-Oriented and Reliable: SMTP usually uses the Transmission Control Protocol (TCP), which provides an ordered, reliable byte stream. SMTP responses determine the transaction result, including whether the message was accepted or rejected. TCP delivers data for the connection, while SMTP servers and their queues also determine the message outcome.
• Standard Ports: SMTP uses specific network ports for communication:
  • Port 25: The traditional port used for relaying mail between MTAs (server-to-server). It is mainly intended for server-to-server traffic.
  • Port 587: The standard port for message submission from an MUA to an MTA. Configurations on this port commonly use authentication and STARTTLS.
  • Port 465: A port for message submission with implicit TLS. The TLS handshake starts before SMTP commands are exchanged.
• Text-Based Communication: SMTP commands and server responses are text-based and line-oriented. An email contains headers and a body defined by RFC 5322, while MIME can encode attachments and other data. The command exchange is separate from the message content sent after DATA.

A typical SMTP conversation (commands)

Communication between an SMTP client and server follows an established sequence of commands and responses. Server reply codes indicate success, a transient error, or a permanent error. Examples include:

• HELO / EHLO: The client initiates the session by identifying itself. 'EHLO' (Extended HELO) also requests a list of extensions supported by the server.
• MAIL FROM: The client specifies the sender's email address. This command starts the mail transaction.
• RCPT TO: The client specifies a recipient's email address. This command can be issued multiple times if there are several recipients.
• DATA: After specifying recipients, the client issues the 'DATA' command to indicate it is ready to send the actual email content (headers and body).
• QUIT: The client issues this command to terminate the SMTP session gracefully.

Receiving protocols: POP3 and IMAP

After the MDA places an email in the recipient's server mailbox, the recipient's MUA needs a protocol to retrieve it. POP3 and IMAP provide different models for accessing the mailbox. POP3 focuses on downloading messages, while IMAP also exposes server-side folders and message state.

POP (Post Office Protocol) and POP3 (Version 3)

POP is among the older and simpler protocols for retrieving email. POP3 is the version most commonly encountered. It downloads messages from the server to the client according to the client's settings. A POP3 session has authorization, transaction, and update phases.

The POP3 model: download and delete

A typical POP3 configuration has the email client (MUA) connect to the server, download new messages to the local device, such as a computer or phone, and then delete them from the server. With these settings, the primary copy of the email resides on the local device. The client can issue commands to retrieve messages and mark them for deletion; the server removes marked messages when the session enters the update phase.

• Offline Access: Once messages are downloaded, the client can read and manage them without an active Internet connection.
• Server Space: A configuration that deletes messages after download uses little server storage.
• The "Leave a copy" Option: Most clients can leave a copy of messages on the server for a chosen period. This option does not synchronize shared mailbox state across devices. An email read on a desktop may still appear unread on a phone, and a message deleted on a phone may remain on the desktop. Folders and sent items are not synchronized in this model.
• Standard Ports: POP3 uses Port 110 for unencrypted connections and Port 995 for secure connections using implicit TLS (POP3S), where the TLS handshake starts before POP3 commands. Transport protection requires TLS on the selected port or a provider-specific configuration.

POP3: POP3 is a simple, older protocol suited to users who access email from one primary device and keep a local archive. With multiple devices, it does not provide shared folder and message state.

IMAP (Internet Message Access Protocol)

IMAP was designed for managing mail stored on a server, especially when users access it from several devices. The protocol exposes mailbox state and operations on messages and folders to the client. A client can select a mailbox, fetch its data, and update message flags.

The IMAP model: a synchronized remote mailbox

With IMAP, email and folder structure are stored on the mail server. The email client (MUA) reads the mailbox state and sends operations such as marking a message read, moving it, or deleting it. The server stores these changes, and other devices can reflect them during their next synchronization.

• State Synchronization: Read/unread status, deletions, drafts, sent items, and the folder hierarchy are stored on the server and made available to desktop, phone, and webmail clients during synchronization.
• Server-Side Storage: Messages remain on the server and are stored centrally. The provider may create backups, depending on the service. A local computer failure does not remove the copy held on the server.
• Partial Fetching: IMAP lets the MUA download headers first, so it can inspect the mailbox without downloading large attachments. The client can then fetch the full body and attachments for selected messages. This reduces transfer on mobile devices and slower connections.
• State Management: IMAP keeps track of message states using flags, such as '\Seen' (read), '\Answered', '\Flagged' (starred), and '\Deleted' (marked for removal). Expunging the mailbox removes messages marked with this flag, and the flags are synchronized across clients.
• Standard Ports: IMAP uses Port 143 for unencrypted connections and Port 993 for secure connections using implicit TLS (IMAPS). Port 143 can also start without protection and upgrade to TLS when the server supports it.

IMAP: IMAP suits access from multiple devices because it stores mailbox state on the server and exposes it to clients. A client may also keep a local cache for offline reading, while state changes reach the server after synchronization. The server remains the reference for shared mailbox state. Full synchronization requires periodic connections to the server, and messages consume server storage.