Email Is Not Broken. Email Clients Are.

The unpopular take: email is not broken. The protocol still does exactly what it was designed to do. The broken layer is the client experience we keep wrapping around it.

Every few years, someone publishes a piece declaring email dead, broken, or beyond saving. Slack will replace it. Web3 will replace it. AI will replace it. None of that has happened. Email remains the most universally supported communication standard in the world, with no realistic replacement on the horizon.

The reason it feels broken is not the protocol. SMTP, IMAP, and MIME are not elegant systems, but they work. Billions of messages are delivered reliably every day. The reason email feels frustrating is the software we use to interact with it.

Symptoms people blame on email

• Search feels unreliable.
• Multi-account usage feels fragmented.
• Offline moments kill momentum.
• Privacy expectations conflict with server-heavy feature sets.

None of these are email problems. They are client problems.

The search problem is a client problem

IMAP SEARCH is limited. It was designed in the 1990s for a world of small mailboxes and slow connections. It supports basic keyword matching, not full-text relevance ranking across thousands of archived messages. If your email client relies primarily on server-side IMAP SEARCH for its search results, you will get unreliable results. That is the client's fault, not the protocol's.

A client that maintains a local full-text index — separate from IMAP SEARCH, built from locally synced message content — delivers fast, reliable, ranked search results regardless of server behavior. This is not technically difficult. It requires the client to download and index messages locally, which most server-dependent clients choose not to do to reduce storage requirements.

The tradeoff is disk space and sync complexity. Clients that skip local indexing are making that tradeoff on your behalf, without telling you. The result is unpredictable search.

The multi-account problem is a design problem

Most email clients were designed around a single account. Multi-account support was added as an afterthought. The result is a triage experience built on account switching rather than unified inbox management.

When you have a work account, a personal account, and a side-project account, you shouldn't need to navigate to each account separately to see if anything requires attention. A well-designed client unifies the triage view across accounts while preserving account context for replies and send identities. That is not a hard problem to solve. It is a product design priority.

The offline problem is an architecture problem

Server-first email clients treat local storage as a cache, not a source of truth. The moment connectivity drops, the experience degrades. You can't search archived mail, you can't access messages outside the recent cache window, and you aren't sure whether your outbox will deliver correctly.

Local-first email clients treat the device as the source of truth and the server as the sync target. Connectivity is an optimization, not a requirement. The offline experience is as complete as the online experience, because they are the same experience.

Building this correctly is genuinely hard. We spent months evaluating sync architectures before landing on a solution that handles millions of rows reliably across platforms. That work is described in Offline-First Landscape. The difficulty of doing it right is why most clients skip it. But difficulty is not an excuse.

The privacy problem is a business model problem

Gmail is free because Google uses your email content to target advertising. That is not a bug in the protocol. It is a business decision made by one company. IMAP email on any other provider, accessed via any client that does not process your content server-side, does not have this problem.

The privacy issues users experience with email are almost always attributable to specific business models — ad-supported providers, collaboration tools that require server-side processing, tracking pixels sent by senders — not to email as a technology.

Root cause: product tradeoffs, not protocol failure

Most "email is broken" arguments are really critiques of business model and UX choices: ad-driven interfaces, over-automation, and weak local indexing. If you want a technical example, read Why Apple Mail Search Feels Bad. If you want infrastructure-level context, read What Most Clients Get Wrong About IMAP.

What we changed in Marco

1. IMAP-first architecture for provider portability.
2. Local indexing for predictable search speed.
3. Offline-first flow so no-network periods are usable.
4. Feature restraint: fewer gimmicks, clearer execution.

Each of these is a response to a specific client failure pattern, not a protocol limitation. Email doesn't need to be replaced. It needs better software.

Practical reset for your own inbox this week

1. Stop adding tools before fixing triage basics (use this 5-step method).
2. Consolidate fragmented accounts (use multi-account process).
3. Run one offline stress test before your next trip (see offline access guide).

For the deeper engineering journey that led to this view, start with Offline-First Landscape.