info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Email 2.0
17 views
Skip to first unread message
Jason Evans
Oct 24, 2021, 3:21:39 AM10/24/21
to
First of all, I do not consider any form of instant messaging a
replacement for email. Email is long-form communication. Instant
messaging is not.
Email2.0 or whatever you want to call it would include the following:
An open standard. Ideally, there would be an RFC that all legitimate
email providers and email clients would adhere to and not be owned by any
single company. Right now email is like this but instant messaging is not
an open standard. I can't write my own client for Signal, Whatsapp, etc.
because they are proprietary nor can I run my own server.
Unencrypted metadata from email would be limited to only the email
address of the recipient. All other data must be a part of the encrypted
message. Individual servers may log incoming and outgoing times for
messages but that data will not be visible metadata.
Encryption is never optional.
When an email is sent to us...@example.com, the mail client will ping
example.com's server and ask for a public key for "user" if one has not
already been cached or manually added. The email will then be encrypted
and sent. "user's" email client/service will decrypt the message. Users
will also have an option to opt-out of having their public key available
on their provider's server. They can then only receive emails from people
that they have shared their key with.
replacement for email. Email is long-form communication. Instant
messaging is not.
Email2.0 or whatever you want to call it would include the following:
An open standard. Ideally, there would be an RFC that all legitimate
email providers and email clients would adhere to and not be owned by any
single company. Right now email is like this but instant messaging is not
an open standard. I can't write my own client for Signal, Whatsapp, etc.
because they are proprietary nor can I run my own server.
Unencrypted metadata from email would be limited to only the email
address of the recipient. All other data must be a part of the encrypted
message. Individual servers may log incoming and outgoing times for
messages but that data will not be visible metadata.
Encryption is never optional.
When an email is sent to us...@example.com, the mail client will ping
example.com's server and ask for a public key for "user" if one has not
already been cached or manually added. The email will then be encrypted
and sent. "user's" email client/service will decrypt the message. Users
will also have an option to opt-out of having their public key available
on their provider's server. They can then only receive emails from people
that they have shared their key with.
b...@ripco.com
Oct 24, 2021, 2:00:03 PM10/24/21
to
Jason Evans <jse...@mailfence.com> wrote:
> An open standard. Ideally, there would be an RFC that all legitimate
> email providers and email clients would adhere to and not be owned by any
> single company.
HAHAHAHAHAH, hah, ho ho ho ho.
> An open standard. Ideally, there would be an RFC that all legitimate
> email providers and email clients would adhere to and not be owned by any
> single company.
Tell me another.
IMAP has been around for what, 20+ years and yet Microsoft and Google
decided to use their own versions "mostly compatable" with the rest of the
world.
You have like what, 50 different email clients across a dozen different
platforms? Really, everyone is just going to join in?
I think the phrase is, "Just like herding cats".
Plus you have systems like Google and Yahoo who wouldn't encrypt jack shit
because of the data mining they do.
It'll never work.
-bruce
b...@ripco.com
Jason Evans
Oct 24, 2021, 2:19:17 PM10/24/21
to
On Sun, 24 Oct 2021 18:00:02 +0000, bje wrote:
> It'll never work.
There's no technical reason that it couldn't work, right? The user base
would be tiny until it found its niche but that's OK. The difficulty
would be getting people (probably techie, security/privacy minded people)
to try it out the first time.
> It'll never work.
There's no technical reason that it couldn't work, right? The user base
would be tiny until it found its niche but that's OK. The difficulty
would be getting people (probably techie, security/privacy minded people)
to try it out the first time.
b...@ripco.com
Oct 24, 2021, 3:46:41 PM10/24/21
to
Been around for years. Getting people to use it is another thing.
You were talking about system-to-system, right?
Someone on gmail.com emailing someone on comcast.com and getting it encrypted
from start to finish?
It'll never happen.
-bruce
b...@ripco.com
Jason Evans
Oct 25, 2021, 3:03:42 AM10/25/21
to
No, not really. Protonmail uses the standard email format which means
unecrypted header metadata. Also, Protonmail uses a proprietary system
for how it handled email internally which includes the fact that they
also host your private key for you.
I'm proposing a new standard which minimizes the amount of unencrypted
metadata to only being the recipient. One of the major issues that the
privacy/security community has with email as it is now is that there is
too much information that is unencrypted even with proper gnupg.
For example, here's an encrypted email that I just sent to myself with
gnupg using Protonmail:
https://susepaste.org/view/raw/42629518
You can see that there is quite a bit of information there that is not
encrypted and this information is quite valuable to a lot of people.
The email system that I am proposing would be _incompatible_ with
existing email because the existing email framework requires these
headers to be unencrypted. This means that the userbase would be
miniscule compared legacy email system. This is OK. It is meant for a
specific use case. To provide always fully encrypted email for users who
value their privacy. I believe that the community who would want this is
globally quite large. They would only be able to talk to each other, but
that's OK in the beginning.
unecrypted header metadata. Also, Protonmail uses a proprietary system
for how it handled email internally which includes the fact that they
also host your private key for you.
I'm proposing a new standard which minimizes the amount of unencrypted
metadata to only being the recipient. One of the major issues that the
privacy/security community has with email as it is now is that there is
too much information that is unencrypted even with proper gnupg.
For example, here's an encrypted email that I just sent to myself with
gnupg using Protonmail:
https://susepaste.org/view/raw/42629518
You can see that there is quite a bit of information there that is not
encrypted and this information is quite valuable to a lot of people.
The email system that I am proposing would be _incompatible_ with
existing email because the existing email framework requires these
headers to be unencrypted. This means that the userbase would be
miniscule compared legacy email system. This is OK. It is meant for a
specific use case. To provide always fully encrypted email for users who
value their privacy. I believe that the community who would want this is
globally quite large. They would only be able to talk to each other, but
that's OK in the beginning.
b...@ripco.com
Oct 25, 2021, 8:43:44 AM10/25/21
to
Jason Evans <jse...@mailfence.com> wrote:
> For example, here's an encrypted email that I just sent to myself with
> gnupg using Protonmail:
>
> https://susepaste.org/view/raw/42629518
>
> You can see that there is quite a bit of information there that is not
> encrypted and this information is quite valuable to a lot of people.
Ok, I see your point but have reservations that the currently unencrypted
> For example, here's an encrypted email that I just sent to myself with
> gnupg using Protonmail:
>
> https://susepaste.org/view/raw/42629518
>
> You can see that there is quite a bit of information there that is not
> encrypted and this information is quite valuable to a lot of people.
data has much value. The From: and Message-ID: would seem to be the worst of
it.
But isn't encrypting everything except recipient going to mess up any kind
of filtering like procmail or Apple Mail Rules where you can separate work
mail from family from spam and so forth?
And what about logging? If the smtp part of this new system doesn't log,
seems like troubleshooting anything is going to be a bitch. If there is
logging, doesn't that defeat the purpose of suppressing the metadata?
Too many questions, I know, but although it's overall a good idea, I just
can't see it being adopted en masse. Really too much work for so little
return.
-bruce
b...@ripco.com
b...@ripco.com
Oct 25, 2021, 11:05:15 AM10/25/21
to
Jason Evans <jse...@mailfence.com> wrote:
> The email system that I am proposing would be _incompatible_ with
> existing email because the existing email framework requires these
> headers to be unencrypted. This means that the userbase would be
> miniscule compared legacy email system. This is OK. It is meant for a
> specific use case. To provide always fully encrypted email for users who
> value their privacy. I believe that the community who would want this is
> globally quite large. They would only be able to talk to each other, but
> that's OK in the beginning.
I was thinking about this a bit more and I think what you want is something
> The email system that I am proposing would be _incompatible_ with
> existing email because the existing email framework requires these
> headers to be unencrypted. This means that the userbase would be
> miniscule compared legacy email system. This is OK. It is meant for a
> specific use case. To provide always fully encrypted email for users who
> value their privacy. I believe that the community who would want this is
> globally quite large. They would only be able to talk to each other, but
> that's OK in the beginning.
like a point-to=point service.
I mean, right now if you wanted to send me a "for my eyes only" email, you
type up the message, encrypt it, hit send and it goes to some smtp server,
maybe one under your control, maybe not. That needs to look up MX records,
figures out where it should go so it gets to me, that server might
re-deliver it to where I pull it down.
It's a paper trail you can't avoid. Headers are needed to make sure it goes
to where it's supposed to go.
But what if when you hit send, rather than going to any smtp server it goes
directly to a device under my control. Of course the main problem is there
is some kind of open directory is needed to point the message to the right
device.
But what if that directory is part of one of those blockchain thingies that
bitcoin and the other alt coins use? I don't really know the inner workings
of those things but anyone having a wallet open is part of it and there is
some weird thing with the wallets verifying each transaction. Can't fuck
with it with false data.
If everyone using this mail system had a unique "wallet id" similar to the
id of a bitcoin wallet, your device can listen in to the blockchain, when it
sees your unique id, it checks the rest for if it's a message for me or not,
using some kind of unique encryption.
The blockchain doesn't come from one server (except at the beginning of
creation) then it's up to open wallets to continue and keep it going.
So what I think is the blockchain can be used for is a signalling system
that someone wants to email you and to start listening for a transaction.
Even if you are off line, when returning the software starts to gather the
missing blocks while you were gone and will still receive the message
eventually when it catches up.
Just a thought. Probably 1001 things wrong with this idea and I wouldn't
have a clue how to proceed. Not even sure if the message should be inserted
into the blockchain or it just being used as a signalling system but I think
it fullfills all your requirements and eliminates my doubts on restructuring
the current email system.
Maybe a different way can be had but I'm sure point-to-point is the answer
you are looking for on email version 2.
-bruce
b...@ripco.com
Computer Nerd Kev
Oct 25, 2021, 5:07:37 PM10/25/21
to
Jason Evans <jse...@mailfence.com> wrote:
> On Sun, 24 Oct 2021 19:46:40 +0000, bje wrote:
>
>> You mean like https://protonmail.com ?
>
> No, not really. Protonmail uses the standard email format which means
> unecrypted header metadata. Also, Protonmail uses a proprietary system
> for how it handled email internally which includes the fact that they
> also host your private key for you.
>
> I'm proposing a new standard which minimizes the amount of unencrypted
> metadata to only being the recipient. One of the major issues that the
> privacy/security community has with email as it is now is that there is
> too much information that is unencrypted even with proper gnupg.
It sounds a lot like what Lavabit's Dark Internet Mail Environment
> On Sun, 24 Oct 2021 19:46:40 +0000, bje wrote:
>
>> You mean like https://protonmail.com ?
>
> No, not really. Protonmail uses the standard email format which means
> unecrypted header metadata. Also, Protonmail uses a proprietary system
> for how it handled email internally which includes the fact that they
> also host your private key for you.
>
> I'm proposing a new standard which minimizes the amount of unencrypted
> metadata to only being the recipient. One of the major issues that the
> privacy/security community has with email as it is now is that there is
> too much information that is unencrypted even with proper gnupg.
"Paranoid" mode does:
https://lavabit.com/security.html
https://github.com/lavabit/
However currently they're still working on the software and only
offer POP/IMAP client access themselves:
"How do I switch between modes (Trustful, Cautious, Paranoid)?
Currently we only support Lavabit Flow, which allows users to
operate in "Trustful" mode using any POP or IMAP client. While
we've developed command line tools, and libraries with DIME
support, we are still working to integrate them into full fledged
applications suitable for customer use. We're working hard to get
these clients finished quickly, and welcome your help with the
effort."
https://lavabit.com/questions.html
--
__ __
#_ < |\| |< _#
Doc O'Leary
Oct 27, 2021, 12:32:34 PM10/27/21
to
For your reference, records indicate that
these days are in the form of “notifications” from automated systems rather
than any sort of long conversation with people. For me, the fire-and-forget asynchronous nature of email is what I value the most.
> Right now email is like this but instant messaging is not
> an open standard. I can't write my own client for Signal, Whatsapp, etc.
> because they are proprietary nor can I run my own server.
None of those apps are the singular definition of what “instant messaging”
is. You’re free to choose IRC or XMPP if you want to use some IM platform
standardized by RFCs. In my experience, though, good ol’ SMTP+IMAP these
days can be just as fast as any of those “instant” chat solutions.
> Unencrypted metadata from email would be limited to only the email
> address of the recipient.
Why stop there? If you’re going to create a whole new system, you might as
well bake in the idea of “disposable email addresses” that allow the
recipient the ability to cut off abusive senders. Nobody is going to
switch over to a system that doesn’t solve the spam problem, so an exposed
address is a non-starter.
> All other data must be a part of the encrypted
> message. Individual servers may log incoming and outgoing times for
> messages but that data will not be visible metadata.
Sounds like transport errors would be a pain to find and fix. You really
need to flesh out how messages are going to move through your new network
such that people have some way to audit the reliability.
> Encryption is never optional.
Again, you need to flesh out what that actually means. Is there something
about SMTP that keeps you from currently encrypting all your message
content? At some level, the system needs to be data-agnostic; encryption
is *moot* when you’re just pushing around bits.
> They can then only receive emails from people
> that they have shared their key with.
No, they can then only *decrypt* them. The server will be pounded by
anyone and everyone who has their email address, with no way of knowing
what is and isn’t valid because it doesn’t have the private key or any
useful metadata. The client *will* have to download them all and process
them to look for a valid message.
I don’t like your new system. Email 1.0 still seems to be the choice for
me. Yes, clients should be improved to make some features more
approachable to the average user. But the same could be said of IRC as an
IM platform. Even NNTP could be more functional than most of the web
forums that replaced it. Closed systems are winning the day, though, so
if you want an open standard (old or new) to replace them, you have to
find a killer app that simply cannot be owned by any one company.
--
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly
Jason Evans <jse...@mailfence.com> wrote:
> First of all, I do not consider any form of instant messaging a
> replacement for email. Email is long-form communication. Instant
> messaging is not.
The line is much fuzzier than that for most people. Most emails I receive
> First of all, I do not consider any form of instant messaging a
> replacement for email. Email is long-form communication. Instant
> messaging is not.
these days are in the form of “notifications” from automated systems rather
than any sort of long conversation with people. For me, the fire-and-forget asynchronous nature of email is what I value the most.
> Right now email is like this but instant messaging is not
> an open standard. I can't write my own client for Signal, Whatsapp, etc.
> because they are proprietary nor can I run my own server.
is. You’re free to choose IRC or XMPP if you want to use some IM platform
standardized by RFCs. In my experience, though, good ol’ SMTP+IMAP these
days can be just as fast as any of those “instant” chat solutions.
> Unencrypted metadata from email would be limited to only the email
> address of the recipient.
well bake in the idea of “disposable email addresses” that allow the
recipient the ability to cut off abusive senders. Nobody is going to
switch over to a system that doesn’t solve the spam problem, so an exposed
address is a non-starter.
> All other data must be a part of the encrypted
> message. Individual servers may log incoming and outgoing times for
> messages but that data will not be visible metadata.
need to flesh out how messages are going to move through your new network
such that people have some way to audit the reliability.
> Encryption is never optional.
Again, you need to flesh out what that actually means. Is there something
about SMTP that keeps you from currently encrypting all your message
content? At some level, the system needs to be data-agnostic; encryption
is *moot* when you’re just pushing around bits.
> They can then only receive emails from people
> that they have shared their key with.
anyone and everyone who has their email address, with no way of knowing
what is and isn’t valid because it doesn’t have the private key or any
useful metadata. The client *will* have to download them all and process
them to look for a valid message.
I don’t like your new system. Email 1.0 still seems to be the choice for
me. Yes, clients should be improved to make some features more
approachable to the average user. But the same could be said of IRC as an
IM platform. Even NNTP could be more functional than most of the web
forums that replaced it. Closed systems are winning the day, though, so
if you want an open standard (old or new) to replace them, you have to
find a killer app that simply cannot be owned by any one company.
--
"Also . . . I can kill you with my brain."
River Tam, Trash, Firefly
0 new messages