SMTP should be blocked on public networks.
Sound crazy? Consider this: Email is now a universal cybercrime portal1.
Consumers, organizations, governments, and specific individuals are being targeted relentlessly by phishing attacks that result in stolen money and confidential data, or planted malware. Email technology offers no effective means to stop phishing2, so it’s been a runaway success for the attackers, and a disaster for millions of victims. Accepting this state of affairs—now that’s crazy.
Furthermore, a majority of email users are plugged into other messaging services, discussion sites, and groupware apps. At least 90 million3 have replaced email where possible with Slack and MS Teams. We no longer need an Internet-wide messaging system that makes everyone on it accessible by everyone else without consent or limits.
Sunsetting SMTP is clearly necessary and feasible.
But email is a foundational Internet application4; the concept is too important to let SaaS vendors or social networks define its future. Therefore the open source community must act to replace it, and act now.
So I’ve drafted a protocol, TMTP, and published implementations of both client and server as open source. TMTP is simple, preserving the soul of email, while dramatically reducing its vulnerabilities. It also addresses major user experience gaps in email, which were solved long ago by web-based discussion apps.
I arrived here by trying to build something completely different.
In 2002, after I left the Internet startup I founded in Silicon Valley, I began exploring a design for a personal-area computing environment5 based on the Web user experience (hyperlinked, multi-format, interactive documents). Its apps and data are local to your devices, but sharable with collaborators and subscribers.
I sourced one element from software version control; related edits to a collection of local-web documents are packaged as a revision. When saved, a revision is distributed via a store-and-forward Internet service to all others sharing the collection. I borrowed another aspect from the datacenter; all your local-web projects (shared and not) are replicated on a few devices, so you can failover to a different device without loss of work.
In 2010-12, I prototyped this in Node.js. It worked well enough, but it was a platform, not an application, and I couldn’t see a killer app which would make it fly. So I set it aside, and created a pocket-server hardware product, another dimension to personal-area computing. (That was an enlightening misadventure, which I’ll cheerfully recount over drinks.)
In the Spring of 2017, I had a revelation—I don’t recall what triggered it:
Holy cow, the killer app… It’s email!
I’d unconciously realized that email could not survive the cybercrime crisis; a new protocol would be required, and I’d already prototyped it. I also recognized that a typical tech startup probably couldn’t convince the world to adopt a new email protocol. The central concern of a for-profit outfit is enriching its owners by satisfying customers. My sole motivation has to be making the Internet safer, while keeping it open.
Three months later, I had a working server in Go, a protocol outline, a short essay titled “Why TMTP?” and a modest to-do list. I named it “mnm” (mnm is not mail, a self-referencing acronym).
I considered announcing the project then, but decided that it would be more credible and appealing given a client application with features missing in today’s email. So I composed a client to-do list, which quickly ballooned past modesty, and started learning Vue.js.
In Spring 2019, I released the first preview to a small audience, and as of this writing, there have been nine preview releases.
At this stage, TMTP & mnm need your support to reach 1.0. That means:
- Donate: support me on Patreon (I’m getting hungry!)
- Contribute: add features, perform code reviews, and invent new test cases.
- Experiment: try the client & server in different environments, and report back.
- Evangelize: put the word out on blogs, social media, and discussion forums!
Many warned the IETF that spam, the forefather of phishing, was a serious problem, and should be addressed at the protocol level, even at significant cost. Sadly, some IETF participants derided such critics as "anti-spam kooks", and their suggestions as "FUSSPs" (final, ultimate solutions to the spam problem). See the rhyolite.com kooks list. ↩
Derived from daily-active-users figures for Slack and MS Teams as of December 2020. ↩