Protocols along the path

Email uses a lot of acronyms. Each one belongs to one spot on the path a message takes. Let me place them.

SMTP submits and transfers mail. It’s the protocol that moves bytes from my app to my provider, and from my provider to Sara’s server.

RFC 5322 is the basic message format: headers, a blank line, a body. MIME extends that format with content types, character sets, multiple parts, and attachments.

POP3 downloads messages from a mailbox to one client. IMAP keeps the mailbox on the server and synchronizes several clients with it.

LMTP is a close cousin of SMTP used for the last step, dropping mail into the mailbox system. Sieve is a small language for server-side filtering rules.

JMAP is the newest one. It exposes mail data through HTTP and JSON, for clients that would rather not speak IMAP.

On one line

Put them on the path and the list stops being scary:

compose RFC 5322 + MIME message
  -> submit with SMTP
  -> relay with SMTP
  -> deliver with SMTP or LMTP
  -> filter with Sieve
  -> store in a mailbox
  -> access with POP3, IMAP, or JMAP

Notice two groups. RFC 5322 and MIME are formats. They describe what the bytes look like. Everything else is a protocol, a conversation between two programs.

Things that don’t replace each other

IMAP and JMAP work on stored mail. Neither one carries a message from my domain to Sara’s. Only SMTP does that between unrelated servers, and that’s unlikely to change.

Sieve runs on the server, right after delivery. That’s why a Sieve rule works even when your laptop is closed, while a Thunderbird filter doesn’t.

Why the map matters when debugging

Each layer fails in its own way. Knowing the layer tells you where to look.

A malformed MIME boundary makes an attachment unreadable. SMTP delivery still succeeded, and the Received headers look perfect. The bug is in the format, not the transport.

An IMAP sync problem hides a delivered message on your phone. It’s still on the server, and webmail shows it. The bug is in access.

A 550 during RCPT TO means the message never left the sender’s side. Nothing downstream ever saw it.

Try classifying these three by layer: a 550 at RCPT TO, an attachment that decodes as garbage, and a message visible in webmail but missing on a phone. If you can name the layer, you already know which tool to open next.