16 ms·
Mnm – an open source project to replace email and SMTP
- TedDoesntTalk 6y agoHow can this reach critical mass when people are already using email for a similar purpose?
- mdpttt 6y agoThis 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 6y agoIETF / 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 6y agoTrue, 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_ 6y agoYou 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.
- TedDoesntTalk 6y agoi 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 6y agoThis 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.
- ruslan 6y agoFidonet 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.
- IlliOnato 6y agoIf 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.
- networkimprov 6y agoExcellent roadmap! \o/ More here: https://news.ycombinator.com/item?id=25804869#25807379 https://news.ycombinator.com/item?id=25804869#25807379 (I'm the author.)
- dingaling 6y agoBut 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.
- networkimprov 6y agoEmail is in deep trouble, due to the cybercrime crisis, in which SMTP plays a leading role, enabling phishing. The only effective solution is to #banSMTP - i.e. block it on public networks.
- based2 6y agohttps://github.com/networkimprov/mnm/issues/5 https://github.com/networkimprov/mnm/issues/5 create TMTP architecture doc
- xwdv 6y agoI wonder if people in 10 years from now will come back here to see the beginning of the project that replaced email.
- gm 6y agoThe 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.
- greatgirl 6y agoMost 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.
- knorker 6y agoJust like with Wave.
- reitanqild 6y agoThis one has the benefit of not being owned/backed by a company that must be one of the biggest quitters of all time ;-)
- gm 6y agoIt 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 6y agoThe 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.
- throwawaysea 6y agoThis is already the case for encrypted transport of email and is how email has been evolving all this time.
- livre 6y agoAnother 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 6y agoThat 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.
- superkuh 6y agoIt'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.
- pozzen 6y agoLike Maddy? https://foxcpp.dev/maddy/ https://foxcpp.dev/maddy/
- superkuh 6y agoYes. Exactly like Maddy except not in Go.
- hactually 6y agoSo non meme language and not Go? What languages are acceptable then? You may need to provide a definition to prevent confusion.
- superkuh 6y agoI mean languages that have been in existence for more than a decade and aren't controlled by a single corporation.
- t0astbread 6y agoGo 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 6y agoDeprecate it.
- 6y ago
- young_unixer 6y agoI'm sorry, but with such an awkward name they won't convince many people.
- gm 6y agoLOL, yeah, recursive project names stopped being interesting to me after "GNU's Not Unix"
- umvi 6y agoAnd 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...
- networkimprov 6y agomnm = mnm is not mail Also addressed here: https://news.ycombinator.com/item?id=25804869#25807379 https://news.ycombinator.com/item?id=25804869#25807379
- anaganisk 6y agoMay be thats we said about, rediff, google, duckduckgo, WhatsApp, tumblr, and others.
- petre 6y agoThe junk folder should be the default deliveey folder, not the inbox. Anything not moved from it for several months should be erased.
- tsimionescu 6y agoSo 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.
- umvi 6y agoThink of it like cellphones. If you aren't in the contact list you are blocked by default.
- beowulfey 6y agoThere was a time not that long ago when we didn’t have caller ID and we actually answered ALL our phone calls
- tsimionescu 6y agoThat'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.
- FiveNinjas 6y agoyou 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.
- hyakosm 6y agoIt'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.
- Whiteshadow12 6y agoDropbox 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 6y agoWell, I instantly knew Dropbox would be a hit. At least for me
- juniperplant 6y agoKind of disappointed in not seeing end-to-end encryption being mentioned? I thought it was perceived as one of the fundamental flaws of email.
- networkimprov 6y agoAddressed here: https://news.ycombinator.com/item?id=25804869#25807379 https://news.ycombinator.com/item?id=25804869#25807379
- Aachen 6y agoNo 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 6y ago...not to mention the leaking of metadata.
- FiveNinjas 6y agotook 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 6y 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. [0] https://github.com/networkimprov/mnm/issues/5 https://github.com/networkimprov/mnm/issues/5 [1] https://www.ietf.org https://www.ietf.org [2] https://mnmnotmail.org/rationale.html https://mnmnotmail.org/rationale.html [3] https://tools.ietf.org/rfc/rfc5321.txt https://tools.ietf.org/rfc/rfc5321.txt [4] https://www.ietf.org/how/wgs/ https://www.ietf.org/how/wgs/ Edit: Fixed links.
- throwawaysea 6y agoEmail 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.
- pmlnr 6y agoDon'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 6y agoYup! 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 6y agoIt 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.
- zapzupnz 6y agoYes, but the point is, don’t sell it that way.
- franga2000 6y agoThe 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.
- ddingus 6y agoNone of what you wrote speaks to not doing what is needed.
- kyrra 6y agoThe (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. https://www.reddit.com/r/golang/comments/kxe5bi/mnm_an_open_source_project_to_replace_smtpemail/ 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 https://github.com/networkimprov/mnm/blob/master/Protocol.md
- networkimprov 6y agoI 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 :)
- xaduha 6y agoAny 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.
- tormeh 6y agoEmail 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.
- beagle3 6y agoThunderbird and Outlook both group by sender, and have for more than 20 years.
- BubuIIC 6y agoI think delta chat does exactly this: https://delta.chat/ https://delta.chat/ (email as chat)
- tormeh 6y agoThanks! This looks great!
- RcrdBrt 6y agoDeltachat 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 https://delta.chat https://delta.chat
- tormeh 6y agoThanks! This looks great!
- na85 6y 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.
- slyall 6y agoThis 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 6y agoI 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 6y agoThere would be "marketplace" sites to connect with people. More here: https://news.ycombinator.com/item?id=25804869#25807379 https://news.ycombinator.com/item?id=25804869#25807379 (I'm the author.)
- StreamBright 6y agoPoint 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. https://en.wikipedia.org/wiki/Cost-based_anti-spam_systems https://en.wikipedia.org/wiki/Cost-based_anti-spam_systems
- networkimprov 6y agoThe new user experience aspects are largely constructed with markdown extensions. 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 https://news.ycombinator.com/item?id=25804869#25807379 (I'm the author :)
- transistor-man 6y agoJust curious, how do you pronounce this, as in how would I recommend this to some one verbally?
- networkimprov 6y agoem-in-em, like the rapper :-)
- netik 6y agoI 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.
- grok22 6y agoNot 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 6y agoYou have to have a killer feature for something to get adopted.
- GekkePrutser 6y agoThe 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.
- EricMausler 6y agoWhat are your thoughts on protonmail?
- thayne 6y agoNot 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.
- flemhans 6y agoWould popular rapper Eminem claim trademark infringement?
- reaperducer 6y agoNot any more than candy maker M&M Mars would.
- m___ 6y agoIs 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 6y agoYeah, 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.
- alisausa 6y agoHello
- alisausa 6y agoTop burny busty chicks only on this site! Follow the link, and you won’t be sorry! - https://adultlove.life https://adultlove.life
- GekkePrutser 6y agoHmmmm... 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.
- throwawaysea 6y ago> The lack of E2E encryption and sender authentication makes it completely useless these days. Both SPF and DMARC provide sender authentication.
- GekkePrutser 6y agoWell 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 6y ago> Well one issue with them is that they're totally optional. So is every proposed replacement for SMTP.
- 0xbadcafebee 6y agoThey lost me at "weird JSON header followed possibly by arbitrary 8 bit data". The rest of the protocol is kind of crazy too.
- GNU_James 6y agoI'll stick to regular email till I'm dead. Thanks.
- networkimprov 6y agoA killer phish will get you sooner than later :-)
- denton-scratch 6y agoPhishing 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 6y agoThe 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.
- onebot 6y agoThis was what Lotus Notes was to be. Maybe not open source, but a reach communications platform.
- networkimprov 6y agoAuthor here. Sorry to be late to the party. AMA. Follow mnm! https://twitter.com/mnmnotmail 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 https://github.com/networkimprov/mnm/blob/master/Protocol.md [2] https://github.com/networkimprov/mnm/issues/5 https://github.com/networkimprov/mnm/issues/5 [3] https://www.rhyolite.com/anti-spam/you-might-be.html https://www.rhyolite.com/anti-spam/you-might-be.html
- leshokunin 6y agoInteresting idea! I think we could use Mailscript to bridge Mnm with email. Would you be interested?
- networkimprov 6y ago
- de6u99er 6y agoDoes anyone remember Google Wave (now Apache wave)? I loved the concept.
- brian_herman 6y agoI would rather use something like https://jmap.io/ https://jmap.io/
- networkimprov 6y agoJMAP is an extension of the email protocol stack; it's fundamentally different than TMTP. (I'm the author of mnm.)
- wowxp 6y agoThe source code is totally unreadable.
- networkimprov 6y agoPlease 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. See also https://github.com/networkimprov/mnm/blob/master/codestyle.txt https://github.com/networkimprov/mnm/blob/master/codestyle.t...
- 0df8dkdf 6y 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 6y agoI'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.)
- LockAndLol 6y agoI 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.
- inopinatus 6y agoThose who have not read https://craphound.com/spamsolutions.txt https://craphound.com/spamsolutions.txt are doomed to repeat it.
- iovrthoughtthis 6y agoI'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 6y agoThere'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.
- doctorfoo 6y agoFor password reset?
- iovrthoughtthis 6y 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.
- 6y ago
- avereveard 6y agoI 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 6y agoYou 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 6y agoyou can check that the envelop and message sender header match at the mx level and let spf handle the rest
- networkimprov 6y agoThere is no authentication of the John Doe part of John Doe <not.john.doe@example.com>
- alisaus2 6y agoTop burny busty chicks only on this site! Follow the link, and you won’t be sorry! - https://adultlove.life https://adultlove.life
- retpirato 6y agoThis looks a lot like instant messaging to me. Maybe glorified IM, but still IM.
- md_ 6y agoAs 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 6y agoTMTP 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.)
- otabdeveloper4 6y agoThe target audience of this uses Microsoft Exchange, not "email and SMTP" anyways.
- Aachen 6y agoSo 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 6y agoSee link to "simple protocol" in first sentence of homepage, and link "Why TMTP?" after goals.
- nickik 6y agoMatrix 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?
- silasdb 6y agoThere 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. [1] https://jmap.io https://jmap.io
- networkimprov 6y agoThank you! An FAQ is in progress; it will address the questions you and others posed. I'll post a link under the top comment here when it's ready. See also https://news.ycombinator.com/item?id=25804869#25807379 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 https://twitter.com/mnmnotmail
- retpirato 6y agoSome 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.