Email is already nicely federated, but I think it’s time for a change. Services like protonmail offer encryption between users, but you can’t host your own instance. It would be awesome if there was a spec somewhere for a federated email service that defines
email encryption between users
markdown
connection with activity pub? (What would this look like) I mean some way to email the activity pub, ie: add comments via email
compatibility with standard email users (if you send/receive to/from a user who does not have email v2 implemented it just uses normal features)
maybe “smart attachments” for money transfers, calender invites, etc.
somehow better support for email discussion groups
this spec should be focused heavily on usage for humans instead of automated mailing, I expect html would not be defined.
I’m just spit balling here. Does anyone have any ideas? Does something like this exist?
Unpopular but very probably true fact: email can’t practicably be made secure, and people should stop trying. Email is itself archaic, and there aren’t good reasons people should use it for routine peer-to-peer communications that need secrecy.
Why? Because:
It’s default-plaintext. We don’t generally love the way websites ensure they’re viewed securely, but email doesn’t even have the basic mechanisms HTTP has to prevent secrets from accidentally being sent in the clear.
Email encryption is never forward-secure. The most popular standard, OpenPGP, involves a long-term key that is the root of secrecy for all messages from a particular person. Lose that key, ever, and not only is every message you send in the future unsafe, but every message you’ve ever sent in the past is too. That’s a terrible property for a secure messaging system.
Email leaks metadata. In fact, some of what we call email “metadata” isn’t even metadata — stuff like subject lines are simply content. They’re sent in plaintext. We would never accept a new secure messaging system that behaved like that.
Most email users get their email from a website. Unless you make them install something on all their computers — and at that point, just get them to install Signal, WhatsApp, or Wire — “encrypting” their email involves schemes in which those websites can get their plaintext mail.
Most email clients are searchable-archive-by-default. Again, if you’re using a secure messaging system to keep secrets from a state-level adversary, that’s exactly what you don’t want. And again, what matters here is the behavior of the overwhelming majority of clients. If you can stipulate a special mail client that is extra-careful, why not stipulate a forward-secure advanced messaging system and stop bothering with email?
Everything that makes email effective in the real world makes it inhospitable to secure messaging. We should stop trying to push this particular boulder up this particular mountain and instead just get people to adopt serious secure messengers.
Basically, use Matrix, XMPP or Briar. Because you’ll have to install special stuff to make email even somewhat secure anyway, so why not just switch to something that’s far MORE secure by default?
Already exists, but it’s not offered on most WebUIs
markdown
Would be a nice idea, but in my eyes more a client side feature
connection with activity pub? (What would this look like)
Please not. As far as I understood, activity pub is used for public messages, which emails are never meant for.
compatibility with standard email users, the features are simply not activated
What is a “standard” email user?
maybe “smart attachments” for money transfers, calender invites, etc.
Calender invites are working with ICS files, if the client uses the file correctly. Also Groupware like OX, Kopano (Zarafa), … already uses this feature since first release.
somehow better support for email discussion groups
Better support for mailing lists? How do you mean this?
this spec should be focused heavily on usage for humans instead of automated mailing, I expect html would not be defined.
Emails only transport what you give them. Clients translate HTML content, but you could also send just markdown in text format.
Most features I see listed are client side features. One could contribute to open source email clients like Thunderbird, Evolution, KMail, Geary, Sylpheed, Claws Mail or Mutt and suggest such options. You could also look at DeltaChat, which already implements a few of these features and can also handle “normal” emails. Some even use it as their only email client.
Mail clients like Spike, for example, already go other ways and display emails like a conversation, like DeltaChat.
Unfortunately, however, most use email via a WebUI or Outlook. Add to that, many uses Gmail, even many wannabe Mastodon instance provider. And we all know how much they love to receive ideas from others.
A community dedicated to fediverse news and discussion.
Fediverse is a portmanteau of “federation” and “universe”. It is a common, informal name for a federation of social network servers whose main purpose is microblogging, the sharing of short, public messages.
For the first you already have Autocrypt implemented in several clients including Thunderbird and Delta Chat.
A federated email delivery system with the emails my own server would be good.
From this hackernews post:
Unpopular but very probably true fact: email can’t practicably be made secure, and people should stop trying. Email is itself archaic, and there aren’t good reasons people should use it for routine peer-to-peer communications that need secrecy.
Why? Because:
It’s default-plaintext. We don’t generally love the way websites ensure they’re viewed securely, but email doesn’t even have the basic mechanisms HTTP has to prevent secrets from accidentally being sent in the clear.
Email encryption is never forward-secure. The most popular standard, OpenPGP, involves a long-term key that is the root of secrecy for all messages from a particular person. Lose that key, ever, and not only is every message you send in the future unsafe, but every message you’ve ever sent in the past is too. That’s a terrible property for a secure messaging system.
Email leaks metadata. In fact, some of what we call email “metadata” isn’t even metadata — stuff like subject lines are simply content. They’re sent in plaintext. We would never accept a new secure messaging system that behaved like that.
Most email users get their email from a website. Unless you make them install something on all their computers — and at that point, just get them to install Signal, WhatsApp, or Wire — “encrypting” their email involves schemes in which those websites can get their plaintext mail.
Most email clients are searchable-archive-by-default. Again, if you’re using a secure messaging system to keep secrets from a state-level adversary, that’s exactly what you don’t want. And again, what matters here is the behavior of the overwhelming majority of clients. If you can stipulate a special mail client that is extra-careful, why not stipulate a forward-secure advanced messaging system and stop bothering with email?
Everything that makes email effective in the real world makes it inhospitable to secure messaging. We should stop trying to push this particular boulder up this particular mountain and instead just get people to adopt serious secure messengers.
Basically, use Matrix, XMPP or Briar. Because you’ll have to install special stuff to make email even somewhat secure anyway, so why not just switch to something that’s far MORE secure by default?
The second statement is true partially.
There is a WIP to make OpenPGP forward-secure. Specially in the Delta Chat team but it is being still worked.
Subject encryption is something that exists IIRC.
Yggmail support and portable email servers is being worked in Delta Chat.
I honestly believe email is beyond salvage… even GnuPG is now compromised by funding through and cooperation with German intelligence services.
Delta chat implement some of those features.
Already exists, but it’s not offered on most WebUIs
Would be a nice idea, but in my eyes more a client side feature
Please not. As far as I understood, activity pub is used for public messages, which emails are never meant for.
What is a “standard” email user?
Calender invites are working with ICS files, if the client uses the file correctly. Also Groupware like OX, Kopano (Zarafa), … already uses this feature since first release.
Better support for mailing lists? How do you mean this?
Emails only transport what you give them. Clients translate HTML content, but you could also send just markdown in text format.
Most features I see listed are client side features. One could contribute to open source email clients like Thunderbird, Evolution, KMail, Geary, Sylpheed, Claws Mail or Mutt and suggest such options. You could also look at DeltaChat, which already implements a few of these features and can also handle “normal” emails. Some even use it as their only email client.
Mail clients like Spike, for example, already go other ways and display emails like a conversation, like DeltaChat.
Unfortunately, however, most use email via a WebUI or Outlook. Add to that, many uses Gmail, even many wannabe Mastodon instance provider. And we all know how much they love to receive ideas from others.
Technically speaking this is Matrix, if you create a GUI that looks like an e-mail client instead of an instant messenger.
I would really like to see this.
That would be indeed a better use for the Matrix protocol then as a messenger.