Mnm – an open source project to replace email and SMTP
mnmnotmail.org
mnmnotmail.org
This seems like a bad idea and goes against years and years of open systems design.
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.
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.
"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.
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.
Also addressed here: https://news.ycombinator.com/item?id=25804869#25807379
(I'm the author.)
Or watch on Twitter: https://twitter.com/mnmnotmail
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
Also addressed here: https://news.ycombinator.com/item?id=25804869#25807379
(I'm the author.)
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.
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.
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.
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.
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.
Why not a proxy through Signal as an option...?
Also addressed here: https://news.ycombinator.com/item?id=25804869#25807379
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
[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.)
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.
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.
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.
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.
E2ee messaging is used by billions. Without talking details, it’s hard to know what about the status quo we wish to improve.
However, these days this should be less of an issue in an ever connected world. Nobody uses UUCP or batched SMTP anymore :)
- 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.
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.)
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?"
John Doe <not.john.doe@example.com>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.
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.
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.
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.
More here: https://news.ycombinator.com/item?id=25804869#25807379
(I'm the author.)
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.
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?
- 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. :)
- 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 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
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.
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.
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.
Otherwise you can just drop the mail you'd put there immediately on reception and not even store it.
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.
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
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.
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.
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.