if proton mail were serious about improving e2ee email, they would've worked to have a standard extension for e2ee via smtp that other MTAs could implement, so that encrypted emails would not be limited to proton mail's non distributed, non self-hostable, proprietary smtp servers
Timeline
Post
Remote status
Replies
14
@atax1a they don't need to get it into smtp proper, not at first at least -- esmtp supports extension discovery via EHLO, so give the server a PROTON_E2EE extension and if supported, use e2ee by some standard extension protonmail would document themselves
now any MTA can implement that, make use of it -- eventually if google doesn't budge, we still have plenty of other options
now any MTA can implement that, make use of it -- eventually if google doesn't budge, we still have plenty of other options
@navi yes, we know how ESMTP works, we've been self-hosting our own email for over 20 years :)
@atax1a then i do not understand your point about google controlling SMTP development, we can do our own thing, but protonmail does not want to
@navi you're describing a technical solution (Just™ implement the feature) to a social problem (we already cannot reliably send mail to google, who is actively attempting to kill email)
@atax1a sending email to google was never part of the problem i described
the problem i described is protonmail selling itself on e2ee while having it's backend software proprietary, and having no intention of improving the wider ecosystem, basically funneling people to use protonmail so they can have encrypted conversations with other protonmail users, and *only* other protonmail users
never mentioned google, and they have nothing to do with the problem at hand
the problem i described is protonmail selling itself on e2ee while having it's backend software proprietary, and having no intention of improving the wider ecosystem, basically funneling people to use protonmail so they can have encrypted conversations with other protonmail users, and *only* other protonmail users
never mentioned google, and they have nothing to do with the problem at hand
@navi they are the 800lb gorilla in the SMTP room, and so if you're not considering what response they will have to other people doing stuff that they don't approve of to the protocol, that seems, to us, unrealistic. until they're removed from their primacy in the ecosystem, the protocol cannot evolve.
@navi
> a standard extension for e2ee via smtp
PGP/GPG
> that other MTAs could implement
If it's not implemented by the MUA, then it's not really e2ee. MTA's already have TLS, DKIM, etc.
> a standard extension for e2ee via smtp
PGP/GPG
> that other MTAs could implement
If it's not implemented by the MUA, then it's not really e2ee. MTA's already have TLS, DKIM, etc.
@toiletpaper
> PGP/GPG
yes because non-techies famously don't have issues setting it up
pgp encrypted email has a huge ui/ux issue and makes it so you can't just send someone an email and have it just work™ -- that's the promise protonmail gives
> If it's not implemented by the MUA, then it's not really e2ee. MTA's already have TLS, DKIM, etc.
ofc MUAs need to support it too, but the whole stack needs to be aware so we don't end up delivering unreadable emails and confusing people even more
if pgp encrypted emails were enough, protonmail wouldn't exist
> PGP/GPG
yes because non-techies famously don't have issues setting it up
pgp encrypted email has a huge ui/ux issue and makes it so you can't just send someone an email and have it just work™ -- that's the promise protonmail gives
> If it's not implemented by the MUA, then it's not really e2ee. MTA's already have TLS, DKIM, etc.
ofc MUAs need to support it too, but the whole stack needs to be aware so we don't end up delivering unreadable emails and confusing people even more
if pgp encrypted emails were enough, protonmail wouldn't exist
@atax1a @navi When done with Google, one must also deal with Microsoft as another 800lb gorilla.
I don’t know what Proton is doing *in SMTP* that wouldn’t be addressed by implicit TLS transport, which was effectively given up on as an interoperable mechanism with the reassignment of port 465 to implicit TLS submission.
Any ideas for revising SMTP should start with understanding similar efforts in the past & ongoing. A good start would be a look at the state of SMTPUTF8. It’s not pretty
@navi
> non-techies ... a huge ui/ux issue
It's not a technical hurdle. The technology has existed practically from day one, but MUA developers have been lazy about making it user friendly. You can't send an encrypted message to someone without their public key anyway, so there's zero chance of accidentally sending a garbled message to someone who hasn't enabled encryption, unless they switch MUA regularly or are incompetent at key management (arguably the MUA's fault).
> don't end up delivering unreadable emails
Which is why encrypted messengers exist (eg. ICQ + OTR), because it's easier to implement something like this without having to also convince every weird legacy MUA to finally support it. Same goes for XMPP + OMEMO. It's often a pain in the ass to get it working because client apps implementation is utterly shit, especially cross-platform. Conversations is the only half decent implementation, but still limited to android, and presuming your contacts are either also on conversations infra, or are not "non-techies" and able to manage their own. Just getting a non-techie to verify a signature via side channel without trust on first use is like pulling teeth.
> the promise protonmail gives
protonmail, tutanota, barely qualify as e2ee given that the entire encryption and decryption process is handled by software served dynamically from their own centralised servers. Sure the algo runs in the browser (lol) on the client side, and technically the server doesn't have plain text copies of messages, but they control the code used in each and every interaction, which makes it possible for them to circumvent at will should they so choose. Sure proton has a desktop client available to paid users, and assuming it's not just a glorified webview, that might theoretically mitigate the issue, but otherwise it's basically just lipstick on a pig so they can tell cops to gtfo when they try to seize server equipment, assuming they choose not to cooperate. End of the day, you're trusting their word for it, not a cryptographic guarantee.
> ofc MUAs need to support it too
Which just brings the problem back around full circle. Until you get the MUA developers to support it, any proposed solution is dead in the water. The fact that PGP/GPG has been around for 35 years now and no one has bothered to make it user friendly enough to catch on, should tell you everything you need to know about that. It's not the cryptography that's at fault. Moreover there's no need for the MTA to even know PGP/GPG exists, much less support it, since it's all handled in the client where it belongs.
All that aside, the closest I've seen to what you're talking about is delta.chat
> non-techies ... a huge ui/ux issue
It's not a technical hurdle. The technology has existed practically from day one, but MUA developers have been lazy about making it user friendly. You can't send an encrypted message to someone without their public key anyway, so there's zero chance of accidentally sending a garbled message to someone who hasn't enabled encryption, unless they switch MUA regularly or are incompetent at key management (arguably the MUA's fault).
> don't end up delivering unreadable emails
Which is why encrypted messengers exist (eg. ICQ + OTR), because it's easier to implement something like this without having to also convince every weird legacy MUA to finally support it. Same goes for XMPP + OMEMO. It's often a pain in the ass to get it working because client apps implementation is utterly shit, especially cross-platform. Conversations is the only half decent implementation, but still limited to android, and presuming your contacts are either also on conversations infra, or are not "non-techies" and able to manage their own. Just getting a non-techie to verify a signature via side channel without trust on first use is like pulling teeth.
> the promise protonmail gives
protonmail, tutanota, barely qualify as e2ee given that the entire encryption and decryption process is handled by software served dynamically from their own centralised servers. Sure the algo runs in the browser (lol) on the client side, and technically the server doesn't have plain text copies of messages, but they control the code used in each and every interaction, which makes it possible for them to circumvent at will should they so choose. Sure proton has a desktop client available to paid users, and assuming it's not just a glorified webview, that might theoretically mitigate the issue, but otherwise it's basically just lipstick on a pig so they can tell cops to gtfo when they try to seize server equipment, assuming they choose not to cooperate. End of the day, you're trusting their word for it, not a cryptographic guarantee.
> ofc MUAs need to support it too
Which just brings the problem back around full circle. Until you get the MUA developers to support it, any proposed solution is dead in the water. The fact that PGP/GPG has been around for 35 years now and no one has bothered to make it user friendly enough to catch on, should tell you everything you need to know about that. It's not the cryptography that's at fault. Moreover there's no need for the MTA to even know PGP/GPG exists, much less support it, since it's all handled in the client where it belongs.
All that aside, the closest I've seen to what you're talking about is delta.chat
@grumpybozo @navi furthermore, the ends of the conversation are the MUAs, so even if all SMTP transactions were done in TLS, that's the easy part. youve still got the metadata problems and the key management problems and so forth
so proton mail does use pgp? no keyserver tho
then why in hell do they not let people use smtp and imap directly, why force the bridge down onto everyone?
plenty of other clients have supported pgp for ages
RE: https://social.vlhl.dev/objects/54294066-32ea-4bf4-ab65-9cf9fac3ad83
then why in hell do they not let people use smtp and imap directly, why force the bridge down onto everyone?
plenty of other clients have supported pgp for ages
RE: https://social.vlhl.dev/objects/54294066-32ea-4bf4-ab65-9cf9fac3ad83
@navi proton mail isnt good. they arent the worst. but they arent very good either