I think my main problem with this is the intermixing of higher "application" level features like surveys and forms with lower level protocol features like "message transport."
This seems like a bad idea and goes against years and years of open systems design.
networkimprov 1195 days ago [-]
There has to be a definition of acceptable message formats for standard clients. I suppose that could be a separate protocol, but for now, there's one protocol draft.
Not sure why that is a problem given the problem domain -- all those high-level features is what will help people consider adopting this. But email can only improve if you fix the whole eco-system including the server side -- which then means also dealing with the protocol. The modification to the protocol will probably help with all those "high-level" features.
ianai 1195 days ago [-]
You have to have a killer feature for something to get adopted.
GekkePrutser 1195 days ago [-]
The killer feature of a new email protocol will be that it's not SMTP.
It should have sender authentication. E2E encryption that's easy and works by default. Those would be more than enough killer features, SMTP is just too broken and all the workarounds we have in place like DKIM, SPF, Spam ratings etc etc don't make up for it. We still have spam, important mails still end up in our junk boxes, and nobody trusts it enough anymore to put important content in emails. The war has long been lost.
ddingus 1195 days ago [-]
"Nobody"
"War"
Few, outside small, likely familiar tech circles, use these terms when discussing email.
Not being SMTP usually means being another messaging island or other, which has only strengthened email.
Lists have huge value today, still!
Now, there is one exception: Marketing
The reason? Everyone else is busy getting work done.
Whatever may transcend email needs that quality, or it will, in fact be, yet another messaging island.
vinay_ys 1195 days ago [-]
Exactly. There's no replacing email with something that's closed membership / invite-only etc. The whole point of e-mail is its your address where someone can initiate a contact, like phone number. You can choose to filter it etc. And you can choose to get attested emails which you can trust more etc. But fundamental nature is it is open for anyone to contact you. If you lose that, and build a custom new protocol, you are just building another closed wall messaging application.
jbaber 1195 days ago [-]
Gmail has done this. I often follow up e-mails from my personal domain with a copy from a gmail account since it gets guessed as spam randomly.
AndrewSChapman 1195 days ago [-]
Agree with everything you've said. Additionally, consistent rendering. If you've ever tried to send an email campaign and had to support all the old (and sometimes surprisingly new) Outlook clients and Lotus notes, you'll know just how painful that is.
Email must be:
* Secure and encrypted;
* Have proven identity;
* Have easy to fabricate and predictable rendering;
I feel like the ability to have forms and charts is very nice, but adds a lot of complexity, especially from a security point of view. I'd be looking at this kind of "application level" functionally being a layer added optionally on top, not being in the core protocol.
Geezus_42 1195 days ago [-]
I have a job because people put important stuff in email... lol
EricMausler 1195 days ago [-]
What are your thoughts on protonmail?
mosselman 1195 days ago [-]
As far as I know, and I could be wrong, ProtonMail wraps around pgp inbox encryption. Many providers have exactly this service already.
The difference seems to be that ProtonMail don’t allow you to use normal imap and your own client with pgp, but force you to use their client. This is probably a trade-off made to protect users against them selves in one way (disabling encryption for grandpa) and hiding the non tech-savvy from all the technical details.
Again, many assumptions here.
So, to me, mentioning proton here doesn’t make sense as the underlying tech: smtp & pgp have existed and been industry standard for a long time. So there is not issue of adoption.
GekkePrutser 1195 days ago [-]
I'm with thayne above on this one.. Protonmail just offers secure storage on their system but they still see the external incoming emails unless they're PGP encrypted. They make that easy, but still. PGP didn't take off in 30 years, it's just too complex. Tools can help that but the weak point is its key management.
thayne 1195 days ago [-]
Not the parent, but protonmail is still just more hacking to work around a broken system. It is a valient effort, but to really fix email the whole thing needs to be replaced.
xtf 1195 days ago [-]
And that is what xmpp already offers
3131s 1195 days ago [-]
It seems to be a favorite of criminals everywhere, which is a good measure of worth in this case.
There was a major deep web counterfeiter about a decade ago that remained active on Jabber even as a federal fugitive, not sure what ended up happening to him.
unethical_ban 1195 days ago [-]
Open systems design has lost the messaging wars.
Federated/decentralized, secure, non-real-time messaging is the problem space. If it can make some overwhelmingly common use cases of current e-mail that much easier, then so be it.
teleforce 1195 days ago [-]
Don't count your chickens just yet, the jury is still out on this one.
If history has any say on this, communication solution based on proprietary technology will meet their death sooner rather than later. How many network protocols have been invented before and after TCP/IP? I know we are talking about messaging now, but messaging is just another overlay network over TCP/IP.
I'd envision in the future that the open messaging systems will be more pervasive. It will be based on local-first software and probably based on the automerge capabilities. The automerge community is focusing on collaborative editing at the moment but could someone please work on automerge solution for messaging system? This can be an excellent new paradigm for open world of messaging. I am seriously tired of people asking me to install the proprietary software of WhatsApp, Line, Wechat, etc.
vinay_ys 1195 days ago [-]
Yes, it is unfortunate they chose to do that. I stopped reading when I saw that section.
networkimprov 1195 days ago [-]
It makes me smile to hear that someone expects to read a perfect document on a perfect product which they understand perfectly; even tho the product is a preview, the document is a draft, and they only read it once.
vinay_ys 1195 days ago [-]
There was nothing imperfect in what I read. It was perfectly clear what features this product considers in its scope. I just didn't agree that those feature went well together with the stated goal of replacing current email systems.
AndrewSChapman 1195 days ago [-]
Completely agree.
pmlnr 1195 days ago [-]
Don't try to "replace" email, ever. Build, name it is a X, just not as "to replace email", because by doing that, it's DoA.
ajsnigrutin 1195 days ago [-]
Yup!
There are many, many protocols for exchanging messages, chats, files, etc. (basically, what e-mail does), they all come, get some traction, last for two years, then die (except maybe irc, but except for a few nerds, it's hard to get anyone on there anymore). Some get killed by google, some just get replaced by "the next new thing"... but e-mail still lives, and works, and does what is needed.
GekkePrutser 1195 days ago [-]
It doesn't do what's needed. It provides a channel for spam, insecure delivery etc. It's too broken. We do really need a new email.
franga2000 1195 days ago [-]
The fact that it has problems is entirely tangential to the fact that it does what's needed. What's needed is "I send a thing to a person and it soon-ish shows up on their end", with the bonus of knowing that someone would have to expend significant effort to intercept it. This has been true since the invention of writing and very few scenarios needed more. Anything on top of that (spam rejection, steong verification and encryption, etc.) is nice to have, but clearly not critical, because otherwise we still wouldn't all be relying on paper mail, email and sms for even the most critical of things.
So yes, we really do need something better than email (and we have plenty of options), but it doesn't have to (nor will it any time soon) replace email.
ruslan 1195 days ago [-]
We do not need new email. We need a way to authorize messages sent and also a way to enburden senders for the content they send. In pre-internet era UUCP was widely used to deliver messages, UUCP providers used to charged their customers for each message they sent which made spam broadcasting quite costly. What I see is a kind of distributed message transportation system that takes currency from sender and shares a fraction of it with recipient. I.e. sender always pays for sending their stuff, recipient gets paid for interruption. SMS messaging is very close to this.
oss2020 1195 days ago [-]
Real transport level security will be possible with MTA-STS (rfc8461). Use DNSSEC, enforce TLS, and verify server certificates. Also I haven't had much trouble with spam recently (spam filter works fine).
tptacek 1194 days ago [-]
The point of MTA-STS is not having to use DNSSEC, which nobody does anyways.
ddingus 1195 days ago [-]
None of what you wrote speaks to not doing what is needed.
zapzupnz 1195 days ago [-]
Yes, but the point is, don’t sell it that way.
almaember 1195 days ago [-]
> except maybe irc, but except for a few nerds, it's hard to get anyone on there anymore
Well IRC isn't really meant to be used for persistent communication anyway
ddingus 1195 days ago [-]
This!
People do not want email replaced. They may want a new thing enough to use it in huge numbers.
And then that thing has to endure long enough, be open enough to see even a modest level of trust email has at this point.
It looks great, but there's zero chance I'm going to replace my current SMTP with a new protocol no one (yet) uses. If there's a bug in all of this it's in laying out very clearly how to ease into this. Especially in a world of hosted email providers where everyone is using Exchange, Google Email, and even cPanel to host email for organizations, and none of them have a big incentive to support this.
EDIT: On thinking about it, I'd think this would have more chances if they phrased it as an augmentation of email's capabilities rather than an email killer.
user3939382 1195 days ago [-]
The way to accomplish the change is to propose upgraded versions of SMTP, IMAP, et al that are backwards compatible with existing protocol versions. This way the infrastructure can update incrementally. If both clients in an email exchange and all the servers they're using in between support the new versions you get the features. iMessage manages this pretty well.
mortenjorck 1195 days ago [-]
There are two key requirements for anything that would actually supplant email:
1. Call the protocol "Email 2"
2. Build something that actually justifies the name
I'm only half joking; the messaging around the protocol is almost as important as the protocol itself. iMessage is a good example of how to expose something like "Email 2" to the end user: as a seamless upgrade, indicated by a subtle UI element, when a client happens to negotiate the upgraded protocol with the server.
Enabling incremental upgrades to infrastructure is critical, but strict backward-compatibility isn't necessarily so. As long as the architecture of the new protocol makes falling back to IMAP/SMTP straightforward when an upgraded client or server isn't available, Email 2 doesn't have to be able to talk directly to legacy.
There's certainly a chicken-and-egg problem in driving enough server adoption to get client vendors to add support while driving enough client adoption to get server operators on board, but there's probably a sweet spot between making a clean enough break with legacy tech that it's more straightforward to implement, while making it conceptually similar enough that it can still plug into the same patterns.
livre 1195 days ago [-]
Another alternative is to support cross communication between email and this new protocol until it has enough users that supporting email stops being a priority. Then start offering new installations with email compatibility off by default until the majority of the users are on the new protocol, then keep email support only on lts releases and finally remove email completely. This way you avoid having to carry the baggage of email forever and having to support an old protocol full of backwards compatibility hacks. This is all in theory, in practice I doubt this will ever get close to replacing email.
chrisandchris 1195 days ago [-]
That works pretty well for IPv6, doesn‘t it (actually, it does not)?
The problem with that approach is that as long as 0.01% still uses the old protocol, you can‘t get rid of it. And then you have a bag with the old and new protocol and maybe after 20 years you realize it‘s going to take another X years until you have at least some relevant adoption, as demonstrated with IPv6.
If one is ever going to „replace“ email it happens on top of the existing protocols and not as a replacement.
livre 1195 days ago [-]
You make a great point. A very popular protocol or standard is never fully replaced. Either it continues existing next to the new thing (IPv4/IPv6) or gets an update while still having to deal with backwards compat (HTML, CSS). Whatever the case is we'll still be dealing with email in 20-30 years from now.
throwawaysea 1195 days ago [-]
This is already the case for encrypted transport of email and is how email has been evolving all this time.
ianai 1195 days ago [-]
Na. We’re talking about adding a protocol to a list of a handful which people use regularly. What you just said sounds like something I would have heard in the 90s about using email for legitimate purposes. Why do we need email when we have fax? (Granted fax still exists, but it’s no email killer.)
This sort of thing could be deployed by people in addition to the other services. For a while and perhaps a long while it’ll be fringe. But if there’s enough utility to it then it may just catch on.
EricMausler 1195 days ago [-]
If support for both is going to be part of the plan, I do not suggest planning to drop support for email. Commit to supporting both or dont
I'm not sure why everyone always tries to replace email with better messaging as if messaging was email's killer feature.
The reason I first got an email address was to get a Runescape account. Email's killer feature on the modern internet is identity management. On most sites it's impossible to create an identity without one.
networkimprov 1195 days ago [-]
There's no inherent reason to have an identity separate from the one the site you're joining grants you.
I'd guess that site is leveraging the effort which webmail providers spend to weed out bots and sock-puppets. And perhaps they use the address for adtech purposes. But I don't know for sure.
I'd love to hear from such sites about how they use customer email. If it's not primarily for communication, it may not make sense to accommodate it in TMTP.
iovrthoughtthis 1195 days ago [-]
> There's no inherent reason to have an identity separate from the one the site you're joining grants you.
What do you mean?
> I'd guess that site is leveraging the effort which webmail providers spend to weed out bots and sock-puppets. And perhaps they use the address for adtech purposes. But I don't know for sure.
It’s a lot like having a physical address which is used as a core part of meatspace identity management.
> I'd love to hear from such sites about how they use customer email. If it's not primarily for communication, it may not make sense to accommodate it in TMTP.
A shared unique identifier (value for user is that it is consistent across services).
A means of authentication when primary auth (password) cant be used (company sends links etc).
1-1 channel of communication (notifications of activity or changes in a service).
Obviously, it’s just my opinion, but making a new messaging protocol won’t fix email. My hunch is that is because email’s primary purpose (to the end user) is not to provide a messaging channel but to provide an identity.
Ir0nMan 1194 days ago [-]
How would you suggest handling password resets?
doctorfoo 1195 days ago [-]
For password reset?
juniperplant 1195 days ago [-]
Kind of disappointed in not seeing end-to-end encryption being mentioned?
I thought it was perceived as one of the fundamental flaws of email.
No it's not. I found two dismissive lines somewhere towards the end of you link. That's not addressing it at length somewhere worth clicking towards.
Saving others a click:
> Re end-to-end encryption, that can be considered for the inner layer protocol. I don't rule it out, but it's not a priority at present.
eeZah7Ux 1195 days ago [-]
...not to mention the leaking of metadata.
kyrra 1195 days ago [-]
The (I believe) author of this posted it on the golang subreddit a few days ago. It looks like he's very open to contributions if you're willing to help.
I welcome constructive feedback and contributions!
I have a "Yes, and ..." attitude to input and community. (I know the pain of being part of an open source community that doesn't.)
(Yes-and is a comedy/theatrical improv technique; always embrace what the previous speaker said, and build on that. Tho admittedly, you can't run an open source project in an entirely improvisational manner :)
FiveNinjas 1195 days ago [-]
took me way too long to find out that the T in TMTP stood for Trusted.
I was looking for protocol descriptions in how this could work. Author said people would be more impressed by code - but I think a protocol spec along with a reference implementation would be useful.
So... what in this proposal isn't fulfilled by a private walled message platform such as Whatsapp, or Signal, or Facebook Messenger?
Nothing here needs this to be 'email'.
And if you're into adding trusted layers with revocation to email, well we have DKIM, client certs, encryption. You can do the 'trusted' enforceability at the application level over the untrusted SMTP network level.
All in, probably DOA as an idea.
nobody9999 1195 days ago [-]
>I was looking for protocol descriptions in how this could work. Author said people would be more impressed by code - but I think a protocol spec along with a reference implementation would be useful.
I went and looked for a protocol spec as well. When I didn't see anything concrete on the site in the submission title, I poked around the comments a bit more and found a link to the Github issue[0] requesting detail with respect to the architecture of the TMTP protocol.
I further poked around in the appropriate places[1] but found nothing remotely related.
The protocol spec[2], while useful in defining the control mechanisms and message formats is vague or silent when it comes to a variety (too many to list completely here) of functional, operational and implementation issues.
A comparison of TMTP's spec with SMTP[3] ("the protocol at the root of all these problems"[2] with messaging), is quite illuminating.
While SMTP by itself lacks a variety of features, it provides a robust, interoperable architecture that's broadly supported and has been augmented repeatedly by other protocols (e.g., MIME, DMARC/DKIM, SMTP-AUTH, LDAP, etc.) to provide such features.
It's not clear to me that mnm/TMTP has been fleshed out enough to provide a real alternative to SMTP+extensions. Rather, it appears to be another (there are many) client/server messaging application that's not interoperable.
Should these issues be addressed, discussed and refined in the appropriate forums[4], It's possible that TMTP could turn out to be a viable replacement for SMTP.
I applaud the authors' work and hope they have much success with their entry in the messaging app market.
And yes, TMTP will see a lot more revision, and real-world use, before it's proposed to any standards body.
(I'm the author.)
nobody9999 1195 days ago [-]
Thanks for the response.
Yes. That was the document I was talking about, but I linked the wrong page.
My apologies for any confusion.
networkimprov 1195 days ago [-]
If widely adopted, most TMTP clients would have concurrent logins to many servers at different sites. Your traffic isn't routed via a middleman like Facebook which everyone needs to join, and which scans your content for advertising purposes.
I've implemented both client and server, so there's the basis for a "reference implementation".
Just been thinking that it's bad to use 'trusted' in an acronym. Not only is it subjective but it will also not stand well over time. Just like how NG is avoided.
StreamBright 1195 days ago [-]
Point 1 is great, point 2 is disastrous. Yes, we need a new email protocol, it has to be simple, cryptographically sound, it must weed out the concept of spam (there are great ideas on this subject, like the cost-based anti-spam systems[1]. We do not need more attack vectors like a JS based chart library. You can render charts as static images without running any code on the reader side. Some days, I wish there was a LaTex based email that did these.
Great because SMTP is completely broken. The lack of E2E encryption and sender authentication makes it completely useless these days. We're bogged down in workaround upon workaround to combat spamming/phishing and other abuse. Companies no longer rely on its security but instead just send an email to check their portals. We need something new.
However the whole slideshows/surveys should be handled in the applications. We need a good protocol first.
upofadown 1195 days ago [-]
>The lack of E2E encryption and sender authentication makes it completely useless these days.
The elephant in the room here is that there is nothing wrong with, say, PGP. Any meaningful approach using public key crytography and crytopgraphic signatures to achieve confidentiality and authentication over SMTP ends up with the conclusion that you could of just used the OpenPGP protocol.
I think the reason we like to think that there is some new method available that will finally make things work is the hope there is a purely technological solution available. After 30 years of failing to come up with such a solution it is clear that there is no such solution possible in isolation.
md_ 1195 days ago [-]
PGP is incompatible with both forward secrecy and metadata secrecy.
If you only want to keep your message body confidential (or authenticated), PGP is reasonable. But it provides a strictly lesser degree of secrecy than modern e2ee messaging applications.
In fact, depending on your threat model, modern SMTP-TLS (which is not e2ee, but does provide some metadata confidentiality and forward secrecy) may in fact be an improvement over PGP.
upofadown 1195 days ago [-]
Forward secrecy isn't really an issue with email. There are few that would be willing to delete their emails after reading them. Keeping old messages around for all practical purposes negates the value of forward secrecy. Most people like to keep their old messages in an easily accessible form so forward secrecy is not very important for messaging in general.
>...metadata secrecy...
This is not a huge problem with a medium like email where you can be more or less anonymous. Contrast with things like instant messengers that insist on a phone number.
>But it provides a strictly lesser degree of secrecy than modern e2ee messaging applications.
Most of those applications take the form of instant messengers. Since such things by necessity have to leave the private key material exposed all the time they are generally less secure than something like encrypted email where that key material can be kept very locked down.
>...modern SMTP-TLS (which is not e2ee, but does provide some metadata confidentiality and forward secrecy) may in fact be an improvement over PGP.
True enough. SMTP-TLS does provide even more security to the encrypted email user. Most importantly, it prevents passive listeners from detecting that an email was encrypted and thus worthy of further interest.
I can't help but point out that this sort of discussion is an excellent example of the state of denial that exists with respect to end to end encrypted messaging these days. Rather than addressing the broader overall issues we are quibbling about obscure technical details.
GekkePrutser 1194 days ago [-]
E2E with forward secrecy was not possible in the past because email was an offline thing. You can't do PFS without a live connection between the endpoints.
However, these days this should be less of an issue in an ever connected world. Nobody uses UUCP or batched SMTP anymore :)
md_ 1195 days ago [-]
Which details? :)
E2ee messaging is used by billions. Without talking details, it’s hard to know what about the status quo we wish to improve.
iggldiggl 1195 days ago [-]
Another thing is that e2ee breaks a number of useful features of e-mail:
- The ability to painlessly access your mail from a number of different clients, ranging from fully-featured desktop clients to smartphone apps to webmail.
- Server-side filtering (both spam and in general)
- Server-side searching (mandatory for webmail and depending on how big your mail archive is, still rather useful for smartphones, too)
upofadown 1194 days ago [-]
>Server-side searching
Pretty sure that is what the unencrypted "Subject:" is for... :)
There is now a way to encrypt the subject but it is turning out to be a controversial thing to do. Perhaps that is at least partially the reason.
iggldiggl 1194 days ago [-]
> Pretty sure that is what the unencrypted "Subject:" is for... :)
Weeell, yes, possibly :) – but more seriously, the subject line only gets you so far, so I do need fulltext search as well.
eeZah7Ux 1195 days ago [-]
metadata are leaked by mnm, activitypub, xmpp, matrix & so on
throwawaysea 1195 days ago [-]
> The lack of E2E encryption and sender authentication makes it completely useless these days.
Both SPF and DMARC provide sender authentication.
GekkePrutser 1195 days ago [-]
Well one issue with them is that they're totally optional. The protocol should have this built in. The way it is now is a kludge. Even mails from big companies still end up in my O365 junk box. I didn't check them in detail but something failed there. At the same time the spammers are actually pretty good at avoiding spam filters.
Also, they don't really provide sender authentication. They provide sending domain->sending server verification. If you have a business that uses the same email provider, you will be able to fake sender auth if you can convince the server to send it. This is why it's a kludge.
If we'd require emails to be signed by default this issue wouldn't be present.
What I really miss these days is public protocol innovation. In the old days if a protocol stopped meeting the needs, people would go back to the drawing board and publish and agree a new RFC. These days we just tack on workarounds to old protocols without fixing the root issues, or we switch to closed alternatives (like what has happened to IM) which is even worse.
dane-pgp 1195 days ago [-]
> Well one issue with them is that they're totally optional.
So is every proposed replacement for SMTP.
GekkePrutser 1195 days ago [-]
True, but at least it would have those things incorporated in it. So you don't have different versions with and without.
I would imagine it would gather uptake pretty quickly. Just like other protocols which have advanced. Like SSH v2, nobody uses v1 anymore.
nobody9999 1195 days ago [-]
> > The lack of E2E encryption and sender authentication makes it completely useless these days.
>Both SPF and DMARC provide sender authentication.
And TLS encryption via required encryption via STARTTLS[0][1] plus s/mime or gpg can provide E2EE.
Not sure if mnm/tmtp supports endpoint data encryption though.
The problem is that s/mime and gpg are too complex for end users. Especially the key management, the encryption itself is not the issue.
s/mime is expensive in terms of certificates and difficult to set up. GPG's trust chain based on key signing parties has never taken off outside the crypto geek community (Don't get me wrong, I'm one too!)
Perhaps a "let's encrypt" approach to s/mime could work though. I could see that happening. It would indeed solve a lot of issues.
nobody9999 1195 days ago [-]
You make very good points.
Corporate environments generally have an easier time with s/mime, and IIUC this app is focused on corporate environments.
GPG is nice (I like a lot and have used it for a very long time), but it's certainly niche.
That said, I included s/mime and gpg to illustrate that end to end encryption is not only possible, but that mature, functional tools are available in an SMTP+extensions environment.
It would be interesting to know how mnm/TMTP does encryption. I'd assume it uses TLS for transport. As for endpoint and server storage encryption (assuming it does that at all), you'd hope they'd use some sort of asymmetric key encryption, which raises the same issues as s/mime and gpg.
zimpenfish 1195 days ago [-]
I thought SPF was more "this email is allowed to come from these hosts" authentication which tells you nothing about the sender (to me, at least) other than "they used an approved host"?
0df8dkdf 1195 days ago [-]
* SMTP, the protocol at the root of these problems, originated at a time when the links between Internet sites were slow and intermittent*
I think the author missed the whole point. Not everyone has access to fast internet or internet at all. SMTP was designed with that in mind, and it also works better than other real time messenger in that sense. Async federated communication.
networkimprov 1195 days ago [-]
I'm referring to a time when the Internet backbone was slow and intermittent. You're describing the last-mile situation.
JMAP offers a solution for intermittently connected devices (phones) which expect notifications and messages from Internet services.
I expect TMTP will do the same; it's far from final. (I'm the author.)
0xbadcafebee 1195 days ago [-]
They lost me at "weird JSON header followed possibly by arbitrary 8 bit data". The rest of the protocol is kind of crazy too.
silasdb 1194 days ago [-]
There are many pessimistic comments here. I'd like to go to the opposite direction.
First, I think the intention is very good. There are some problems with email that I don't know if they are possible to fix. Yes, JMAP [1] try to fix some of these problems for clients, but other flaws cannot be fixed without breaking backwards compatibility. Even unsuccesful, audacious experiments like that bring about discussions about what are the limits of current technology, what alternatives we have and what alternatives we can build.
Anyway, the best solution for asynchronous communication is still email. An incompatible solution would have to provide a compatibility layer for that. People refer Matrix here but I've always thought that, although many teams have adopted Matrix as a solution for general communication, it is a chat platform and not a replacement for asynchronous communication.
I just glanced over the site so I may sound repetitive: as a suggestion, I'd recommend adding some screenshots of client applications, diagrams explaning how mnm works, an explanation about federation and something that highlights differences to email.
Also on the drawing board is a live demo of the client in a webpage, with canned data.
All this -- TMTP, client, server, website -- are a work in progress (and a solo effort). This HN item is the first time any of it has received significant public attention. No one should be disappointed that it doesn't look polished!
I'm not concerned by the pessimistic comments, considering that it got 300+ up-votes :-) A lot of comments are from folks who didn't get a clear picture.
So what is the actual design? How is it different from SMTP or other comparable protocols or products? The page tells me it's meant to replace email, it binds together features like charts into this smtp replacement (don't quite get why one needs to have anything to do with the other), and then tells me where I can download it. The only link to a design spec goes to a Github repo with 1 issue namely "todo: design docs".
What's here to see if not that? I'm not going to spend hours on installing, running and testing software when I don't even conceptually know how it works. It's like linking a download page for yet another instant messenger, saying it'll have certain high level features, but not how the design will be better than the existing messaging services. Why should I install that?
I'd love to read about a concrete design that could fix (some of) email/smtp's problems and get invested in the idea and run a server of my own etc., in that order, but not spend hours investigating something with a 95% chance of not being better in the first place.
networkimprov 1195 days ago [-]
See link to "simple protocol" in first sentence of homepage, and link "Why TMTP?" after goals.
Whiteshadow12 1195 days ago [-]
Dropbox history on HN gave us a lens on how comments here are not true reflections of what could happen, as well as give every would be project the best clock, "what if we are the next Dropbox". Super fascinating.
jbverschoor 1195 days ago [-]
Well, I instantly knew Dropbox would be a hit. At least for me
This seems to mainly be disigned to work within an organisation. Like Microsoft Teams or Slack
It doesn't seem to work for a "common" email use case of contacting random people at other organisations. How would I say contact a vendor and a sales guy reply to me?
Can I publish my address on my website or business card and people contact me?
Of course any-to-any connections with email (or the phone system) spend a lot of time working with the downside of "unwanted" messages/calls.
IlliOnato 1195 days ago [-]
I think the idea is to have it adopted in stages.
First, to communicate within a single organization or project.
Second, between organizations/groups who adopted it already.
Third, when critical mass is reached, open it.
The really cool feature seem to be that an unknown/unapproved party can only ask you to establish a contact, and cannot immediately send you any links, attachments, etc.
networkimprov 1195 days ago [-]
There would be "marketplace" sites to connect with people.
I'm sorry, but with such an awkward name they won't convince many people.
umvi 1195 days ago [-]
And this is for techies who are used to xkcd, xna, gnu, etc. Could you imagine any average consumer-facing product with this name being successful? There's no candy-coating the truth I'm afraid - people couldn't handle a name like this, it's too much of a mouthful...
arm 1195 days ago [-]
Just to make the reference completely obvious, parent is referring to the candy named M&M's:
I honestly think we shouldn't be writing a new protocol to replace email but repurposing an existing, safe protocol like Signal's protocol and writing an app that looks like an email app.
Not only would it liberate Signal from centralization and make it federated, it would provide all the benefits of the protocol and whatever benefits people believe email have. Signal staff is already working on getting rid on removing the phone number requirement.
Another candidate could be the matrix protocol. I would really appreciate getting rid of email altogether. It's clunky and old.
nickik 1194 days ago [-]
Matrix basically does everything you would possibly want from such a system and it does much more on top of it, like e2e encryption.
Its based around the simple HTTP and JSON transports and its well standardized.
What am I missing?
retpirato 1188 days ago [-]
Some of the problems mentioned in the article could already be solved with gmail. To find out who sent you an email, append a "+[keyword]" & use that email to signup for a service. If you only use 1 site per keyword you will know which site sent it. Unfortunately that doesn't work for sending on email though.
avereveard 1195 days ago [-]
I don't get it, I can have all of this on email right now, and still be compatible with the rest of the world
> choose the organizations/sites that relay your correspondence
SPF/DKIM
> select which members of a site can correspond with you
whitelists have been a thing in a while
> always know from which site a message originated
SPF
> can block anyone with whom you’ve made contact
blacklists have been a thing in a while
> may leave a site and never see traffic from it again
domain filter are a thing too. preemptive 'but you still receive emails' - no you can send a 550 early on and interrupt the transfer as soon as you get the envelope sender domain
> 2 To offer capabilities missing in traditional email, including
that's all client side stuff and you can do all of it as of today on top of email. first part of the protocol is to know which user sent you markdown before, so you can send markdown to them. for user that you don't know if they have a markdown clent, your own client send a multipart with markdown and the local markdown representation as html, so you have a two-in-one discovery/fallback mechanism
while the first one might be beneficial as you give more control from the sysad and into the user hand for point 1.5, the second part is a problem we already had and we already solved with the transition from text email to html email and it was never a protocol issue to begin with, so I don't understand why it has been rolled in here for more effort and little effective gains.
networkimprov 1195 days ago [-]
You can (sort of, with a great deal of effort) but you don't.
And there is no effective way to prevent phishing in SMTP/etc if the server accepts connections from the public Internet.
If you didn't, I suggest reading the protocol draft and "Why TMTP?"
LoSboccacc 1195 days ago [-]
you can check that the envelop and message sender header match at the mx level and let spf handle the rest
networkimprov 1195 days ago [-]
There is no authentication of the John Doe part of
John Doe <not.john.doe@example.com>
LoSboccacc 1195 days ago [-]
DMARC
onebot 1195 days ago [-]
This was what Lotus Notes was to be. Maybe not open source, but a reach communications platform.
transistor-man 1195 days ago [-]
Just curious, how do you pronounce this, as in how would I recommend this to some one verbally?
networkimprov 1195 days ago [-]
em-in-em, like the rapper :-)
otabdeveloper4 1195 days ago [-]
The target audience of this uses Microsoft Exchange, not "email and SMTP" anyways.
TedDoesntTalk 1195 days ago [-]
How can this reach critical mass when people are already using email for a similar purpose?
mdpttt 1195 days ago [-]
This was the first thing that came to my mind as well, but on the other hand this seems to solve some real issues. Is there some space for solving this issue by evolving/improving SMTP?
jbverschoor 1195 days ago [-]
IETF / RFCs
I don’t understand why you need to completely (and naively) need to recreate something like SMTP.
This project tries to do too many things, even forms and charts. There’s no separation between layers.
gm 1195 days ago [-]
True, when I read the description, it looked to me like a bundle of smtp, email rules config utility, spam filter, and email client, all in one package you cannot reconfigure.
dsr_ 1195 days ago [-]
You can solve a bunch of SMTP problems by organizing people.
Let's call it the Secure Mail Cooperative. In order to join the SMC, you need to:
- have an acceptable usage policy that means you will not allow any of your users to send spam (defined as...). Your first violation gets a warning. Your second violation gets you suspended from the SMC for a month. Third violation in a year disqualifies your organization from ever rejoining. Reset the count a year after a second violation.
- register the fingerprint of your SSL certs with the SMC, which will publish it in a DNS accept-list.
- add an SMC header to your SMC-bound email that indicates the address of your SMC postmaster, who is one or more people who can enforce the AUP on your side. The SMC postmaster address should never accept non-SMC email.
- agree that the SMC postmaster will be tested every so often and a lack of a response within 168 hours will be considered a violation, same as spam.
That's all off the top of my head, but it could reasonably work... for individuals and small to medium organizations. It requires too much attention for a Google or Microsoft to afford.
ruslan 1195 days ago [-]
Fidonet operated exactly the way you describe. I recall in 90th I used to run quite a large Fidonet node. I was responsible for my points' (users) behaviour - when someone violated rules by misbehaving in an echo conference it effected me as a boss node in first place, I had to execute the ban and brainwash negligent user. What's more, I had to introduce new and old users to fidonet policy and its updates regularily to make sure they understand the rules. This all worked pretty well and was widely accepted. Fidonet was incredibly popular in 90th.
I think we may create a similar network basing on same old ESMTP, what we need is just to agree on rules and their enforcement. Also we need to secure inter-node communications.
TedDoesntTalk 1195 days ago [-]
i wouldn't have my organization join this cooperative. Why? Because accounts get compromised and spam gets sent. It just does, even with 2FA and NFC dongles and public/private keys.
In your cooperative, if two or more of the thousands of accounts in my org are compromised, the entire org loses email?
Not gonna happen, even if you tweak the rules to be more lenient.
Realistically we will always have spam. It can be reduced but, just like snail mail and all other forms of push communication, you will always get spam. Get over it.
ruslan 1195 days ago [-]
This is called responsibility. Lack of respobsibility brought us to the point where noone cares about security seriously. Yes, we talk much about it, but in reality we don't give a damn about it because possible damage is usually inappreciable.
IlliOnato 1195 days ago [-]
If I understand them correctly, they have in mind the following:
Stage 1. Organizations would use it to create _internal_ messaging systems, for employees/members only.
At that stage it does not replace e-mail, and both systems are used alongside it.
If it is mandated to be used for internal communication,
this solves the problem of getting "Open this immediately!!!" e-mail claiming to come from your boss, but being in fact from scammers.
It also solves the problem of e-mail from your colleagues getting into spam folder.
Stage 2. If your clients, suppliers, etc. start to use mnm, you can add them to your mnm network, and stop using e-mail in communication with them. When you reach this stage, you can severely reduce using of e-mail for your organization, at this point perhaps the only people who need e-mail are marketing, support, and perhaps developers (but the latter only for maillists).
3. mnm gets a critical mass, where it makes sense for organizations and projects start to offer mnm as an option to contact them, and later to require them. At this point "general public" starts to use mnm.
4. When it reaches critical mass among general population, e-mail can start to be phases out.
Don't know how realistic is this, and some design decisions of the mnm team seem counter-productive, but to me it does not sound completely crazy.
dingaling 1195 days ago [-]
But all that complexity of migration, when similar results can be achieved today using SMTP trust-lists and separate accounts.
In your roadmap example, steps 1 and 2 can be done right now by maintaining trusted network lists for SMTP, so that employees can't be spammed by unapproved senders. And it can enforce TLS between those trusted networks for privacy.
Meanwhile the customer-service people can have both guarded @internal.bigcorp.com and open @bigcorp.com accounts, the latter for public communication.
That's a pattern that's already in use and works on existing infrastructure. Any new protocol will have to offer overwhelming benefits.
Any particular reason XMPP can't extended to support email-like usage? It's not like email is that special, apart from inertia and the fact that it's not going anywhere because of it.
josephg 1195 days ago [-]
XMPP can be extended to support anything. We could do http over xmpp if we wanted, but that doesn’t make it a good idea.
mst 1195 days ago [-]
There's also an RFC for SOAP transport over SMTP.
Occasionally I threaten to implement it in order to upset somebody.
josephg 1195 days ago [-]
:( I'm upset already.
md_ 1195 days ago [-]
As someone fairly well-versed in the email ecosystem, I don't understand this proposal, like, at all.
- Is it even federated? It seems like not--it seems like it's proposing a protocol for organizations to use to run their own messaging service in-house?
- If it's not, this doesn't really get at either the _interesting_ parts of email--the universal federation--or what makes it _hard_. (The reason email has spam, authentication, and confidentiality problems really boils down to the difficulty in securely establishing authoritative identities; this is why protocols like DANE, DMARC, DKIM, SPF, and MTA-STS are tacked on top.)
- If it is, the documentation is woefully underemphasizing this point. :)
- The proposal (as others have noted) seems to mix application features with message delivery. This doesn't seem useful.
- Instead of using encryption, the proposal says that "To prevent theft of correspondence (in the event of a compromised account or server) the messaging service must store only messages that have not yet been delivered". This is...a really problematic design choice.
- The proposal suggests a bunch of reasonable application features which many email providers (at the MTA or MUA level) do already support (like "blocking anyone", "selecting [who] can correspond with you", etc). Email is fully compatible with these features!
- Conversely, the proposal suggests some features which are not obviously satisfied by the proposal itself, like "always know from which site a message originated." Again, where is identity even discussed?
To be blunt, this proposal doesn't seem like it was written with an eye to what's actually challenging about email. The fact that SMTP is not JSON is really not a significant problem; the focus of this proposal is just in the wrong place.
To make this more constructive, I would suggest reading the IETF SMTP WG archives to understand the kinds of problems implementors and spec-authors face.
I'm frankly pessimistic about the prospect for a wholesale (non-incremental) replacement of SMTP, but even as a design exercise, starting with what real implementors struggle with makes sense.
networkimprov 1195 days ago [-]
TMTP is not federated because federation is a security hole, except in certain circumstances. There are other ways to connect with people outside your current circles. See my other comments herein.
I've been asked to create a doc describing the architecture and infrastructure of TMTP. That should clear up the Q's you and others have raised.
(I am the author.)
md_ 1195 days ago [-]
So is this better viewed as a replacement for enterprise messaging?
The protocol[1] has two layers, altho that's not emphasized in the draft. The outer layer covers posting messages for recipients. The inner layer describes message contents, and isn't enforced by the server (see protocol #7 Post //datahead segment). You can do special-purpose apps with the outer layer without supporting the inner if you don't send messages to normal clients.
EDIT: The protocol will see many more revisions (some already planned), and real-world use, before it's proposed to a standards body.
This isn't a drop-in/swap-out replacement for email. It's a (far) better way of doing electronic correspondence. It will take some years to build the community and infrastructure necessary for TMTP to widely supplant SMTP. It's been suggested recently that I draft an architecture doc for TMTP[2], which will also discuss infrastructure.
Part of that infrastructure involves "marketplace" sites which verify members' real-life identities and let people make contact with folks outside their normal circles (e.g. work, school, community, hobbies/interests). Most professional organizations would run marketplace sites for their members.
I gather that the IETF has (repeatedly) stated that it is not interested in adjusting SMTP to solve "the spam problem". [3]
Re end-to-end encryption, that can be considered for the inner layer protocol. I don't rule it out, but it's not a priority at present.
If successful, "mnm" won't be the only implementation of TMTP. Maybe some other client will have a better name. (OTOH, Slack did well, and that's a pretty terrible name for a workplace tool ;-)
EDIT2: SMTP and related protocols have no effective defense against phishing. A large fraction of phishing attempts originate at authenticated domains, like Gmail.
IETF isn't disinterested in solving the spam problem. If that were true, why would they have published multiple RFCs to fight spam?
leshokunin 1195 days ago [-]
Interesting idea! I think we could use Mailscript to bridge Mnm with email. Would you be interested?
networkimprov 1195 days ago [-]
What should I read about Mailscript?
leshokunin 1195 days ago [-]
You can see more at Mailscript.com. Check out docs.mailscript.com and api.mailscript.com to get started.
Happy to chat any time. I’m Shokunin@mailscript.com
networkimprov 1195 days ago [-]
@DANG could you push this group to the top of the comments, so ppl see answers to FAQs? Thanks!
anticensor 1195 days ago [-]
Why TMTP and not MQTT? The latter is a general purpose messaging protocol too.
petre 1195 days ago [-]
Because one shouldn't subscribe to mail but rather get it?
retpirato 1195 days ago [-]
This looks a lot like instant messaging to me. Maybe glorified IM, but still IM.
de6u99er 1195 days ago [-]
Does anyone remember Google Wave (now Apache wave)?
I loved the concept.
wowxp 1195 days ago [-]
The source code is totally unreadable.
networkimprov 1195 days ago [-]
Please clarify. I don't use go fmt because mnm makes heavy use of the filesystem API, and the error-handling boilerplate for rarely-occurring, unrecoverable errors is painfully high.
Email is fine and has a place in the array of digital communication choices we have available. If you don’t like email you can always use a private communication format instead and have your safe walled garden. But a federated, openly addressable protocol is important to retain. Email can also be made reasonably secure - with SPF, DMARC, more secure DNS, and other evolutionary changes. But I don’t get the purpose of this project in trying to attack the foundational motivations for email to exist.
GNU_James 1195 days ago [-]
I'll stick to regular email till I'm dead. Thanks.
networkimprov 1195 days ago [-]
A killer phish will get you sooner than later :-)
denton-scratch 1194 days ago [-]
Phishing depends on human factors; it amounts to deceiving recipients into trusting a message. That can be done by an authenticated sender as well as by a stranger.
My opinion is that the OP is premature.
- I can't see how this scheme is supposed to interoperate with ESMTP etc.
- I don't want charts and slidedecks running in my mail client
- I'm not OK with relying on a browser as my mail client
- The linked website is far too thin for a proposed email replacement; there are scores of dead email replacement proposals, and a new FUSSP has a steep hill to climb. Build a team, get feedback from your new colleagues, and say Hi again when you have a website that addresses objections.
Good luck!
networkimprov 1194 days ago [-]
The project has code you can try; virtually all of the work has gone into that, vs the website.
An FAQ addressing the Q's posted here will be live on the site late on Jan 18th.
alisausa 1195 days ago [-]
Hello
alisaus2 1195 days ago [-]
Top burny busty chicks only on this site! Follow the link, and you won’t be sorry! - https://adultlove.life
superkuh 1195 days ago [-]
It's cool but what I really want, what I'd trade almost anything for, is an all-in-one smtp+dkim+imap mailserver binary written in a non-meme language.
tacon 1195 days ago [-]
I have been running my own mail server since the 1980s, using Debian/exim4 for the last eight years. With the weird patches for greylisting, etc., I never wanted to update it. In the last week, I jumped to docker-mailserver[0]. O.M.G. That is too easy! Yes, there is picking one's way through the options at first, but those go in a tiny config file and survive updates. The heavy lifting is all in one container. I just use it as a mail gateway, into a local machine that has port 25 filtered, but I played a bit with the imap functions, too. You do have to have a box somewhere that can run containers, which for me is a KVM VPS.
Gmail instantly was happy with my inbound emails. I got on a backscatter blacklist because I didn't immediately drop invalid email addresses at the gateway, but that will time out shortly. And just as I had settled in with the new server, I got to test the update function. This week the entire docker-mailserver project moved to a new repo name on Github, with a new release. A couple of the config files changed names, but nothing much in contents. A docker pull for the new image name, and my mail server was running the fresh release. Happy, happy, happy.
What languages are acceptable then? You may need to provide a definition to prevent confusion.
superkuh 1195 days ago [-]
I mean languages that have been in existence for more than a decade and aren't controlled by a single corporation.
t0astbread 1195 days ago [-]
Go has existed for 11 years. It's probably safe to say that it won't die off soon. As for the control part: What could Google do to Go that would affect you as a user of some software written in it?
denton-scratch 1194 days ago [-]
Deprecate it.
t0astbread 1193 days ago [-]
If a programming language has exited for 11 years I'd be more worried about the author of the software dropping that than the author of the language deprecating the language. It's the Lindy effect.
gm 1195 days ago [-]
Why would a market care about the language a product's written at? Maybe only programmers, and anal retentive ones at that.
bee_rider 1195 days ago [-]
I wouldn't want to depend on some open source project in an obscure language because it will likely get fewer contributors. But go isn't some obscure language.
Proven 1195 days ago [-]
You won't get to depend on it if it has few contributors.
jagger27 1195 days ago [-]
Go isn't a meme language.
alisausa 1195 days ago [-]
Top burny busty chicks only on this site! Follow the link, and you won’t be sorry! - https://adultlove.life
flemhans 1195 days ago [-]
Would popular rapper Eminem claim trademark infringement?
reaperducer 1195 days ago [-]
Not any more than candy maker M&M Mars would.
xwdv 1195 days ago [-]
I wonder if people in 10 years from now will come back here to see the beginning of the project that replaced email.
gm 1195 days ago [-]
The road of tech is littered with the bodies of email replacements.
Some of them went on to thrive, but not as email replacements: Slack for one.
knorker 1195 days ago [-]
Just like with Wave.
reitanqild 1195 days ago [-]
This one has the benefit of not being owned/backed by a company that must be one of the biggest quitters of all time ;-)
greatgirl 1195 days ago [-]
Most hard problems are not solved simply by creating a technically superior product, they are often unsolvable due to mundane factors like user adoption, distribution, financial issues, server issues, etc.
m___ 1195 days ago [-]
Is there anything here that ssh protocol and derivatives, sshfs, scp, sftp, and then VPNs cannot do,
It seems an ill defined approach to protocol, mixing idiot proof user interfaces with the former. The license??? Looks and feels like another pair of sneekers. The functionality is all surrounding us, the innards (protocol), are many that can comply with the white-paper.
anaganisk 1195 days ago [-]
Yeah, please do come back with your comment, when a regular babushka can ssh into her server in AWS, and run all the hell you mentioned. I dont understand people who think every thing is designed with developers in mind. Not everyone is a GNU GPL C++ cruching desktop junkie.
petre 1195 days ago [-]
The junk folder should be the default deliveey folder, not the inbox. Anything not moved from it for several months should be erased.
tsimionescu 1195 days ago [-]
So people should be expected to regularly go through their Junk folder to see if anything interesting has popped up?
A junk folder is only useful if you essentially never have to open it.
megous 1195 days ago [-]
On the contrary, Junk folder is only useful if you go there regularly and check that non-junk mail didn't get there. Especially for services that have too much false positives, like gmail.
Otherwise you can just drop the mail you'd put there immediately on reception and not even store it.
userbinator 1195 days ago [-]
I'm particularly wary of mail filtering that seems to always put mail from a sender that hasn't been seen before into junk... which certainly puts a bit of a chilling effect on communcation.
1195 days ago [-]
umvi 1195 days ago [-]
Think of it like cellphones. If you aren't in the contact list you are blocked by default.
tsimionescu 1195 days ago [-]
That's not at all how my cellphone works. This has been thankfully the case recently when a hospital contacted me to notify that they had admitted my grandmother.
It's not safe to block calls from unknown numbers if you have people that may depend on you.
Email is much less likely to be critical, but there are still occasions when you may be contacted with important information by addresses you didn't think to white list.
beowulfey 1195 days ago [-]
There was a time not that long ago when we didn’t have caller ID and we actually answered ALL our phone calls
hyakosm 1195 days ago [-]
It's the difference between a social network decicated to exchange in a bubble and a truly universal communication service like post, phone system or email where anyone can reach anyone without subscribe to same/any service, without being "friend" or trusted.
FiveNinjas 1195 days ago [-]
you mean like Skype. There's nothing specially 'email' about this other than it is a bad mix up of a P2P communication app and a supposedly 'trusted' version of SMTP.
tormeh 1195 days ago [-]
Email sucks. It doesn't need replacement with something else that does the same but encrypted. The whole skeuomorphic concept of electronic mail is just not great and needs to go away. What we need is federated chat, like Matrix maybe.
Apropos: Is anyone aware of an email client that groups mail by sender, like a chat client? That would make email far more usable for me, as addresses that send a lot of mail and addresses that send little mail would get the same amount of screenspace. Currently my company email is drowning in automated internal semi-spam.
na85 1195 days ago [-]
>Email sucks
Email is great. I can choose between umpteen providers or run my own mail server, it's a standard protocol with many different clients to suit one's needs, I can't get banned by a faceless FAANG corporation for no reason and with no recourse, I'm not locked into some walled garden and dependent on the benevolence of corporate overlords and I don't need to worry about some intern at Google suffering from NIH syndrome deciding to make completely unneeded "improvements" that negatively impact my UX.
Email is old but that doesn't mean it sucks.
Internal "semi-spam" is a social problem and needs a social solution. Changing protocols won't change the spam problem at your company.
zimpenfish 1195 days ago [-]
> I can't get banned by a faceless FAANG corporation for no reason
They can make your life difficult though with their seemingly random decisions about what constitutes spam even when you jump through all the SPF/DKIM/DMARC/etc hoops.
na85 1195 days ago [-]
What I mean is they can't lock me out of my emails and contacts without recourse because (unless I use gmail or similar) my contacts are stored on my local device, and potentially so is my mail.
tormeh 1195 days ago [-]
All the benefits you're listing are benefits that any federated protocol, for example Matrix, has. Completely orthogonal to email itself.
na85 1195 days ago [-]
And the problems you listed with email aren't actually problems with the technology so much as problems with the way people at your company (and others) misuse the technology. They're completely orthogonal to email itself.
mac01021 1195 days ago [-]
I'm not sure that's true. Email has a somewhat archaic data model that has suboptimal support for things like threading.
rakoo 1195 days ago [-]
What exactly does it need to do better threading ? Today a client can write anything they want in the References: and In-Reply-To: headers, and the server doesn't verify that it's valid. Would that be enough for you ?
tormeh 1195 days ago [-]
I only mentioned one problem with the clients, and an abstract complaint about doing one electronic communication but pretending it's physical.
Some problems with email, from a user perspective:
- The latency is too high for truly real-time communication
- There is no cryptographic verification of the sender's identity (this problem is also shared with telephony). This has lead to really harsh anti-spam measures that make it hard to self-host. Sender verification + client-side sender whitelists would solve spam for good. It also means grouping by sender gives a very false sense of security regarding identity continuity between messages
- There is no good support for groups or threads. Subject lines of type "Re: Re: Aw: Re: Sv: new proposal" is not an acceptable solution, as they look ugly and clients often disagree on how to parse and write them, leading to breakage of the thread
- Clients do not group by sender, group or thread, partly because these concepts do not actually exist in email (see above) and partly for social reasons
- Partly for historical reasons (it's just mail on a computer!) and partly for technical reasons (there is no sender, etc.) email is presented as huge letter-like affairs, leading to a felt need for all sorts of formalisms for every single message even if the messages are two minutes apart. Also email signatures (with logos?!) being attached to every message are just so wasteful both in terms of storage and in terms of screen space
na85 1195 days ago [-]
> The latency is too high for truly real-time communication
If you want real-time communication you really ought to be using VOIP.
> There is no cryptographic verification of the sender's identity (this problem is also shared with telephony). This has lead to really harsh anti-spam measures that make it hard to self-host. Sender verification + client-side sender whitelists would solve spam for good. It also means grouping by sender gives a very false sense of security regarding identity continuity between messages
I agree that the crypto situation in email needs addressed. I don't think that the answer to this problem is "throw it away and start competing standard #1982374" though.
> There is no good support for groups or threads.
Mailing lists are groups. Threading actually works quite well with subject-line threading. Mailing lists have been doing this successfully for decades.
>Clients do not group by sender, group or thread,
Some do. Gmail does, for example.
>Partly for historical reasons (it's just mail on a computer!) and partly for technical reasons (there is no sender, etc.) email is presented as huge letter-like affairs, leading to a felt need for all sorts of formalisms for every single message even if the messages are two minutes apart. Also email signatures (with logos?!) being attached to every message are just so wasteful both in terms of storage and in terms of screen space
The formalisms thing isn't actually true, and all of these are social problems, not technical ones.
It's okay to just admit you don't like email, even if it's for purely subjective reasons.
denton-scratch 1194 days ago [-]
>>Clients do not group by sender, group or thread,
> Some do. Gmail does, for example.
Thunderbird too.
For threading, look into the use of the References: email header.
This grouping complaint is a poor excuse for trying to junk existing email solutions; obviously the existing structures are capable of supporting that kind of grouping. If you want to launch a replacement for the existing structure, it's unhelpful if you are unfamiliar with the strengths and weaknesses of what you are proposing to replace.
The weaknesses of traditional email have been a subject of intense and detailed discussion for over 20 years. For a replacement to succeed, it will need to take account of the content of those discussions.
dieortin 1195 days ago [-]
Some of this problems are (in my opinion) actually advantages.
E-mail’s latency makes it so people write longer, thought out messages, instead of spamming very short messages. This makes for a different kind of communication, which is better for many things.
It also removes the expectation to respond really soon, and the sender doesn’t know if you’ve read the message.
denton-scratch 1194 days ago [-]
Indeed!
I for one appreciate this property of email. The recipient doesn't neeed to be at their desk; their equipment doesn't have to be switched on; and they don't have to be awake at the same time as me.
I also prefer to type considered, thought-through messages (and I am unhappy that various messaging clients have hijacked email, so that my correspondents reply to me in a format that suggests they mistook my email for a text message).
Also, I have no messaging client on my laptop; and my fingers are too blunt to accurately type more than a few characters using the virtual keyboard on my mobile.
RcrdBrt 1195 days ago [-]
Deltachat maybe? Check it out. You might like it, it's a federated chat (since mail is) and built on top of the email tech stack
This seems like a bad idea and goes against years and years of open systems design.
Also addressed here: https://news.ycombinator.com/item?id=25804869#25807379
(I'm the author.)
Or watch on Twitter: https://twitter.com/mnmnotmail
It should have sender authentication. E2E encryption that's easy and works by default. Those would be more than enough killer features, SMTP is just too broken and all the workarounds we have in place like DKIM, SPF, Spam ratings etc etc don't make up for it. We still have spam, important mails still end up in our junk boxes, and nobody trusts it enough anymore to put important content in emails. The war has long been lost.
"War"
Few, outside small, likely familiar tech circles, use these terms when discussing email.
Not being SMTP usually means being another messaging island or other, which has only strengthened email.
Lists have huge value today, still!
Now, there is one exception: Marketing
The reason? Everyone else is busy getting work done.
Whatever may transcend email needs that quality, or it will, in fact be, yet another messaging island.
Email must be: * Secure and encrypted; * Have proven identity; * Have easy to fabricate and predictable rendering;
I feel like the ability to have forms and charts is very nice, but adds a lot of complexity, especially from a security point of view. I'd be looking at this kind of "application level" functionally being a layer added optionally on top, not being in the core protocol.
The difference seems to be that ProtonMail don’t allow you to use normal imap and your own client with pgp, but force you to use their client. This is probably a trade-off made to protect users against them selves in one way (disabling encryption for grandpa) and hiding the non tech-savvy from all the technical details.
Again, many assumptions here.
So, to me, mentioning proton here doesn’t make sense as the underlying tech: smtp & pgp have existed and been industry standard for a long time. So there is not issue of adoption.
https://www.cyberscoop.com/jabber-xmpp-cybercrime-russia-enc...
There was a major deep web counterfeiter about a decade ago that remained active on Jabber even as a federal fugitive, not sure what ended up happening to him.
Federated/decentralized, secure, non-real-time messaging is the problem space. If it can make some overwhelmingly common use cases of current e-mail that much easier, then so be it.
If history has any say on this, communication solution based on proprietary technology will meet their death sooner rather than later. How many network protocols have been invented before and after TCP/IP? I know we are talking about messaging now, but messaging is just another overlay network over TCP/IP.
I'd envision in the future that the open messaging systems will be more pervasive. It will be based on local-first software and probably based on the automerge capabilities. The automerge community is focusing on collaborative editing at the moment but could someone please work on automerge solution for messaging system? This can be an excellent new paradigm for open world of messaging. I am seriously tired of people asking me to install the proprietary software of WhatsApp, Line, Wechat, etc.
There are many, many protocols for exchanging messages, chats, files, etc. (basically, what e-mail does), they all come, get some traction, last for two years, then die (except maybe irc, but except for a few nerds, it's hard to get anyone on there anymore). Some get killed by google, some just get replaced by "the next new thing"... but e-mail still lives, and works, and does what is needed.
So yes, we really do need something better than email (and we have plenty of options), but it doesn't have to (nor will it any time soon) replace email.
Well IRC isn't really meant to be used for persistent communication anyway
People do not want email replaced. They may want a new thing enough to use it in huge numbers.
And then that thing has to endure long enough, be open enough to see even a modest level of trust email has at this point.
Also addressed here: https://news.ycombinator.com/item?id=25804869#25807379
(I'm the author.)
EDIT: On thinking about it, I'd think this would have more chances if they phrased it as an augmentation of email's capabilities rather than an email killer.
1. Call the protocol "Email 2"
2. Build something that actually justifies the name
I'm only half joking; the messaging around the protocol is almost as important as the protocol itself. iMessage is a good example of how to expose something like "Email 2" to the end user: as a seamless upgrade, indicated by a subtle UI element, when a client happens to negotiate the upgraded protocol with the server.
Enabling incremental upgrades to infrastructure is critical, but strict backward-compatibility isn't necessarily so. As long as the architecture of the new protocol makes falling back to IMAP/SMTP straightforward when an upgraded client or server isn't available, Email 2 doesn't have to be able to talk directly to legacy.
There's certainly a chicken-and-egg problem in driving enough server adoption to get client vendors to add support while driving enough client adoption to get server operators on board, but there's probably a sweet spot between making a clean enough break with legacy tech that it's more straightforward to implement, while making it conceptually similar enough that it can still plug into the same patterns.
The problem with that approach is that as long as 0.01% still uses the old protocol, you can‘t get rid of it. And then you have a bag with the old and new protocol and maybe after 20 years you realize it‘s going to take another X years until you have at least some relevant adoption, as demonstrated with IPv6.
If one is ever going to „replace“ email it happens on top of the existing protocols and not as a replacement.
This sort of thing could be deployed by people in addition to the other services. For a while and perhaps a long while it’ll be fringe. But if there’s enough utility to it then it may just catch on.
It is backward compatible, smtp, imap, pop3 and support unicode email as well, and it is REST API callable. So you can receive and send email.
Also addressed here: https://news.ycombinator.com/item?id=25804869#25807379
Why not a proxy through Signal as an option...?
The reason I first got an email address was to get a Runescape account. Email's killer feature on the modern internet is identity management. On most sites it's impossible to create an identity without one.
I'd guess that site is leveraging the effort which webmail providers spend to weed out bots and sock-puppets. And perhaps they use the address for adtech purposes. But I don't know for sure.
I'd love to hear from such sites about how they use customer email. If it's not primarily for communication, it may not make sense to accommodate it in TMTP.
What do you mean?
> I'd guess that site is leveraging the effort which webmail providers spend to weed out bots and sock-puppets. And perhaps they use the address for adtech purposes. But I don't know for sure.
It’s a lot like having a physical address which is used as a core part of meatspace identity management.
> I'd love to hear from such sites about how they use customer email. If it's not primarily for communication, it may not make sense to accommodate it in TMTP.
A shared unique identifier (value for user is that it is consistent across services).
A means of authentication when primary auth (password) cant be used (company sends links etc).
1-1 channel of communication (notifications of activity or changes in a service).
Obviously, it’s just my opinion, but making a new messaging protocol won’t fix email. My hunch is that is because email’s primary purpose (to the end user) is not to provide a messaging channel but to provide an identity.
I thought it was perceived as one of the fundamental flaws of email.
Saving others a click:
> Re end-to-end encryption, that can be considered for the inner layer protocol. I don't rule it out, but it's not a priority at present.
https://www.reddit.com/r/golang/comments/kxe5bi/mnm_an_open_...
The one interesting link from his post, is a link to the spec itself. https://github.com/networkimprov/mnm/blob/master/Protocol.md
I have a "Yes, and ..." attitude to input and community. (I know the pain of being part of an open source community that doesn't.)
(Yes-and is a comedy/theatrical improv technique; always embrace what the previous speaker said, and build on that. Tho admittedly, you can't run an open source project in an entirely improvisational manner :)
I was looking for protocol descriptions in how this could work. Author said people would be more impressed by code - but I think a protocol spec along with a reference implementation would be useful.
So... what in this proposal isn't fulfilled by a private walled message platform such as Whatsapp, or Signal, or Facebook Messenger? Nothing here needs this to be 'email'.
And if you're into adding trusted layers with revocation to email, well we have DKIM, client certs, encryption. You can do the 'trusted' enforceability at the application level over the untrusted SMTP network level.
All in, probably DOA as an idea.
I went and looked for a protocol spec as well. When I didn't see anything concrete on the site in the submission title, I poked around the comments a bit more and found a link to the Github issue[0] requesting detail with respect to the architecture of the TMTP protocol.
I further poked around in the appropriate places[1] but found nothing remotely related.
The protocol spec[2], while useful in defining the control mechanisms and message formats is vague or silent when it comes to a variety (too many to list completely here) of functional, operational and implementation issues.
A comparison of TMTP's spec with SMTP[3] ("the protocol at the root of all these problems"[2] with messaging), is quite illuminating.
While SMTP by itself lacks a variety of features, it provides a robust, interoperable architecture that's broadly supported and has been augmented repeatedly by other protocols (e.g., MIME, DMARC/DKIM, SMTP-AUTH, LDAP, etc.) to provide such features.
It's not clear to me that mnm/TMTP has been fleshed out enough to provide a real alternative to SMTP+extensions. Rather, it appears to be another (there are many) client/server messaging application that's not interoperable.
Should these issues be addressed, discussed and refined in the appropriate forums[4], It's possible that TMTP could turn out to be a viable replacement for SMTP.
I applaud the authors' work and hope they have much success with their entry in the messaging app market.
[0] https://github.com/networkimprov/mnm/issues/5
[1] https://www.ietf.org
[2] https://mnmnotmail.org/rationale.html
[3] https://tools.ietf.org/rfc/rfc5321.txt
[4] https://www.ietf.org/how/wgs/
Edit: Fixed links.
And yes, TMTP will see a lot more revision, and real-world use, before it's proposed to any standards body.
(I'm the author.)
Yes. That was the document I was talking about, but I linked the wrong page.
My apologies for any confusion.
I've implemented both client and server, so there's the basis for a "reference implementation".
More here: https://news.ycombinator.com/item?id=25804869#25807379
(I'm the author.)
https://en.wikipedia.org/wiki/Cost-based_anti-spam_systems
There's nothing insecure about including JSON data for a chart/graph. It wouldn't support arbitrary JS (for heaven's sake :)
More here: https://news.ycombinator.com/item?id=25804869#25807379
(I'm the author :)
I think this is great and not great.
Great because SMTP is completely broken. The lack of E2E encryption and sender authentication makes it completely useless these days. We're bogged down in workaround upon workaround to combat spamming/phishing and other abuse. Companies no longer rely on its security but instead just send an email to check their portals. We need something new.
However the whole slideshows/surveys should be handled in the applications. We need a good protocol first.
The elephant in the room here is that there is nothing wrong with, say, PGP. Any meaningful approach using public key crytography and crytopgraphic signatures to achieve confidentiality and authentication over SMTP ends up with the conclusion that you could of just used the OpenPGP protocol.
I think the reason we like to think that there is some new method available that will finally make things work is the hope there is a purely technological solution available. After 30 years of failing to come up with such a solution it is clear that there is no such solution possible in isolation.
If you only want to keep your message body confidential (or authenticated), PGP is reasonable. But it provides a strictly lesser degree of secrecy than modern e2ee messaging applications.
In fact, depending on your threat model, modern SMTP-TLS (which is not e2ee, but does provide some metadata confidentiality and forward secrecy) may in fact be an improvement over PGP.
>...metadata secrecy...
This is not a huge problem with a medium like email where you can be more or less anonymous. Contrast with things like instant messengers that insist on a phone number.
>But it provides a strictly lesser degree of secrecy than modern e2ee messaging applications.
Most of those applications take the form of instant messengers. Since such things by necessity have to leave the private key material exposed all the time they are generally less secure than something like encrypted email where that key material can be kept very locked down.
>...modern SMTP-TLS (which is not e2ee, but does provide some metadata confidentiality and forward secrecy) may in fact be an improvement over PGP.
True enough. SMTP-TLS does provide even more security to the encrypted email user. Most importantly, it prevents passive listeners from detecting that an email was encrypted and thus worthy of further interest.
I can't help but point out that this sort of discussion is an excellent example of the state of denial that exists with respect to end to end encrypted messaging these days. Rather than addressing the broader overall issues we are quibbling about obscure technical details.
However, these days this should be less of an issue in an ever connected world. Nobody uses UUCP or batched SMTP anymore :)
E2ee messaging is used by billions. Without talking details, it’s hard to know what about the status quo we wish to improve.
- The ability to painlessly access your mail from a number of different clients, ranging from fully-featured desktop clients to smartphone apps to webmail.
- Server-side filtering (both spam and in general)
- Server-side searching (mandatory for webmail and depending on how big your mail archive is, still rather useful for smartphones, too)
Pretty sure that is what the unencrypted "Subject:" is for... :)
There is now a way to encrypt the subject but it is turning out to be a controversial thing to do. Perhaps that is at least partially the reason.
Weeell, yes, possibly :) – but more seriously, the subject line only gets you so far, so I do need fulltext search as well.
Both SPF and DMARC provide sender authentication.
Also, they don't really provide sender authentication. They provide sending domain->sending server verification. If you have a business that uses the same email provider, you will be able to fake sender auth if you can convince the server to send it. This is why it's a kludge.
If we'd require emails to be signed by default this issue wouldn't be present.
What I really miss these days is public protocol innovation. In the old days if a protocol stopped meeting the needs, people would go back to the drawing board and publish and agree a new RFC. These days we just tack on workarounds to old protocols without fixing the root issues, or we switch to closed alternatives (like what has happened to IM) which is even worse.
So is every proposed replacement for SMTP.
I would imagine it would gather uptake pretty quickly. Just like other protocols which have advanced. Like SSH v2, nobody uses v1 anymore.
>Both SPF and DMARC provide sender authentication.
And TLS encryption via required encryption via STARTTLS[0][1] plus s/mime or gpg can provide E2EE.
Not sure if mnm/tmtp supports endpoint data encryption though.
[0] https://en.wikipedia.org/wiki/Email_encryption
[1] https://tools.ietf.org/html/rfc8314
s/mime is expensive in terms of certificates and difficult to set up. GPG's trust chain based on key signing parties has never taken off outside the crypto geek community (Don't get me wrong, I'm one too!)
Perhaps a "let's encrypt" approach to s/mime could work though. I could see that happening. It would indeed solve a lot of issues.
Corporate environments generally have an easier time with s/mime, and IIUC this app is focused on corporate environments.
GPG is nice (I like a lot and have used it for a very long time), but it's certainly niche.
That said, I included s/mime and gpg to illustrate that end to end encryption is not only possible, but that mature, functional tools are available in an SMTP+extensions environment.
It would be interesting to know how mnm/TMTP does encryption. I'd assume it uses TLS for transport. As for endpoint and server storage encryption (assuming it does that at all), you'd hope they'd use some sort of asymmetric key encryption, which raises the same issues as s/mime and gpg.
I think the author missed the whole point. Not everyone has access to fast internet or internet at all. SMTP was designed with that in mind, and it also works better than other real time messenger in that sense. Async federated communication.
JMAP offers a solution for intermittently connected devices (phones) which expect notifications and messages from Internet services.
I expect TMTP will do the same; it's far from final. (I'm the author.)
First, I think the intention is very good. There are some problems with email that I don't know if they are possible to fix. Yes, JMAP [1] try to fix some of these problems for clients, but other flaws cannot be fixed without breaking backwards compatibility. Even unsuccesful, audacious experiments like that bring about discussions about what are the limits of current technology, what alternatives we have and what alternatives we can build.
Anyway, the best solution for asynchronous communication is still email. An incompatible solution would have to provide a compatibility layer for that. People refer Matrix here but I've always thought that, although many teams have adopted Matrix as a solution for general communication, it is a chat platform and not a replacement for asynchronous communication.
I just glanced over the site so I may sound repetitive: as a suggestion, I'd recommend adding some screenshots of client applications, diagrams explaning how mnm works, an explanation about federation and something that highlights differences to email.
[1] https://jmap.io
See also https://news.ycombinator.com/item?id=25804869#25807379
Also on the drawing board is a live demo of the client in a webpage, with canned data.
All this -- TMTP, client, server, website -- are a work in progress (and a solo effort). This HN item is the first time any of it has received significant public attention. No one should be disappointed that it doesn't look polished!
I'm not concerned by the pessimistic comments, considering that it got 300+ up-votes :-) A lot of comments are from folks who didn't get a clear picture.
(I'm the author.)
Follow mnm: https://twitter.com/mnmnotmail
What's here to see if not that? I'm not going to spend hours on installing, running and testing software when I don't even conceptually know how it works. It's like linking a download page for yet another instant messenger, saying it'll have certain high level features, but not how the design will be better than the existing messaging services. Why should I install that?
I'd love to read about a concrete design that could fix (some of) email/smtp's problems and get invested in the idea and run a server of my own etc., in that order, but not spend hours investigating something with a 95% chance of not being better in the first place.
It doesn't seem to work for a "common" email use case of contacting random people at other organisations. How would I say contact a vendor and a sales guy reply to me?
Can I publish my address on my website or business card and people contact me?
Of course any-to-any connections with email (or the phone system) spend a lot of time working with the downside of "unwanted" messages/calls.
First, to communicate within a single organization or project. Second, between organizations/groups who adopted it already. Third, when critical mass is reached, open it.
The really cool feature seem to be that an unknown/unapproved party can only ask you to establish a contact, and cannot immediately send you any links, attachments, etc.
More here: https://news.ycombinator.com/item?id=25804869#25807379
(I'm the author.)
https://en.wikipedia.org/wiki/M%26M's
Also addressed here: https://news.ycombinator.com/item?id=25804869#25807379
Not only would it liberate Signal from centralization and make it federated, it would provide all the benefits of the protocol and whatever benefits people believe email have. Signal staff is already working on getting rid on removing the phone number requirement.
Another candidate could be the matrix protocol. I would really appreciate getting rid of email altogether. It's clunky and old.
Its based around the simple HTTP and JSON transports and its well standardized.
What am I missing?
> choose the organizations/sites that relay your correspondence
SPF/DKIM
> select which members of a site can correspond with you
whitelists have been a thing in a while
> always know from which site a message originated
SPF
> can block anyone with whom you’ve made contact
blacklists have been a thing in a while
> may leave a site and never see traffic from it again
domain filter are a thing too. preemptive 'but you still receive emails' - no you can send a 550 early on and interrupt the transfer as soon as you get the envelope sender domain
> 2 To offer capabilities missing in traditional email, including
that's all client side stuff and you can do all of it as of today on top of email. first part of the protocol is to know which user sent you markdown before, so you can send markdown to them. for user that you don't know if they have a markdown clent, your own client send a multipart with markdown and the local markdown representation as html, so you have a two-in-one discovery/fallback mechanism
while the first one might be beneficial as you give more control from the sysad and into the user hand for point 1.5, the second part is a problem we already had and we already solved with the transition from text email to html email and it was never a protocol issue to begin with, so I don't understand why it has been rolled in here for more effort and little effective gains.
And there is no effective way to prevent phishing in SMTP/etc if the server accepts connections from the public Internet.
If you didn't, I suggest reading the protocol draft and "Why TMTP?"
I don’t understand why you need to completely (and naively) need to recreate something like SMTP.
This project tries to do too many things, even forms and charts. There’s no separation between layers.
Let's call it the Secure Mail Cooperative. In order to join the SMC, you need to:
- have an acceptable usage policy that means you will not allow any of your users to send spam (defined as...). Your first violation gets a warning. Your second violation gets you suspended from the SMC for a month. Third violation in a year disqualifies your organization from ever rejoining. Reset the count a year after a second violation.
- register the fingerprint of your SSL certs with the SMC, which will publish it in a DNS accept-list.
- add an SMC header to your SMC-bound email that indicates the address of your SMC postmaster, who is one or more people who can enforce the AUP on your side. The SMC postmaster address should never accept non-SMC email.
- agree that the SMC postmaster will be tested every so often and a lack of a response within 168 hours will be considered a violation, same as spam.
That's all off the top of my head, but it could reasonably work... for individuals and small to medium organizations. It requires too much attention for a Google or Microsoft to afford.
I think we may create a similar network basing on same old ESMTP, what we need is just to agree on rules and their enforcement. Also we need to secure inter-node communications.
In your cooperative, if two or more of the thousands of accounts in my org are compromised, the entire org loses email?
Not gonna happen, even if you tweak the rules to be more lenient.
Realistically we will always have spam. It can be reduced but, just like snail mail and all other forms of push communication, you will always get spam. Get over it.
Stage 1. Organizations would use it to create _internal_ messaging systems, for employees/members only. At that stage it does not replace e-mail, and both systems are used alongside it. If it is mandated to be used for internal communication, this solves the problem of getting "Open this immediately!!!" e-mail claiming to come from your boss, but being in fact from scammers. It also solves the problem of e-mail from your colleagues getting into spam folder.
Stage 2. If your clients, suppliers, etc. start to use mnm, you can add them to your mnm network, and stop using e-mail in communication with them. When you reach this stage, you can severely reduce using of e-mail for your organization, at this point perhaps the only people who need e-mail are marketing, support, and perhaps developers (but the latter only for maillists).
3. mnm gets a critical mass, where it makes sense for organizations and projects start to offer mnm as an option to contact them, and later to require them. At this point "general public" starts to use mnm.
4. When it reaches critical mass among general population, e-mail can start to be phases out.
Don't know how realistic is this, and some design decisions of the mnm team seem counter-productive, but to me it does not sound completely crazy.
In your roadmap example, steps 1 and 2 can be done right now by maintaining trusted network lists for SMTP, so that employees can't be spammed by unapproved senders. And it can enforce TLS between those trusted networks for privacy.
Meanwhile the customer-service people can have both guarded @internal.bigcorp.com and open @bigcorp.com accounts, the latter for public communication.
That's a pattern that's already in use and works on existing infrastructure. Any new protocol will have to offer overwhelming benefits.
More here: https://news.ycombinator.com/item?id=25804869#25807379
(I'm the author.)
The only effective solution is to #banSMTP - i.e. block it on public networks.
Occasionally I threaten to implement it in order to upset somebody.
- Is it even federated? It seems like not--it seems like it's proposing a protocol for organizations to use to run their own messaging service in-house?
- The proposal (as others have noted) seems to mix application features with message delivery. This doesn't seem useful.- Instead of using encryption, the proposal says that "To prevent theft of correspondence (in the event of a compromised account or server) the messaging service must store only messages that have not yet been delivered". This is...a really problematic design choice.
- The proposal suggests a bunch of reasonable application features which many email providers (at the MTA or MUA level) do already support (like "blocking anyone", "selecting [who] can correspond with you", etc). Email is fully compatible with these features!
To be blunt, this proposal doesn't seem like it was written with an eye to what's actually challenging about email. The fact that SMTP is not JSON is really not a significant problem; the focus of this proposal is just in the wrong place.To make this more constructive, I would suggest reading the IETF SMTP WG archives to understand the kinds of problems implementors and spec-authors face.
I'm frankly pessimistic about the prospect for a wholesale (non-incremental) replacement of SMTP, but even as a design exercise, starting with what real implementors struggle with makes sense.
I've been asked to create a doc describing the architecture and infrastructure of TMTP. That should clear up the Q's you and others have raised.
(I am the author.)
(I'm the author of mnm.)
Follow mnm! https://twitter.com/mnmnotmail
To address some comments...
The protocol[1] has two layers, altho that's not emphasized in the draft. The outer layer covers posting messages for recipients. The inner layer describes message contents, and isn't enforced by the server (see protocol #7 Post //datahead segment). You can do special-purpose apps with the outer layer without supporting the inner if you don't send messages to normal clients.
EDIT: The protocol will see many more revisions (some already planned), and real-world use, before it's proposed to a standards body.
This isn't a drop-in/swap-out replacement for email. It's a (far) better way of doing electronic correspondence. It will take some years to build the community and infrastructure necessary for TMTP to widely supplant SMTP. It's been suggested recently that I draft an architecture doc for TMTP[2], which will also discuss infrastructure.
Part of that infrastructure involves "marketplace" sites which verify members' real-life identities and let people make contact with folks outside their normal circles (e.g. work, school, community, hobbies/interests). Most professional organizations would run marketplace sites for their members.
I gather that the IETF has (repeatedly) stated that it is not interested in adjusting SMTP to solve "the spam problem". [3]
Re end-to-end encryption, that can be considered for the inner layer protocol. I don't rule it out, but it's not a priority at present.
If successful, "mnm" won't be the only implementation of TMTP. Maybe some other client will have a better name. (OTOH, Slack did well, and that's a pretty terrible name for a workplace tool ;-)
EDIT2: SMTP and related protocols have no effective defense against phishing. A large fraction of phishing attempts originate at authenticated domains, like Gmail.
---
[1] https://github.com/networkimprov/mnm/blob/master/Protocol.md
[2] https://github.com/networkimprov/mnm/issues/5
[3] https://www.rhyolite.com/anti-spam/you-might-be.html
Happy to chat any time. I’m Shokunin@mailscript.com
I loved the concept.
See also https://github.com/networkimprov/mnm/blob/master/codestyle.t...
My opinion is that the OP is premature. - I can't see how this scheme is supposed to interoperate with ESMTP etc. - I don't want charts and slidedecks running in my mail client - I'm not OK with relying on a browser as my mail client - The linked website is far too thin for a proposed email replacement; there are scores of dead email replacement proposals, and a new FUSSP has a steep hill to climb. Build a team, get feedback from your new colleagues, and say Hi again when you have a website that addresses objections.
Good luck!
An FAQ addressing the Q's posted here will be live on the site late on Jan 18th.
Gmail instantly was happy with my inbound emails. I got on a backscatter blacklist because I didn't immediately drop invalid email addresses at the gateway, but that will time out shortly. And just as I had settled in with the new server, I got to test the update function. This week the entire docker-mailserver project moved to a new repo name on Github, with a new release. A couple of the config files changed names, but nothing much in contents. A docker pull for the new image name, and my mail server was running the fresh release. Happy, happy, happy.
[0] https://github.com/docker-mailserver/docker-mailserver
What languages are acceptable then? You may need to provide a definition to prevent confusion.
Some of them went on to thrive, but not as email replacements: Slack for one.
It seems an ill defined approach to protocol, mixing idiot proof user interfaces with the former. The license??? Looks and feels like another pair of sneekers. The functionality is all surrounding us, the innards (protocol), are many that can comply with the white-paper.
A junk folder is only useful if you essentially never have to open it.
Otherwise you can just drop the mail you'd put there immediately on reception and not even store it.
It's not safe to block calls from unknown numbers if you have people that may depend on you.
Email is much less likely to be critical, but there are still occasions when you may be contacted with important information by addresses you didn't think to white list.
Apropos: Is anyone aware of an email client that groups mail by sender, like a chat client? That would make email far more usable for me, as addresses that send a lot of mail and addresses that send little mail would get the same amount of screenspace. Currently my company email is drowning in automated internal semi-spam.
Email is great. I can choose between umpteen providers or run my own mail server, it's a standard protocol with many different clients to suit one's needs, I can't get banned by a faceless FAANG corporation for no reason and with no recourse, I'm not locked into some walled garden and dependent on the benevolence of corporate overlords and I don't need to worry about some intern at Google suffering from NIH syndrome deciding to make completely unneeded "improvements" that negatively impact my UX.
Email is old but that doesn't mean it sucks.
Internal "semi-spam" is a social problem and needs a social solution. Changing protocols won't change the spam problem at your company.
They can make your life difficult though with their seemingly random decisions about what constitutes spam even when you jump through all the SPF/DKIM/DMARC/etc hoops.
Some problems with email, from a user perspective:
- The latency is too high for truly real-time communication
- There is no cryptographic verification of the sender's identity (this problem is also shared with telephony). This has lead to really harsh anti-spam measures that make it hard to self-host. Sender verification + client-side sender whitelists would solve spam for good. It also means grouping by sender gives a very false sense of security regarding identity continuity between messages
- There is no good support for groups or threads. Subject lines of type "Re: Re: Aw: Re: Sv: new proposal" is not an acceptable solution, as they look ugly and clients often disagree on how to parse and write them, leading to breakage of the thread
- Clients do not group by sender, group or thread, partly because these concepts do not actually exist in email (see above) and partly for social reasons
- Partly for historical reasons (it's just mail on a computer!) and partly for technical reasons (there is no sender, etc.) email is presented as huge letter-like affairs, leading to a felt need for all sorts of formalisms for every single message even if the messages are two minutes apart. Also email signatures (with logos?!) being attached to every message are just so wasteful both in terms of storage and in terms of screen space
If you want real-time communication you really ought to be using VOIP.
> There is no cryptographic verification of the sender's identity (this problem is also shared with telephony). This has lead to really harsh anti-spam measures that make it hard to self-host. Sender verification + client-side sender whitelists would solve spam for good. It also means grouping by sender gives a very false sense of security regarding identity continuity between messages
I agree that the crypto situation in email needs addressed. I don't think that the answer to this problem is "throw it away and start competing standard #1982374" though.
> There is no good support for groups or threads.
Mailing lists are groups. Threading actually works quite well with subject-line threading. Mailing lists have been doing this successfully for decades.
>Clients do not group by sender, group or thread,
Some do. Gmail does, for example.
>Partly for historical reasons (it's just mail on a computer!) and partly for technical reasons (there is no sender, etc.) email is presented as huge letter-like affairs, leading to a felt need for all sorts of formalisms for every single message even if the messages are two minutes apart. Also email signatures (with logos?!) being attached to every message are just so wasteful both in terms of storage and in terms of screen space
The formalisms thing isn't actually true, and all of these are social problems, not technical ones.
It's okay to just admit you don't like email, even if it's for purely subjective reasons.
> Some do. Gmail does, for example.
Thunderbird too.
For threading, look into the use of the References: email header.
This grouping complaint is a poor excuse for trying to junk existing email solutions; obviously the existing structures are capable of supporting that kind of grouping. If you want to launch a replacement for the existing structure, it's unhelpful if you are unfamiliar with the strengths and weaknesses of what you are proposing to replace.
The weaknesses of traditional email have been a subject of intense and detailed discussion for over 20 years. For a replacement to succeed, it will need to take account of the content of those discussions.
E-mail’s latency makes it so people write longer, thought out messages, instead of spamming very short messages. This makes for a different kind of communication, which is better for many things.
It also removes the expectation to respond really soon, and the sender doesn’t know if you’ve read the message.
I for one appreciate this property of email. The recipient doesn't neeed to be at their desk; their equipment doesn't have to be switched on; and they don't have to be awake at the same time as me.
I also prefer to type considered, thought-through messages (and I am unhappy that various messaging clients have hijacked email, so that my correspondents reply to me in a format that suggests they mistook my email for a text message).
Also, I have no messaging client on my laptop; and my fingers are too blunt to accurately type more than a few characters using the virtual keyboard on my mobile.
https://delta.chat