Thinking out loud about 2nd-gen email
Efforts to design a “second‑generation” email system — with stronger authentication, cleaner HTML support, and simpler self‑hosting via a new MX2 DNS record — are met with both enthusiasm and skepticism. Commenters note that email is already slowly evolving through SPF, DKIM, DMARC and de facto rules set by giants like Google and Microsoft, and argue that any real change depends on those incumbents’ incentives and willingness to cooperate. Many see spam, deliverability cartels, and the capture of email by a few large providers as the core problems, suggesting that incremental, backward‑compatible standards and better tooling for small hosts are more realistic than a full protocol reboot.
Feasibility of “Email 2.0” / MX2
- Many see email as already undergoing a slow, de facto “v2” via DMARC/DKIM/SPF and big-provider policies, not via a clean new spec.
- Several argue MX2-like changes could succeed only if Google/Microsoft/Apple/Yahoo push them and bias spam filters toward it; without that, it’s DOA.
- Others think large providers have weak incentives to simplify or reset email, since complexity and lock‑in benefit them.
- Skeptics compare MX2 to IPv6: technically better, but hard to deploy because the legacy system works “well enough.”
Spam, authentication, and power dynamics
- Consensus: spam is the major technical pain; everything else is secondary.
- Many doubt domain-based trust alone solves spam: domains are cheap, and reputation cartels just move from IP lists to domain lists.
- Some say deliverability is effectively a cartel; incumbents use complexity to retain control and sell “access to eyeballs.”
- Ideas floated: stricter SMTP-level rejections, richer status codes, sender‑authorization tokens, or “pickup only” or IM2000-style models; others respond with standard anti‑spam checklists showing likely failure modes.
HTML, formatting, and client behavior
- Strong disagreement about HTML:
- Marketers and UX‑oriented commenters want standardized, richer HTML (or XML/JSON‑based formats), referencing existing but messy practice.
- Others want HTML removed entirely or replaced with a constrained subset or lightweight markup; some propose text/markdown or similar.
- Several note decades of failed attempts to standardize HTML for email, citing conflicting interests (marketing, security, Outlook’s Word-based renderer).
- There’s skepticism that plain‑text or Markdown-only email would ever be adopted by marketers, which would hurt adoption of any new standard.
Encryption, identity, and tokens
- Some want any reboot to bake in modern E2EE (Signal-like, OMEMO-like, or better OpenPGP/S/MIME usability).
- Others argue new crypto alone doesn’t fix core problems (key distribution, usability, long-term storage vs. forward secrecy).
- Token- or capability-based models (only authorized senders can email you; revocable per-sender aliases) are discussed, but seen as complex and vulnerable to new abuse patterns.
Self‑hosting, centralization, and regulation
- Many lament that self-hosting is practically blocked by IP/domain reputation and opaque big‑provider filtering.
- Some fear MX2 would further centralize power in a few providers; others say email is already captured.
- Proposals include government‑blessed “secure email v2,” portability mandates for email addresses, or even government-run mail infrastructure.
- A minority suggests abandoning email entirely in favor of newer messaging systems; others defend email’s openness, federated nature, and Lindy‑like resilience.