[HN Gopher] Mnm - an open source project to replace email and SMTP
___________________________________________________________________
Mnm - an open source project to replace email and SMTP
Author : skinkestek
Score : 116 points
Date : 2021-01-16 19:48 UTC (3 hours ago)
(HTM) web link (mnmnotmail.org)
(TXT) w3m dump (mnmnotmail.org)
| Whiteshadow12 wrote:
| 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.
| juniperplant wrote:
| 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.
| based2 wrote:
| https://github.com/networkimprov/mnm/issues/5 create TMTP
| architecture doc
| FiveNinjas wrote:
| 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.
| als0 wrote:
| 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.
| nobody9999 wrote:
| >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
|
| [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.
| xwdv wrote:
| I wonder if people in 10 years from now will come back here to
| see the beginning of the project that replaced email.
| knorker wrote:
| Just like with Wave.
| gm wrote:
| 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.
| greatgirl wrote:
| 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.
| gm wrote:
| 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.
| samstave wrote:
| also, is SLS or E2EE an option?
|
| Why not a proxy through Signal as an option...?
| user3939382 wrote:
| 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.
| throwawaysea wrote:
| This is already the case for encrypted transport of email and
| is how email has been evolving all this time.
| livre wrote:
| 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.
| throwawaysea wrote:
| 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.
| superkuh wrote:
| 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.
| jagger27 wrote:
| Go isn't a meme language.
| tacon wrote:
| 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.
|
| [0] https://github.com/docker-mailserver/docker-mailserver
| gm wrote:
| Why would a market care about the language a product's written
| at? Maybe only programmers, and anal retentive ones at that.
| bee_rider wrote:
| 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.
| pozzen wrote:
| Like Maddy? https://foxcpp.dev/maddy/
| superkuh wrote:
| Yes. Exactly like Maddy except not in Go.
| pmlnr wrote:
| Don't try to "replace" email, ever. Build, name is a X, just not
| as "to replace email", because by doing that, it's DoA.
| ajsnigrutin wrote:
| 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.
| kyrra wrote:
| 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.
|
| 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
| transistor-man wrote:
| Just curious, how do you pronounce this, as in how would I
| recommend this to some one verbally?
| young_unixer wrote:
| I'm sorry, but with such an awkward name they won't convince many
| people.
| gm wrote:
| LOL, yeah, recursive project names stopped being interesting to
| me after "GNU's Not Unix"
| umvi wrote:
| 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 wrote:
| Just to make the reference completely obvious, parent is
| referring to the candy named _M &M's_:
|
| https://en.wikipedia.org/wiki/M%26M's
| ccleve wrote:
| Marshall Mathers, Eminem, had the same idea, but did it
| better.
| slyall wrote:
| 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.
| netik wrote:
| 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.
| petre wrote:
| The junk folder should be the default deliveey folder, not the
| inbox. Anything not moved from it for several months should be
| erased.
| tsimionescu wrote:
| 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.
| umvi wrote:
| Think of it like cellphones. If you aren't in the contact
| list you are blocked by default.
| beowulfey wrote:
| There was a time not that long ago when we didn't have
| caller ID and we actually answered ALL our phone calls
| tsimionescu wrote:
| 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.
| FiveNinjas wrote:
| 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.
| userbinator wrote:
| 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.
| [deleted]
| xaduha wrote:
| 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.
| flemhans wrote:
| Would popular rapper Eminem claim trademark infringement?
| reaperducer wrote:
| Not any more than candy maker M&M Mars would.
| StreamBright wrote:
| 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.
|
| https://en.wikipedia.org/wiki/Cost-based_anti-spam_systems
| TedDoesntTalk wrote:
| How can this reach critical mass when people are already using
| email for a similar purpose?
| mdpttt wrote:
| 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 wrote:
| 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 wrote:
| 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.
| tormeh wrote:
| 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.
| beagle3 wrote:
| Thunderbird and Outlook both group by sender, and have for more
| than 20 years.
| BubuIIC wrote:
| I think delta chat does exactly this: https://delta.chat/
| (email as chat)
| tormeh wrote:
| Thanks! This looks great!
| RcrdBrt wrote:
| 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
|
| https://delta.chat
| tormeh wrote:
| Thanks! This looks great!
| na85 wrote:
| >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.
| tormeh wrote:
| All the benefits you're listing are benefits that any
| federated protocol, for example Matrix, has. Completely
| orthogonal to email itself.
___________________________________________________________________
(page generated 2021-01-16 23:00 UTC)