Actors, Protocols, and Standards

Chapter 1 established that Internet Mail progresses across independently operated systems, and that a success report at one boundary does not prove the whole journey finished. That leaves a practical question: if the path is made of cooperating systems, what are those systems doing?

People often answer with product names—“Gmail,” “Postfix,” “Outlook,” “the mail server.” Those names matter later. First you need the architectural vocabulary: which role is being performed, and what shared rules let independently operated systems talk to each other.

Why This Matters

Without role vocabulary, every hop collapses into “the mail server.” Troubleshooting then starts in the wrong place: you argue about products before you know whether you are looking at submission, transfer, or delivery.

Without a clean distinction between a protocol and a document that describes it, operators also confuse wire behavior with paperwork—“SMTP is RFC 5321,” or “an RFC is a protocol,” or “every RFC is an Internet Standard.” Those shortcuts make later chapters harder, not easier.

This chapter stays at map depth. It names the primary roles and the protocol/document distinction so the rest of the Handbook can be precise.

Roles Before Machines

Internet Mail architecture talks about actors and roles—responsibilities on the path—not a requirement that each label be a separate physical machine, product, or organization (RFC 5598). Modern submission and transfer language likewise describes processes that perform those jobs (RFC 6409). SMTP terminology warns that sharp boundaries between “user agent” and “transfer agent” language often do not match every conforming deployment (RFC 5321).

So the first safeguard is simple:

Roles may combine, co-locate, distribute across components, or repeat along a path. One product may perform more than one role. One organization may operate many roles. An administrative domain can contain a complex arrangement of functional components (RFC 5598).

The Four Primary Roles

For orientation, this chapter introduces four primary role labels: MUA, MSA, MTA, and MDA, plus mailbox as the delivery destination that orients the map. The architectural definitions below are grounded in Internet Mail architecture and related standards (RFC 5598; RFC 6409).

MUA — Message User Agent

The MUA works on behalf of users and user applications inside the email service (RFC 5598; RFC 6409).

In ordinary terms: it is the user-side role involved in creating and submitting outgoing mail, and/or in processing mail that has already been delivered. An authoring MUA creates a message and performs initial submission toward an MSA. A recipient MUA works on received mail after delivery into the recipient environment.

An MUA is not “always a desktop app,” and it is not required to be a single local program (RFC 5598). Keep the idea light: user-side role, not a product brand.

MSA — Message Submission Agent

The MSA is the submission-side role. It accepts a message from an authoring MUA, enforces local policy and Internet standards requirements for posting, and introduces the message into the Message Handling Service (RFC 5598). It may then deliver or relay onward to an MTA (RFC 6409).

Map-level meaning: submission into the mail handling system. Authenticated submission ports, AUTH mechanisms, and operational submission policy belong later.

MTA — Message Transfer Agent

The MTA is the transfer/relay role. It moves a message for an application-level hop toward its recipients without rewriting editorial content as a new authoring step (RFC 5598; RFC 6409).

When systems use SMTP to transfer mail, the transfer role is the MTA (RFC 5321). That does not mean every colloquial “mail server” is an MTA. A host called “the mail server” might be performing submission, transfer, delivery, mailbox access, or a combination.

A path may include one or more transfer/relay stages—or a shorter path (RFC 5598; RFC 5321). Do not memorize “always exactly one MTA.”

MDA — Mail Delivery Agent

The MDA is the delivery-side role: transfer of responsibility from the Message Handling Service into the recipient’s environment—toward the mailbox (RFC 5598).

A mailbox receives mail. It is a conceptual destination and does not necessarily mean a particular file on disk (RFC 5598). Critically:

Inbox folders, spam folders, and filtering outcomes are later topics. This chapter only needs the delivery destination on the map.

Submission, Transfer, and Delivery

These three words organize the path without teaching SMTP commands.

Submission is the message entering the mail handling system from the user/client side—MUA to MSA posting (RFC 5598; RFC 6409).

