A Systemic Critique of the Email

Email itself is a product of the 1980s, a quintessential "living fossil" of the internet. It was originally designed as a text transmission tool for small-scale environments built on mutual trust, rather than the mass-market infrastructure it is today, which is expected to carry sensitive information.

In the contemporary internet, the primary function of email has undergone substantial degradation: it has devolved from a tool for bidirectional information exchange into a mechanism for account recovery, an identity anchor, a pipeline for unidirectional notifications, and a repository for formal documentation.

1. Archaic and Unevolvable Architecture

The core designs of SMTP, POP3, and IMAP originate entirely from a pre-security era.

The layered patching of MIME, Headers, and Bodies results in highly ambiguous protocol semantics.

Backward compatibility is treated as dogma; any substantive improvement would disrupt the ecosystem.

2. Decentralization Does Not Exist in Reality

Theoretically, email is federated and decentralized; in reality, the exact opposite is true:

Mainstream service providers (Google, Microsoft, etc.) default to distrusting self-hosted mail servers, making SPF, DKIM, and DMARC effective barriers to entry.

Even universities and research institutions are easily misclassified as sources of spam; Outlook's hostility toward university email is a typical example.

Email is a system that is decentralized in protocol but highly centralized in operation.

3. Privacy Protection is a Failure by Design

SMTP is fundamentally a plaintext protocol; encryption is merely a retroactive add-on.

Uncontrollable Transmission Links: Even if the client-to-server connection uses TLS/STARTTLS, server-to-server communication may remain completely unencrypted. Any hop in the middle is subject to passive or active eavesdropping.

Full Exposure of Metadata: Senders, recipients, timestamps, and subject lines are all exposed and impossible to protect.

4. Severe Issues with Encryption

(1) Structural Flaws in Messaging

Loose definitions of MIME boundaries lead to structural vulnerabilities such as "GpgFail." These issues are nearly impossible to fix completely, as fixing them implies breaking compatibility.

See this:

GPG Fail

(2) Issues with S/MIME (PKI)

It is highly centralized, and commercial certificates are expensive.

In Germany: Universities issue certificates for free, but the process is cumbersome (requiring in-person application) and non-standard (e.g., unable to use CSRs, instead issuing private keys directly). This effectively means the institution possesses the technical capability to access private keys, rendering the security model entirely subservient to administrative and organizational trust.

(3) Issues with GPG (Web of Trust)

Theoretically decentralized, but in practice, it is a triple failure in terms of usability, security, and comprehensibility. Both protocol design and usage configuration are complex and error-prone.

See this:

The PGP Problem

(4) Difficulty in Achieving Forward Secrecy

The design of email is inherently ill-suited for forward secrecy because the cost of dynamic key negotiation between sender and receiver is high. Neither S/MIME nor GPG supports forward secrecy. If a recipient's private key is compromised, an attacker can decrypt all historical emails.

See this:

Harvest now, decrypt later

5. Mistakenly Treated as an Identity Anchor

See the next article.



You've reached the end of this page. And you may Go to index or visit my friends.
About me and contacts
Except where otherwise noted, this site is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License