[nullindividual]

The mail server has to read the body of the mail message, which throws out any E2E use. SMTP is from the 1980s. There are countless SMTP servers on the Internet. You want spam filtering? Server-side rules? Can't have E2E.

That, and more, is why E2E isn't available for SMTP-based email. Many modern SMTP servers support opportunistic-TLS, potentially securing email traffic between two SMTP servers. Or forced TLS when you know the target supports TLS connections.

This isn't some "money making" or "spyware" conspiracy. It is a product of history, decentralization, and momentum.

Comparing that to modern chat apps which can be built from the ground up and their messaging protocol doesn't rely on a 40 year old standard is disingenuous at worst, ignorant at best.

[kbns]

While I understand the challenges with SMTP-based email, dismissing privacy concerns as ignorance is unhelpful. It's not at all a technical difficulty—Modern threats demand updated solutions, and opportunistic-TLS isn't enough. Financial incentives and data monetization do play a role in the reluctance of major providers. If new protocols can secure chat apps, similar efforts should be made for email.

Users deserve better privacy protections despite historical constraints.

[nullindividual]

> It's not at all a technical difficult

Tell us how you'd implement it and be backwards compatible with existing SMTP servers.

> Financial incentives and data monetization do play a role in the reluctance of major providers.

Do you have evidence that they're preventing E2E SMTP from becoming an RFC?

[mike_hearn]

You technically can have spam filtering with e2e encryption by using confidential computing. It's just really hard and there isn't much market demand.