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?
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.
You can solve a bunch of SMTP problems by organizing people.
Let's call it the Secure Mail Cooperative. In order to join the SMC, you need to:
- have an acceptable usage policy that means you will not allow any of your users to send spam (defined as...). Your first violation gets a warning. Your second violation gets you suspended from the SMC for a month. Third violation in a year disqualifies your organization from ever rejoining. Reset the count a year after a second violation.
- register the fingerprint of your SSL certs with the SMC, which will publish it in a DNS accept-list.
- add an SMC header to your SMC-bound email that indicates the address of your SMC postmaster, who is one or more people who can enforce the AUP on your side. The SMC postmaster address should never accept non-SMC email.
- agree that the SMC postmaster will be tested every so often and a lack of a response within 168 hours will be considered a violation, same as spam.
That's all off the top of my head, but it could reasonably work... for individuals and small to medium organizations. It requires too much attention for a Google or Microsoft to afford.
i wouldn't have my organization join this cooperative. Why? Because accounts get compromised and spam gets sent. It just does, even with 2FA and NFC dongles and public/private keys.
In your cooperative, if two or more of the thousands of accounts in my org are compromised, the entire org loses email?
Not gonna happen, even if you tweak the rules to be more lenient.
Realistically we will always have spam. It can be reduced but, just like snail mail and all other forms of push communication, you will always get spam. Get over it.
This is called responsibility. Lack of respobsibility brought us to the point where noone cares about security seriously. Yes, we talk much about it, but in reality we don't give a damn about it because possible damage is usually inappreciable.
Fidonet operated exactly the way you describe. I recall in 90th I used to run quite a large Fidonet node. I was responsible for my points' (users) behaviour - when someone violated rules by misbehaving in an echo conference it effected me as a boss node in first place, I had to execute the ban and brainwash negligent user. What's more, I had to introduce new and old users to fidonet policy and its updates regularily to make sure they understand the rules. This all worked pretty well and was widely accepted. Fidonet was incredibly popular in 90th.
I think we may create a similar network basing on same old ESMTP, what we need is just to agree on rules and their enforcement. Also we need to secure inter-node communications.
If I understand them correctly, they have in mind the following:
Stage 1. Organizations would use it to create _internal_ messaging systems, for employees/members only.
At that stage it does not replace e-mail, and both systems are used alongside it.
If it is mandated to be used for internal communication,
this solves the problem of getting "Open this immediately!!!" e-mail claiming to come from your boss, but being in fact from scammers.
It also solves the problem of e-mail from your colleagues getting into spam folder.
Stage 2. If your clients, suppliers, etc. start to use mnm, you can add them to your mnm network, and stop using e-mail in communication with them. When you reach this stage, you can severely reduce using of e-mail for your organization, at this point perhaps the only people who need e-mail are marketing, support, and perhaps developers (but the latter only for maillists).
3. mnm gets a critical mass, where it makes sense for organizations and projects start to offer mnm as an option to contact them, and later to require them. At this point "general public" starts to use mnm.
4. When it reaches critical mass among general population, e-mail can start to be phases out.
Don't know how realistic is this, and some design decisions of the mnm team seem counter-productive, but to me it does not sound completely crazy.
But all that complexity of migration, when similar results can be achieved today using SMTP trust-lists and separate accounts.
In your roadmap example, steps 1 and 2 can be done right now by maintaining trusted network lists for SMTP, so that employees can't be spammed by unapproved senders. And it can enforce TLS between those trusted networks for privacy.
Meanwhile the customer-service people can have both guarded @internal.bigcorp.com and open @bigcorp.com accounts, the latter for public communication.
That's a pattern that's already in use and works on existing infrastructure. Any new protocol will have to offer overwhelming benefits.
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.
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.
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.
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.
That works pretty well for IPv6, doesn‘t it (actually, it does not)?
The problem with that approach is that as long as 0.01% still uses the old protocol, you can‘t get rid of it. And then you have a bag with the old and new protocol and maybe after 20 years you realize it‘s going to take another X years until you have at least some relevant adoption, as demonstrated with IPv6.
If one is ever going to „replace“ email it happens on top of the existing protocols and not as a replacement.
You make a great point. A very popular protocol or standard is never fully replaced. Either it continues existing next to the new thing (IPv4/IPv6) or gets an update while still having to deal with backwards compat (HTML, CSS). Whatever the case is we'll still be dealing with email in 20-30 years from now.
Na. We’re talking about adding a protocol to a list of a handful which people use regularly. What you just said sounds like something I would have heard in the 90s about using email for legitimate purposes. Why do we need email when we have fax? (Granted fax still exists, but it’s no email killer.)
This sort of thing could be deployed by people in addition to the other services. For a while and perhaps a long while it’ll be fringe. But if there’s enough utility to it then it may just catch on.
There are two key requirements for anything that would actually supplant email:
1. Call the protocol "Email 2"
2. Build something that actually justifies the name
I'm only half joking; the messaging around the protocol is almost as important as the protocol itself. iMessage is a good example of how to expose something like "Email 2" to the end user: as a seamless upgrade, indicated by a subtle UI element, when a client happens to negotiate the upgraded protocol with the server.
Enabling incremental upgrades to infrastructure is critical, but strict backward-compatibility isn't necessarily so. As long as the architecture of the new protocol makes falling back to IMAP/SMTP straightforward when an upgraded client or server isn't available, Email 2 doesn't have to be able to talk directly to legacy.
There's certainly a chicken-and-egg problem in driving enough server adoption to get client vendors to add support while driving enough client adoption to get server operators on board, but there's probably a sweet spot between making a clean enough break with legacy tech that it's more straightforward to implement, while making it conceptually similar enough that it can still plug into the same patterns.
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.
Go has existed for 11 years. It's probably safe to say that it won't die off soon. As for the control part: What could Google do to Go that would affect you as a user of some software written in it?
If a programming language has exited for 11 years I'd be more worried about the author of the software dropping that than the author of the language deprecating the language. It's the Lindy effect.
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.
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.
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...
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.
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.
It's the difference between a social network decicated to exchange in a bubble and a truly universal communication service like post, phone system or email where anyone can reach anyone without subscribe to same/any service, without being "friend" or trusted.
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.
On the contrary, Junk folder is only useful if you go there regularly and check that non-junk mail didn't get there. Especially for services that have too much false positives, like gmail.
Otherwise you can just drop the mail you'd put there immediately on reception and not even store it.
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.
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.
>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.
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.
If widely adopted, most TMTP clients would have concurrent logins to many servers at different sites. Your traffic isn't routed via a middleman like Facebook which everyone needs to join, and which scans your content for advertising purposes.
I've implemented both client and server, so there's the basis for a "reference implementation".
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.
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.
The fact that it has problems is entirely tangential to the fact that it does what's needed. What's needed is "I send a thing to a person and it soon-ish shows up on their end", with the bonus of knowing that someone would have to expend significant effort to intercept it. This has been true since the invention of writing and very few scenarios needed more. Anything on top of that (spam rejection, steong verification and encryption, etc.) is nice to have, but clearly not critical, because otherwise we still wouldn't all be relying on paper mail, email and sms for even the most critical of things.
So yes, we really do need something better than email (and we have plenty of options), but it doesn't have to (nor will it any time soon) replace email.
We do not need new email. We need a way to authorize messages sent and also a way to enburden senders for the content they send. In pre-internet era UUCP was widely used to deliver messages, UUCP providers used to charged their customers for each message they sent which made spam broadcasting quite costly. What I see is a kind of distributed message transportation system that takes currency from sender and shares a fraction of it with recipient. I.e. sender always pays for sending their stuff, recipient gets paid for interruption. SMS messaging is very close to this.
Real transport level security will be possible with MTA-STS (rfc8461). Use DNSSEC, enforce TLS, and verify server certificates. Also I haven't had much trouble with spam recently (spam filter works fine).
The (I believe) author of this posted it on the golang subreddit a few days ago. It looks like he's very open to contributions if you're willing to help.
I welcome constructive feedback and contributions!
I have a "Yes, and ..." attitude to input and community. (I know the pain of being part of an open source community that doesn't.)
(Yes-and is a comedy/theatrical improv technique; always embrace what the previous speaker said, and build on that. Tho admittedly, you can't run an open source project in an entirely improvisational manner :)
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.
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.
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.
And the problems you listed with email aren't actually problems with the technology so much as problems with the way people at your company (and others) misuse the technology. They're completely orthogonal to email itself.
What exactly does it need to do better threading ? Today a client can write anything they want in the References: and In-Reply-To: headers, and the server doesn't verify that it's valid. Would that be enough for you ?
I only mentioned one problem with the clients, and an abstract complaint about doing one electronic communication but pretending it's physical.
Some problems with email, from a user perspective:
- The latency is too high for truly real-time communication
- There is no cryptographic verification of the sender's identity (this problem is also shared with telephony). This has lead to really harsh anti-spam measures that make it hard to self-host. Sender verification + client-side sender whitelists would solve spam for good. It also means grouping by sender gives a very false sense of security regarding identity continuity between messages
- There is no good support for groups or threads. Subject lines of type "Re: Re: Aw: Re: Sv: new proposal" is not an acceptable solution, as they look ugly and clients often disagree on how to parse and write them, leading to breakage of the thread
- Clients do not group by sender, group or thread, partly because these concepts do not actually exist in email (see above) and partly for social reasons
- Partly for historical reasons (it's just mail on a computer!) and partly for technical reasons (there is no sender, etc.) email is presented as huge letter-like affairs, leading to a felt need for all sorts of formalisms for every single message even if the messages are two minutes apart. Also email signatures (with logos?!) being attached to every message are just so wasteful both in terms of storage and in terms of screen space
Some of this problems are (in my opinion) actually advantages.
E-mail’s latency makes it so people write longer, thought out messages, instead of spamming very short messages. This makes for a different kind of communication, which is better for many things.
It also removes the expectation to respond really soon, and the sender doesn’t know if you’ve read the message.
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.
> The latency is too high for truly real-time communication
If you want real-time communication you really ought to be using VOIP.
> There is no cryptographic verification of the sender's identity (this problem is also shared with telephony). This has lead to really harsh anti-spam measures that make it hard to self-host. Sender verification + client-side sender whitelists would solve spam for good. It also means grouping by sender gives a very false sense of security regarding identity continuity between messages
I agree that the crypto situation in email needs addressed. I don't think that the answer to this problem is "throw it away and start competing standard #1982374" though.
> There is no good support for groups or threads.
Mailing lists are groups. Threading actually works quite well with subject-line threading. Mailing lists have been doing this successfully for decades.
>Clients do not group by sender, group or thread,
Some do. Gmail does, for example.
>Partly for historical reasons (it's just mail on a computer!) and partly for technical reasons (there is no sender, etc.) email is presented as huge letter-like affairs, leading to a felt need for all sorts of formalisms for every single message even if the messages are two minutes apart. Also email signatures (with logos?!) being attached to every message are just so wasteful both in terms of storage and in terms of screen space
The formalisms thing isn't actually true, and all of these are social problems, not technical ones.
It's okay to just admit you don't like email, even if it's for purely subjective reasons.
>>Clients do not group by sender, group or thread,
> Some do. Gmail does, for example.
Thunderbird too.
For threading, look into the use of the References: email header.
This grouping complaint is a poor excuse for trying to junk existing email solutions; obviously the existing structures are capable of supporting that kind of grouping. If you want to launch a replacement for the existing structure, it's unhelpful if you are unfamiliar with the strengths and weaknesses of what you are proposing to replace.
The weaknesses of traditional email have been a subject of intense and detailed discussion for over 20 years. For a replacement to succeed, it will need to take account of the content of those discussions.
> I can't get banned by a faceless FAANG corporation for no reason
They can make your life difficult though with their seemingly random decisions about what constitutes spam even when you jump through all the SPF/DKIM/DMARC/etc hoops.
What I mean is they can't lock me out of my emails and contacts without recourse because (unless I use gmail or similar) my contacts are stored on my local device, and potentially so is my mail.
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.
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.
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.
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.
Not sure why that is a problem given the problem domain -- all those high-level features is what will help people consider adopting this. But email can only improve if you fix the whole eco-system including the server side -- which then means also dealing with the protocol. The modification to the protocol will probably help with all those "high-level" features.
The killer feature of a new email protocol will be that it's not SMTP.
It should have sender authentication. E2E encryption that's easy and works by default. Those would be more than enough killer features, SMTP is just too broken and all the workarounds we have in place like DKIM, SPF, Spam ratings etc etc don't make up for it. We still have spam, important mails still end up in our junk boxes, and nobody trusts it enough anymore to put important content in emails. The war has long been lost.
Not the parent, but protonmail is still just more hacking to work around a broken system. It is a valient effort, but to really fix email the whole thing needs to be replaced.
I'm with thayne above on this one.. Protonmail just offers secure storage on their system but they still see the external incoming emails unless they're PGP encrypted. They make that easy, but still. PGP didn't take off in 30 years, it's just too complex. Tools can help that but the weak point is its key management.
As far as I know, and I could be wrong, ProtonMail wraps around pgp inbox encryption. Many providers have exactly this service already.
The difference seems to be that ProtonMail don’t allow you to use normal imap and your own client with pgp, but force you to use their client. This is probably a trade-off made to protect users against them selves in one way (disabling encryption for grandpa) and hiding the non tech-savvy from all the technical details.
Again, many assumptions here.
So, to me, mentioning proton here doesn’t make sense as the underlying tech: smtp & pgp have existed and been industry standard for a long time. So there is not issue of adoption.
Exactly. There's no replacing email with something that's closed membership / invite-only etc. The whole point of e-mail is its your address where someone can initiate a contact, like phone number. You can choose to filter it etc. And you can choose to get attested emails which you can trust more etc. But fundamental nature is it is open for anyone to contact you. If you lose that, and build a custom new protocol, you are just building another closed wall messaging application.
Agree with everything you've said. Additionally, consistent rendering. If you've ever tried to send an email campaign and had to support all the old (and sometimes surprisingly new) Outlook clients and Lotus notes, you'll know just how painful that is.
Email must be:
* Secure and encrypted;
* Have proven identity;
* Have easy to fabricate and predictable rendering;
I feel like the ability to have forms and charts is very nice, but adds a lot of complexity, especially from a security point of view. I'd be looking at this kind of "application level" functionally being a layer added optionally on top, not being in the core protocol.
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.
Don't count your chickens just yet, the jury is still out on this one.
If history has any say on this, communication solution based on proprietary technology will meet their death sooner rather than later. How many network protocols have been invented before and after TCP/IP? I know we are talking about messaging now, but messaging is just another overlay network over TCP/IP.
I'd envision in the future that the open messaging systems will be more pervasive. It will be based on local-first software and probably based on the automerge capabilities. The automerge community is focusing on collaborative editing at the moment but could someone please work on automerge solution for messaging system? This can be an excellent new paradigm for open world of messaging. I am seriously tired of people asking me to install the proprietary software of WhatsApp, Line, Wechat, etc.
There has to be a definition of acceptable message formats for standard clients. I suppose that could be a separate protocol, but for now, there's one protocol draft.
It makes me smile to hear that someone expects to read a perfect document on a perfect product which they understand perfectly; even tho the product is a preview, the document is a draft, and they only read it once.
There was nothing imperfect in what I read. It was perfectly clear what features this product considers in its scope. I just didn't agree that those feature went well together with the stated goal of replacing current email systems.
Is there anything here that ssh protocol and derivatives, sshfs, scp, sftp, and then VPNs cannot do,
It seems an ill defined approach to protocol, mixing idiot proof user interfaces with the former. The license??? Looks and feels like another pair of sneekers. The functionality is all surrounding us, the innards (protocol), are many that can comply with the white-paper.
Yeah, please do come back with your comment, when a regular babushka can ssh into her server in AWS, and run all the hell you mentioned. I dont understand people who think every thing is designed with developers in mind. Not everyone is a GNU GPL C++ cruching desktop junkie.
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.
Well one issue with them is that they're totally optional. The protocol should have this built in. The way it is now is a kludge. Even mails from big companies still end up in my O365 junk box. I didn't check them in detail but something failed there. At the same time the spammers are actually pretty good at avoiding spam filters.
Also, they don't really provide sender authentication. They provide sending domain->sending server verification. If you have a business that uses the same email provider, you will be able to fake sender auth if you can convince the server to send it. This is why it's a kludge.
If we'd require emails to be signed by default this issue wouldn't be present.
What I really miss these days is public protocol innovation. In the old days if a protocol stopped meeting the needs, people would go back to the drawing board and publish and agree a new RFC. These days we just tack on workarounds to old protocols without fixing the root issues, or we switch to closed alternatives (like what has happened to IM) which is even worse.
The problem is that s/mime and gpg are too complex for end users. Especially the key management, the encryption itself is not the issue.
s/mime is expensive in terms of certificates and difficult to set up. GPG's trust chain based on key signing parties has never taken off outside the crypto geek community (Don't get me wrong, I'm one too!)
Perhaps a "let's encrypt" approach to s/mime could work though. I could see that happening. It would indeed solve a lot of issues.
Corporate environments generally have an easier time with s/mime, and IIUC this app is focused on corporate environments.
GPG is nice (I like a lot and have used it for a very long time), but it's certainly niche.
That said, I included s/mime and gpg to illustrate that end to end encryption is not only possible, but that mature, functional tools are available in an SMTP+extensions environment.
It would be interesting to know how mnm/TMTP does encryption. I'd assume it uses TLS for transport. As for endpoint and server storage encryption (assuming it does that at all), you'd hope they'd use some sort of asymmetric key encryption, which raises the same issues as s/mime and gpg.
I thought SPF was more "this email is allowed to come from these hosts" authentication which tells you nothing about the sender (to me, at least) other than "they used an approved host"?
>The lack of E2E encryption and sender authentication makes it completely useless these days.
The elephant in the room here is that there is nothing wrong with, say, PGP. Any meaningful approach using public key crytography and crytopgraphic signatures to achieve confidentiality and authentication over SMTP ends up with the conclusion that you could of just used the OpenPGP protocol.
I think the reason we like to think that there is some new method available that will finally make things work is the hope there is a purely technological solution available. After 30 years of failing to come up with such a solution it is clear that there is no such solution possible in isolation.
PGP is incompatible with both forward secrecy and metadata secrecy.
If you only want to keep your message body confidential (or authenticated), PGP is reasonable. But it provides a strictly lesser degree of secrecy than modern e2ee messaging applications.
In fact, depending on your threat model, modern SMTP-TLS (which is not e2ee, but does provide some metadata confidentiality and forward secrecy) may in fact be an improvement over PGP.
Forward secrecy isn't really an issue with email. There are few that would be willing to delete their emails after reading them. Keeping old messages around for all practical purposes negates the value of forward secrecy. Most people like to keep their old messages in an easily accessible form so forward secrecy is not very important for messaging in general.
>...metadata secrecy...
This is not a huge problem with a medium like email where you can be more or less anonymous. Contrast with things like instant messengers that insist on a phone number.
>But it provides a strictly lesser degree of secrecy than modern e2ee messaging applications.
Most of those applications take the form of instant messengers. Since such things by necessity have to leave the private key material exposed all the time they are generally less secure than something like encrypted email where that key material can be kept very locked down.
>...modern SMTP-TLS (which is not e2ee, but does provide some metadata confidentiality and forward secrecy) may in fact be an improvement over PGP.
True enough. SMTP-TLS does provide even more security to the encrypted email user. Most importantly, it prevents passive listeners from detecting that an email was encrypted and thus worthy of further interest.
I can't help but point out that this sort of discussion is an excellent example of the state of denial that exists with respect to end to end encrypted messaging these days. Rather than addressing the broader overall issues we are quibbling about obscure technical details.
E2E with forward secrecy was not possible in the past because email was an offline thing. You can't do PFS without a live connection between the endpoints.
However, these days this should be less of an issue in an ever connected world. Nobody uses UUCP or batched SMTP anymore :)
Another thing is that e2ee breaks a number of useful features of e-mail:
- The ability to painlessly access your mail from a number of different clients, ranging from fully-featured desktop clients to smartphone apps to webmail.
- Server-side filtering (both spam and in general)
- Server-side searching (mandatory for webmail and depending on how big your mail archive is, still rather useful for smartphones, too)
210 comments
[ 4.3 ms ] story [ 448 ms ] threadI 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.
Some of them went on to thrive, but not as email replacements: Slack for one.
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
What languages are acceptable then? You may need to provide a definition to prevent confusion.
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
https://en.wikipedia.org/wiki/M%26M's
Also addressed here: https://news.ycombinator.com/item?id=25804869#25807379
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.
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.
I was looking for protocol descriptions in how this could work. Author said people would be more impressed by code - but I think a protocol spec along with a reference implementation would be useful.
So... what in this proposal isn't fulfilled by a private walled message platform such as Whatsapp, or Signal, or Facebook Messenger? Nothing here needs this to be 'email'.
And if you're into adding trusted layers with revocation to email, well we have DKIM, client certs, encryption. You can do the 'trusted' enforceability at the application level over the untrusted SMTP network level.
All in, probably DOA as an idea.
I went and looked for a protocol spec as well. When I didn't see anything concrete on the site in the submission title, I poked around the comments a bit more and found a link to the Github issue[0] requesting detail with respect to the architecture of the TMTP protocol.
I further poked around in the appropriate places[1] but found nothing remotely related.
The protocol spec[2], while useful in defining the control mechanisms and message formats is vague or silent when it comes to a variety (too many to list completely here) of functional, operational and implementation issues.
A comparison of TMTP's spec with SMTP[3] ("the protocol at the root of all these problems"[2] with messaging), is quite illuminating.
While SMTP by itself lacks a variety of features, it provides a robust, interoperable architecture that's broadly supported and has been augmented repeatedly by other protocols (e.g., MIME, DMARC/DKIM, SMTP-AUTH, LDAP, etc.) to provide such features.
It's not clear to me that mnm/TMTP has been fleshed out enough to provide a real alternative to SMTP+extensions. Rather, it appears to be another (there are many) client/server messaging application that's not interoperable.
Should these issues be addressed, discussed and refined in the appropriate forums[4], It's possible that TMTP could turn out to be a viable replacement for SMTP.
I applaud the authors' work and hope they have much success with their entry in the messaging app market.
[0] https://github.com/networkimprov/mnm/issues/5
[1] https://www.ietf.org
[2] https://mnmnotmail.org/rationale.html
[3] https://tools.ietf.org/rfc/rfc5321.txt
[4] https://www.ietf.org/how/wgs/
Edit: Fixed links.
And yes, TMTP will see a lot more revision, and real-world use, before it's proposed to any standards body.
(I'm the author.)
Yes. That was the document I was talking about, but I linked the wrong page.
My apologies for any confusion.
I've implemented both client and server, so there's the basis for a "reference implementation".
More here: https://news.ycombinator.com/item?id=25804869#25807379
(I'm the author.)
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.
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 :)
Occasionally I threaten to implement it in order to upset somebody.
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.
https://delta.chat
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.
It doesn't seem to work for a "common" email use case of contacting random people at other organisations. How would I say contact a vendor and a sales guy reply to me?
Can I publish my address on my website or business card and people contact me?
Of course any-to-any connections with email (or the phone system) spend a lot of time working with the downside of "unwanted" messages/calls.
First, to communicate within a single organization or project. Second, between organizations/groups who adopted it already. Third, when critical mass is reached, open it.
The really cool feature seem to be that an unknown/unapproved party can only ask you to establish a contact, and cannot immediately send you any links, attachments, etc.
More here: https://news.ycombinator.com/item?id=25804869#25807379
(I'm the author.)
https://en.wikipedia.org/wiki/Cost-based_anti-spam_systems
There's nothing insecure about including JSON data for a chart/graph. It wouldn't support arbitrary JS (for heaven's sake :)
More here: https://news.ycombinator.com/item?id=25804869#25807379
(I'm the author :)
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
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.
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.
[0] https://en.wikipedia.org/wiki/Email_encryption
[1] https://tools.ietf.org/html/rfc8314
s/mime is expensive in terms of certificates and difficult to set up. GPG's trust chain based on key signing parties has never taken off outside the crypto geek community (Don't get me wrong, I'm one too!)
Perhaps a "let's encrypt" approach to s/mime could work though. I could see that happening. It would indeed solve a lot of issues.
Corporate environments generally have an easier time with s/mime, and IIUC this app is focused on corporate environments.
GPG is nice (I like a lot and have used it for a very long time), but it's certainly niche.
That said, I included s/mime and gpg to illustrate that end to end encryption is not only possible, but that mature, functional tools are available in an SMTP+extensions environment.
It would be interesting to know how mnm/TMTP does encryption. I'd assume it uses TLS for transport. As for endpoint and server storage encryption (assuming it does that at all), you'd hope they'd use some sort of asymmetric key encryption, which raises the same issues as s/mime and gpg.
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.