How email moves

The parts of an email system

Name the agents that compose, submit, relay, deliver, store, and display one email message.

Email is not one protocol connecting two inboxes. It’s a chain of small programs, each with one job. Once you know the jobs, every protocol in this course has an obvious place.

Here are the names. I’ll use them in every lesson.

The mail user agent (MUA) is the app where you write and read mail. Apple Mail, Thunderbird, the Gmail web page. The mail submission agent (MSA) is the server that accepts outgoing mail from your app. Mail transfer agents (MTAs) relay the message between domains. The mail delivery agent (MDA) drops it into the recipient’s mailbox.

Then the recipient reads that mailbox. Their app uses an access protocol like IMAP or POP3, or a web interface, to show the stored message.

Learning the roles first saves you from a common mistake: expecting one protocol to do every job. SMTP moves mail. IMAP reads it. Nothing does both.

Follow the ownership of one message

Suppose I send a message from [email protected] to [email protected]. This is who holds it at each step:

flowchart LR
  accTitle: The parts of an email system
  accDescr: A mail user agent submits a message to an MSA, two MTAs relay it, an MDA delivers it to the message store, and the recipient reads it with another MUA.
  Sender["Sender MUA"] --> MSA
  MSA --> Sending["Sending MTA"]
  Sending --> Receiving["Receiving MTA"]
  Receiving --> MDA
  MDA --> Store["Message store"]
  Store --> Recipient["Recipient MUA"]

Every arrow is a handoff. At each one the message can be accepted, rejected, queued, or changed.

When my provider’s MSA answers 250 OK, it means one thing: that server now owns the message. It does not mean Sara has it. Her server hasn’t even been contacted yet.

One product, several roles

In practice the same product plays many roles. Fastmail, Google, or a self-hosted Postfix box can run submission, relay, filtering, delivery, and storage behind one hostname.

Keep the roles separate in your head anyway. When something breaks, the question is always “which handoff failed?”, and you can only answer it if you know the handoffs exist.

What this looks like when it fails

Say Sara never receives my message, but my app shows it in Sent. The Sent folder only proves the first arrow worked. The sending MTA might still be retrying against mx.studiorossi.it, or her MDA might have filed it in Spam.

My advice: draw the path for a message you send from your own account. Mark who owns it after each successful handoff, and where you’d look for evidence (client log, provider log, receiving server, mailbox) if it stops.

Lesson completed