# 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.

Source: emailmarketing.net — https://emailmarketing.net/learn/rfc/rfc5598-email-architecture

To diagnose a delivery problem, or to follow a discussion about one, you need exact names for the parts of the mail system. Statements such as "the MSA should add that header" or "forwarding breaks SPF because the mediator is a new originator" only make sense with these terms.

RFC 5598 is the specification that defines them. It names the components, actors and administrative boundaries that the transport specification ([RFC 5321](https://emailmarketing.net/learn/rfc/rfc5321-smtp)) and the format specification ([RFC 5322](https://emailmarketing.net/learn/rfc/rfc5322-message-format)) assume.

## Two worlds

- **MUA world (users)**: where messages are created and read.
- **MHS (Message Handling Service)**: the store-and-forward network that accepts a message from an Author and delivers it to Recipients. The architecture has three store-and-forward layers: User **Mediators** at the top, **MHS Relays** in the middle, and packet switches at the bottom.

## Actor roles (who is responsible)

| Role | Responsibility |
|---|---|
| **Author** | Creates the content and the recipient list |
| **Originator** | Checks the message against standards and local policy, then submits it, and handles the duties that follow submission. It has "dual allegiance": it works for the Author but enforces the rules of its ADMD |
| **Relay** | Routes, stores and forwards within the MHS, and adds trace information. It MUST NOT change envelope addresses or the meaning of the message |
| **Gateway** | A hybrid of User and Relay that connects different kinds of mail service. It may translate content but must preserve the dialogue between Author and Recipient |
| **Receiver** | Performs final delivery (or redirects the message). It may enforce policy immediately before or after delivery, which is where decisions to deliver to the inbox, file as spam or reject are made |
| **Recipient** | Reads the message, and may reply or send message disposition notifications (MDNs) |
| **Return Handler** (Bounce Handler) | A special recipient of the notifications the MHS generates (DSNs), reached through the return address the Originator supplied |

## Functional components

| Component | Full name | Function | Key facts |
|---|---|---|---|
| **MUA** | Message User Agent | The mail client of the Author (aMUA) or of the Recipient (rMUA) | The aMUA creates and submits. The rMUA displays, replies and files |
| **MSA** | Message Submission Agent | Accepts submission from the aMUA, and enforces ADMD policy and conformance to standards | Port **587** (SUBMISSION, RFC 4409 and 6409), authenticated, compared with port 25 for relay. Split into the aMSA (acts for the Author, and may add `Date:` and `Message-ID:` or fix headers) and the hMSA (acts for the MHS and takes responsibility) |
| **MTA** | Message Transfer Agent | Relays the message one application-level hop over SMTP | Adds `Received:`. Does not change envelope addresses or editorial content (it may re-encode the MIME Content-Transfer-Encoding, CTE). Variants: Boundary (or Border) MTA, which crosses ADMDs, and Outbound, Inbound and Final MTAs |
| **MDA** | Message Delivery Agent | Transfers responsibility from the MHS to the Recipient's environment | Split into the hMDA (facing SMTP) and the rMDA (applies actions at delivery time, for example filtering into folders). Writes `Return-Path:` |
| **MS** | Message Store | Where messages rest | aMS (drafts, queue and sent mail) and rMS (received mail, accessed over IMAP or POP) |

The standard flow runs **from the aMUA to the MSA, through one or more MTAs, to the MDA, the rMS and finally the rMUA.**

## ADMD: Administrative Management Domain

An **ADMD** is a boundary of independent administrative authority. Inside it, one operator's policies apply for authentication, filtering, accountability and content handling. Everything that matters in deliverability happens **at the boundaries between ADMDs**, because that is where parties with no shared control must establish trust. This is what SPF, DKIM and [DMARC](https://emailmarketing.net/learn/authentication/dmarc) authenticate: the sending ADMD to the receiving ADMD.

There are three types. **Edge** ADMDs are organizations at the periphery that run their own mail. **Consumer** ADMDs are mailbox providers that serve end users, typically through web or IMAP access. **Transit** ADMDs are mail service providers and ESPs that relay mail and add value between Edge ADMDs. Edge ADMDs may exchange mail directly with each other. Transit ADMDs aggregate and filter mail, and take on responsibility for the reputation of their customers' mail.

## Mediators vs. relays: why forwarding is special

A **Relay** moves the same message along. Responsibility and the envelope do not change.

A **Mediator** receives a delivered message and **posts it again**. That creates a new transit through the MHS and a new responsibility, and the content may change, while the original Author's `From:` is preserved. Mediators sit between full relaying and full authorship, and they cause most of the edge cases in authentication. SPF breaks because the mediator's IP address is not in the SPF record of the Author's domain, and DKIM may break if the content changes.

| Mediator type | What it does | Identity effects |
|---|---|---|
| **Alias** | Sends the message on to one or more new addresses. The message continues through the transfer service | Keeps the original `MailFrom` (return path), so bounces go to the original Originator. Only `RcptTo` changes. This is classic forwarding in the style of ".forward" |
| **ReSender** (ReDirector) | Inserts a new Recipient into the original exchange | Keeps `From:`, adds `Resent-From:` (the mediator as author) and `Resent-Sender:`, and typically uses a new `MailFrom` |
| **Mailing List** | Collects postings and redistributes them to members | A new `MailFrom` (the list's bounce address). Adds `List-Id:` (RFC 2919) and other list headers. Often modifies the subject or adds a footer, which breaks DKIM |
| **Gateway** | Translates between different kinds of mail service | May rewrite content and addressing as needed, but must keep replies working |
| **Boundary Filter** | A filter for abuse or policy at the edge of an ADMD, which may modify or quarantine messages | Acts as both a receiver and a re-injector |

What this means for deliverability: a forwarder of the Alias type that preserves `MailFrom` breaks SPF at the next hop, unless it rewrites the sender (for example with SRS). A Mailing List that takes ownership of `MailFrom` passes SPF for its own domain, but it must not break alignment for the Author's domain. That need is the practical reason for ARC and for practices that preserve DKIM signatures.

## Identity fields: who sets what

| Identity | Set by | Meaning |
|---|---|---|
| `RFC5321.HELO/EHLO` | SMTP client (MSA or MTA) | The host announcing itself for this hop |
| `RFC5321.MailFrom` | Originator | The return address for notifications at the transfer level. It **need not** be the Author |
| `RFC5321.RcptTo` | Author (or the Final MTA or MDA on redirect) | The envelope recipient, which may never appear in the headers |
| `RFC5322.From` | Author | Who wrote the message (the DMARC identifier) |
| `RFC5322.Sender` | Originator | Who submitted it. If it is absent, the `From:` mailbox is treated as the sender |
| `RFC5322.Reply-To` | Author | Where replies should go |
| `RFC5322.To/Cc/Bcc` | Author | The displayed recipients (Bcc recipients are not disclosed) |
| `RFC5321.Received` | Each relay, mediator or receiver | A trace of hosts and IP addresses |
| `RFC5321.Return-Path` | MDA | Records the `MailFrom` at delivery |
| `RFC3461.ENVID` | Originator | An opaque tracking ID for one transit from posting to delivery (used to match DSNs) |
| `RFC5321.ORCPT` | Originator | The original recipient address, which survives remapping. It is the only reliable way to match a DSN to a recipient |
| `RFC2919.List-Id` | Mediator (list) | A globally unique list name that does not depend on any host |

Three separate identities look like "the sender": `MailFrom`, `From:` and `Sender:`. Two different roles set them, and that is exactly why email authentication needed the concept of alignment ([DMARC](https://emailmarketing.net/learn/authentication/dmarc)).

## Ports and protocols quick reference

| Port / protocol | Use |
|---|---|
| 25 / SMTP | Relay from MTA to MTA across ADMDs |
| 587 / SUBMISSION | Submission from the aMUA to the MSA, authenticated (submission over implicit TLS on port 465 was added later, by RFC 8314) |
| IMAP / POP | Access from the rMUA to the Message Store |
| LMTP | Delivery from the MHS to the MDA without queuing |
| ETRN / ODMR | Transfer from the MHS on request ("on-demand"), pulled by the receiving side |

## Related articles

- [RFC 5321: SMTP](https://emailmarketing.net/learn/rfc/rfc5321-smtp), the relay protocol these components use
- [RFC 5322: Message Format](https://emailmarketing.net/learn/rfc/rfc5322-message-format), the header fields each actor sets
- [Foundations of Email Deliverability](https://emailmarketing.net/learn/foundations/foundations-of-email-deliverability), on how receiving ADMDs decide placement