Egregoros

Signal feed

Timeline

Post

Remote status

Context

7

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

@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
@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

Replies

2

@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