RFC 5598 — Internet Mail Architecture
The vocabulary of email: MUA/MSA/MTA/MDA, ADMDs, actor roles, mediators vs. relays, and which actor sets which identity field.
RFC 5598 is the terminology spec: it names the components, actors, and administrative boundaries that the transport (RFC 5321) and format (RFC 5322) specs assume. Deliverability discussions — "the MSA should add that header", "forwarding breaks SPF because the mediator is a new originator" — depend on these exact terms.
Two worlds
- MUA world (users): creation and consumption of messages.
- MHS (Message Handling Service): the store-and-forward network that accepts a message from an Author and delivers it to Recipients. Architecturally there are three store-and-forward layers: User Mediators on top, MHS Relays in the middle, packet switches below.
Actor roles (who is responsible)
| Role | Responsibility |
|---|---|
| Author | Creates content and the recipient list |
| Originator | Validates the message against standards and local policy, then submits it; handles post-submission duties. Has "dual allegiance": works for the Author but enforces its ADMD's rules |
| Relay | Routes and store-and-forwards within the MHS; adds trace info; MUST NOT change envelope addresses or message semantics |
| Gateway | Hybrid User/Relay bridging heterogeneous mail services; may translate content but must preserve the Author–Recipient dialogue |
| Receiver | Performs final delivery (or redirects); may enforce policy immediately before/after delivery — this is where inbox/spam/reject decisions live |
| Recipient | Consumes the message; may reply or emit MDNs |
| Return Handler (Bounce Handler) | Special recipient of MHS-generated notifications (DSNs), addressed via the return address the Originator supplied |
Functional components
| Component | Full name | Function | Key facts |
|---|---|---|---|
| MUA | Message User Agent | Author's (aMUA) or Recipient's (rMUA) mail client | aMUA creates + submits; rMUA displays, replies, files |
| MSA | Message Submission Agent | Accepts submission from the aMUA; enforces ADMD policy and standards conformance | Port 587 (SUBMISSION, RFC 4409/6409), authenticated — vs. port 25 for relay. Split into aMSA (acts for the Author; may add Date:, Message-ID:, fix headers) and hMSA (acts for the MHS; takes responsibility) |
| MTA | Message Transfer Agent | Relays one application-level hop via SMTP | Adds Received:; doesn't change envelope addresses or editorial content (may re-encode MIME CTE). Variants: Boundary/Border MTA (crosses ADMDs), Outbound, Inbound, Final |
| MDA | Message Delivery Agent | Transfers responsibility from the MHS to the Recipient's environment | Split into hMDA (SMTP-facing) and rMDA (applies delivery-time actions, e.g., filtering into folders); writes Return-Path: |
| MS | Message Store | Where messages rest | aMS (drafts/queue/sent), rMS (received; accessed via IMAP/POP) |
Canonical flow: aMUA → MSA → (MTA → … → MTA) → MDA → rMS → rMUA.
ADMD — Administrative Management Domain
An ADMD is a boundary of independent administrative authority: one operator's policies for authentication, filtering, accountability, and content handling apply inside it. Everything interesting in deliverability happens at ADMD boundaries — that's where trust must be established between parties with no shared control (this is what SPF/DKIM/DMARC authenticate: the sending ADMD to the receiving ADMD).
Types: Edge ADMDs (organizations at the periphery running their own mail), Consumer ADMDs (mailbox providers serving end users, typically web/IMAP access), Transit ADMDs (mail service providers/ESPs relaying and adding value between Edge ADMDs). Edge ADMDs may exchange directly peer-to-peer; Transit ADMDs aggregate, filter, and take on reputation responsibility for their customers' mail.
Mediators vs. relays — why forwarding is special
A Relay moves the same message along; responsibility and envelope are unchanged.
A Mediator receives a delivered message and re-posts it: a new MHS transit, new responsibility, potentially modified content — while preserving the original Author's From:. Mediators sit between full relaying and full authorship, and they are the root cause of most authentication edge cases (SPF breaks because the mediator's IP isn't in the Author domain's SPF; DKIM may break if content changes).
| Mediator type | What it does | Identity effects |
|---|---|---|
| Alias | Re-addresses to one or more new addresses; message continues through the transfer service | Keeps original MailFrom (return path) — so bounces go to the original Originator; only RcptTo changes. Classic ".forward"-style forwarding |
| ReSender (ReDirector) | Splices a new Recipient into the original exchange | Keeps From:; adds Resent-From: (mediator author) and Resent-Sender:; typically new MailFrom |
| Mailing List | Aggregates postings, redistributes to members | New MailFrom (list bounce address), adds List-Id: (RFC 2919) and list headers; often modifies subject/footer (breaking DKIM) |
| Gateway | Translates between heterogeneous mail services | May rewrite content and addressing as needed; must keep replies workable |
| Boundary Filter | Anti-abuse/policy filter at an ADMD edge; may modify or quarantine | Acts as receiver+re-injector |
Deliverability takeaway: an Alias-style forwarder that preserves MailFrom breaks SPF at the next hop (unless it rewrites the sender, e.g., SRS); a Mailing List that takes ownership of MailFrom passes SPF for its own domain but must not break the alignment story of the Author domain — the practical driver behind ARC and DKIM-preservation practices.
Identity fields — who sets what
| Identity | Set by | Meaning |
|---|---|---|
RFC5321.HELO/EHLO |
SMTP client (MSA/MTA) | Host announcing itself for this hop |
RFC5321.MailFrom |
Originator | Return address for transfer-level notifications; need not be the Author |
RFC5321.RcptTo |
Author (or Final MTA/MDA on redirect) | Envelope recipient; may never appear in headers |
RFC5322.From |
Author | Who wrote the message (the DMARC identifier) |
RFC5322.Sender |
Originator | Who submitted it; if absent, the From: mailbox is the virtual sender |
RFC5322.Reply-To |
Author | Where replies should go |
RFC5322.To/Cc/Bcc |
Author | Displayed recipients (Bcc undisclosed) |
RFC5321.Received |
Each relay/mediator/receiver | Trace of hosts and IPs |
RFC5321.Return-Path |
MDA | Records MailFrom at delivery |
RFC3461.ENVID |
Originator | Opaque tracking ID for one posting→delivery transit (DSN correlation) |
RFC5321.ORCPT |
Originator | Original recipient address, surviving remapping — the only reliable DSN-to-recipient correlation |
RFC2919.List-Id |
Mediator (list) | Globally unique, host-independent list name |
Three separate "sender-ish" identities — MailFrom, From:, Sender: — set by two different roles, is exactly why email authentication needed the alignment concept (DMARC).
Ports and protocols quick reference
| Port / protocol | Use |
|---|---|
| 25 / SMTP | MTA↔MTA relay across ADMDs |
| 587 / SUBMISSION | aMUA→MSA, authenticated (465 implicit-TLS submission is the later RFC 8314 addition) |
| IMAP / POP | rMUA ↔ Message Store access |
| LMTP | MHS→MDA delivery without queuing |
| ETRN / ODMR | Pull-based ("on-demand") MHS transfer |
See also
- RFC 5321 — SMTP — the relay protocol these components speak.
- RFC 5322 — Message Format — the header fields each actor sets.
- Foundations of Email Deliverability — how receiving ADMDs decide placement.