IMAP, SMTP, OAuth — what actually happens when you connect an account

Connecting an email account to a new client looks like a single click. It is not. Behind it are three protocols, each from a different decade, each with its own quirks. Knowing how they work is useful when something breaks, when you are auditing privacy, or when you want to understand why your “reply from the right address” failed.

This is the plain-language version.

SMTP: how email gets sent

SMTP stands for Simple Mail Transfer Protocol. It was designed in 1982. It does one thing: it accepts an email message and forwards it toward the recipient.

When you hit send in any email client, here is roughly what happens:

1. Your client opens an authenticated SMTP connection to your provider's outbound server (smtp.gmail.com, smtp.office365.com, etc.).
2. It sends the message, including from, to, subject, body, attachments.
3. The provider's SMTP server passes the message toward the recipient's domain by looking up the recipient's MX records.
4. The recipient's server accepts the message, runs spam filters, and delivers it to the recipient's mailbox.

That is the entire send path. SMTP is, in a real sense, a relay system. Each hop is encrypted in transit (TLS) but the message is decrypted at every server.

IMAP: how email gets read

IMAP is the Internet Message Access Protocol. It was standardized in 1986. It lets a client read, organize, and sync mail that lives on a server.

When you open your email client and see your inbox, here is what is happening:

1. Your client opens an authenticated IMAP connection to your provider's server.
2. It asks: “what folders exist? How many messages in inbox?”
3. It downloads message headers, then bodies on demand.
4. When you mark something read or move it to a folder, your client tells the IMAP server to update the state.

IMAP is the reason your inbox is the same on three devices. The server is the source of truth. Each client is a window into it.

OAuth: how authentication is supposed to work

OAuth replaces passwords for connecting third-party apps to your account.

Old way: you would type your Gmail password into Apple Mail, and Apple Mail would store it. If Apple Mail got compromised, your Gmail password leaked. Bad.

OAuth way: when you connect Gmail to a new client, you go to Google's sign-in page, log in, and grant the new client a scoped token. The client never sees your password. Google issues a token with specific permissions (“read mail, send mail, manage settings, no other Google apps”). The client uses the token. If something goes wrong, you revoke the token and the client is locked out without you changing your password.

OAuth, when done well, is one of the better security improvements of the last 15 years. Done badly, it is a license to over-scope access.

What “connect your account” really does

When you connect a Gmail account to STAMP (or any modern client), the flow is:

1. The client opens a browser to Google's OAuth consent page.
2. You approve specific scopes. STAMP requests scopes for reading and sending mail and for marking read state. Nothing else.
3. Google issues an access token and a refresh token to the client.
4. The client uses the access token for IMAP and SMTP-equivalent calls (Gmail uses its API, not raw IMAP, in many cases).
5. When the access token expires (usually after an hour), the refresh token gets a new one without re-prompting you.

The same flow works for Outlook, iCloud (with app-specific passwords for now), and any provider that supports OAuth. Custom IMAP servers without OAuth still use passwords, which we strongly recommend pairing with a per-client app password if your provider supports it.

Where leaks happen

Three weak points in the chain.

One: the client's credential storage. A client storing OAuth tokens insecurely on disk is a vulnerability. STAMP stores tokens in macOS Keychain, encrypted at rest, scoped to the app.

Two: the SMTP relay path. Mail in transit is TLS-encrypted to your provider, but the message bodies are decrypted on the receiving server. End-to-end encryption (PGP, S/MIME) is rare. If you need true end-to-end, those tools exist; we do not currently ship them.

Three: third-party AI processing. This is the modern leak. If your client sends email content to a third-party AI service for processing, that is a fourth party with access. We covered this in why your email client should not read your email.

What good clients do at this layer

Five things we look for in any email client's connection layer:

1. OAuth instead of passwords wherever possible.
2. Scoped tokens (not “all Google access”).
3. Local credential storage in the OS keychain.
4. TLS-only connections to provider servers.
5. No middleware servers between you and the provider for routine sync.

STAMP does all five. Most modern clients do four of the five. The middleware-server case (where a client's server sits between you and Gmail to make sync easier) is a structural privacy concern. Some clients have it. We do not.

A client that puts its own server between you and Gmail is asking you to trust two companies instead of one.

What about IMAP IDLE and push notifications

A modern client wants to know about new mail in real-time. Two ways this happens.

IMAP IDLE. A long-running connection where the server pushes notifications. STAMP uses this where supported. Battery cost is real but acceptable.

Provider push. Gmail's API and Microsoft Graph offer push subscriptions where the provider tells your app, via a webhook or websocket, that something changed. Faster but requires either a backend server (us) or some constraints. We use IMAP IDLE primarily and provider push selectively.

In neither case does new-mail notification require sending email content to anyone. The notification is “something changed in folder X.” The client then asks for the new content directly from the provider.

What this means in practice

For most users, none of this is interesting until something breaks. Five practical takeaways:

• If a client asks for your password instead of opening a Google sign-in, be skeptical.
• If a client asks for permissions beyond mail, be skeptical (“view your calendar,” “manage your contacts” might be legitimate, might not).
• Revoke OAuth tokens at myaccount.google.com/permissions when you stop using a client.
• For custom IMAP, use app-specific passwords.
• Audit your provider's “connected apps” list once a year.

Where to go from here

For the privacy posture argument, why your email client should not read your email. For the privacy comparison framework, email privacy in 2026.

---

Connect securely. hello@stamp.email