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
Context
1
Replies
8
@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.
@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
@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