Transfer (relay) is the message moving between transfer roles toward recipients—MTA to MTA, where applicable. Modern standards deliberately split submission from relay so each service can operate under its own rules (RFC 6409).

Delivery is responsibility moving into the recipient environment/mailbox via the MDA (RFC 5598).

SMTP was defined as a message transfer protocol and is also widely used as a message submission protocol; the submission service is specified separately so those jobs are not treated as identical (RFC 6409; RFC 5321). Keep that conceptual here. Ports, AUTH, and session mechanics wait for later chapters.

Teaching Model: Actor Path

MUA
  ↓  submission
MSA
  ↓
[MTA transfer / relay stage(s), 0..n]
  ↓  delivery
MDA
  ↓
Mailbox

Read this as a map of responsibilities, not a floor plan of servers.

Caveats you must keep attached to the model:

Roles may combine or co-locate in one implementation.

Transfer/relay stages may repeat, or a simplified path may show fewer hops.

Real deployments vary; the model orients vocabulary, it does not certify one canonical machine sequence.

Other edge cases and administrative-boundary detail stay light in this chapter.

Protocols Are Not Products

A protocol is how particular capabilities are performed—the shared rules and behavior systems use when they communicate (RFC 5598).

SMTP (Simple Mail Transfer Protocol) is the Internet’s primary mail transport protocol: the conversation semantics used to transfer mail between participating systems (RFC 5321). Saying “SMTP” names the protocol. Saying “an SMTP server” names a process participating in that protocol. Those are related sentences, not synonyms.

SMTP transfers are typically point-to-point. A message may traverse intermediate systems, or it may transfer in a shorter path (RFC 5321). That continues Chapter 1’s point: Internet Mail is not one continuous end-to-end chat from author to mailbox.

Protocol vs Specification vs RFC

SYSTEM A
   │
   │  communicates using a protocol
   ▼
SYSTEM B

         ↑
  behavior specified / documented by
         │
SPECIFICATION / RFC DOCUMENT

Three distinctions matter for the rest of the Handbook:

1. Protocol — the rules/behavior on the path between systems (RFC 5598).

2. Specification / standards document — the written definition of expected interoperable behavior.

3. RFC — a document published in the RFC series.

Therefore:

An RFC is not automatically “the protocol.”

Systems do not “speak an RFC”; they implement protocol behavior described by documents.

One protocol may be specified across documents over time.

SMTP and RFC 5321: RFC 5321 is the current base Standards Track specification of SMTP behavior (RFC 5321). That is a precise relationship. It is not the slogan “SMTP = RFC 5321,” as if the protocol name and a single document number were identical forever. Submission behavior, for example, is addressed by the Message Submission standard as its own specification (RFC 6409).

RFC status is not uniform. Publication as an RFC does not by itself make a document an Internet Standard. Being on the Standards Track is also not the same thing as already having Internet Standard status. The sources used for this chapter illustrate the point: RFC 5598 is Informational architecture; RFC 5321 is Standards Track; RFC 6409 is Internet Standard. Status must be read from the document, not inferred from the letters “RFC.”

Why Shared Standards Matter

Chapter 1’s interoperability precept is the bridge into this section: Internet Mail is designed so users and transfer systems can interoperate without prior direct arrangement between every pair of independent administrative authorities that will handle a message (RFC 5598).

That only works if participants can rely on shared behavior—protocols and the specifications that define them. Independently operated systems do not need to share a vendor. They need enough shared protocol expectations to hand a message across a boundary and continue.

Operator Perspective

When you diagnose an email problem, ask first:

Submission? Transfer/relay? Delivery? User agent?

Then ask which product, host, or provider implements that role.

Role-first reasoning prevents the most common operator collapse: treating every component as “the mail server,” then guessing. It also prepares the next chapter: once you can name the role, you will need to identify the host that performs it.

Common Misconceptions

Key Takeaways