Stuff you wanted to know, and weren’t afraid to ask
Why should we replace email?
It’s become a universal cybercrime portal, because it makes you accessible to everyone else on the Internet without limits, and thereby facilitates phishing. (Most phishing attacks originate at authenticated senders.) The only effective solution is to block SMTP on public networks; to do so, we must replace email.
See also Why TMTP?
How can TMTP grow to replace email, given how entrenched email is?
Initially, it can replace internal email at organizations where a phishing attack could be catastrophic (e.g. manufacturing, public infrastructure, government, finance, R&D, IT). And it can replace external email for services whose members dislike the message scanning done by webmail apps for advertising purposes (e.g. legal affairs, health care, job search, family matters).
As more sites adopt TMTP for their own reasons, they’ll begin using it to communicate with each other for B2B purposes, in lieu of email. As B2B use grows, those organizations that serve consumers can offer them TMTP accounts.
Consumers will then start to ask for TMTP accounts everywhere they still need email, including work. Once enough consumers have switched over, sites can begin requiring TMTP for all external electronic correspondence.
What is the architecture of TMTP?
Succinctly stated: client-server, store-and-forward, members-only. If a member registers multiple clients, the server forwards messages to all of them. The client-server links support both sending and receiving messages.
A user is expected to have memberships at numerous sites, as in the real world. At each server, the user has a separate membership identity, and one or more human-readable aliases associated with it. The server constrains aliases, e.g. minimum number of characters, no duplicates.
TMTP defines no server-to-server aspect. Where a site needs to analyze or archive correspondence by its members with other sites, its server could act as a proxy client (not yet defined in protocol draft).
TMTP relies on a secure stream protocol to carry its traffic. That generally means TCP+TLS, but HTTPS could also work, given a mechanism whereby the server can alert the client (see #7 re mobile clients). For stronger security, a TMTP server could be configured to require client-side TLS certificates.
See also Supplanting SMTP.
Does TMTP enable a universal identity, the way email does?
No, it provides site-specific identities. However, “marketplace” sites which offer membership to large segments of the public may serve as common identity providers; for instance, a consortium of professional organizations, or a service that verifies real-world identity and background.
The issue of universal identity is complex, and should not be defined within a messaging protocol. If a separate universal identity system is widely adopted, TMTP servers could accept a universal identity string as a user registration credential.
Does TMTP provide end-to-end encryption (E2EE)?
Not yet, but it’s likely. E2EE wouldn’t be the default, as there are legitimate reasons why a TMTP site would need to analyze or archive traffic among its members. And as mnm is motivated by the cybercrime crisis, the author is concerned about the benefits of encryption to bad actors.
E2EE is not as important for TMTP as it is for SMTP. When the Internet was emerging, its constituent networks weren’t online continuously, therefore email between networks had to be stored at each relay node until the next one was accessible. That exposes the message content to every node in the path, regardless of any encryption at the transport layer, e.g. SSL/TLS. TMTP (like HTTP) simply assumes a robust Internet.
Why doesn’t TMTP offer federation between servers?
It isn’t necessary, and it would open an easily exploited security hole. Even federation that requires mutual consent by the sites’ administrators allows members of another site to impersonate members of your site.
When you receive an invitation to correspond or a message, you need to know who has control over the sender’s stated identity. If it’s your organization, it’s trustworthy. If it’s a vendor you buy from, it may not be. If it’s a semi-public service that verifies real-life identities, do you trust its verification?
See also #4, re universal identity.
How does TMTP support mobile clients with variable-quality Internet connections?
The protocol draft needs work in this area. JMAP specifies a client-side listener which the server can ping to prompt the client to reconnect for pending messages. That could be a template for a TMTP feature.
Why does the TMTP protocol draft define both message delivery and message body formatting?
The definition of acceptable message formats could be a separate protocol, but for now, there’s one protocol draft.
The server doesn’t enforce the protocol for message formatting (see protocol op “Post” under “.datahead segment”). Special-purpose clients that don’t send messages to normal clients can use whatever message format suits them.
Couldn’t one implement all these features on the existing email protocol stack?
Goodness, no. Have you read the protocol draft?
Doesn’t another protocol already provide these features, e.g. Matrix or JMAP?
Matrix & JMAP are synchronization protocols, wherein both sides maintain a copy of the data objects in question. Matrix is federated (see #6 re federation) and highly complex. JMAP is an extension of the email protocol stack, fitting between user apps and email hosts.
Will TMTP be standardized; if so, when?
Yes, after we gain real-world experience with the protocol, and have a community of folks who want to see it codified.
Is “mnm” really the best name for the project?
Good question! I think it rolls off the tongue nicely. And the general public might get a kick out of the self-referencing quirk, which is new to them. Plus you can invent your own names from the acronym; it’s Massive New Mail!
To pose a question not addressed above, feel free to open or comment on an issue: