4 ms·

It would be incredibly useful if there was a mail service that received email over SMTP, encrypted it straight away with a public key, then just dumped the encr

It would be incredibly useful if there was a mail service that received email over SMTP, encrypted it straight away with a public key, then just dumped the encrypted email into a general-purpose online storage solution (e.g. an S3 bucket). That would IMO provide a good base for encrypted client-side apps to build on top of. Open source would better be able address the problem of writing a client once the money needed for hosting and storage is taken out of the equation.

LiveTheDream 13y ago
Hushmail and Lavabit sort of do this. They encrypt emails before storing them. However, as far as I can tell they handle the public/private keypair on their own, so the security only goes as far as you trust them.
dmix 13y ago
Countermail does this: https://countermail.com/ https://countermail.com/
- richdougherty 13y ago
  I was imagining an even lower level service. I guess that CounterMail must store unencrypted email headers in order to serve IMAP, right? I was thinking something that just manages the problem of being online 24/7 to receive email. This (and possibly sending email) is the only thing that can't be done completely client side. A service like I was thinking of would just accept messages, immediately encrypt them (headers and all) with an RSA key and then dump them into some third party online storage system (maybe sending a notification over XMPP too). The rest of the email pipeline could then be run completely client-side. I'm talking about doing everything client side: spam filtering, sorting into folders or tagging, running email rules, indexing, and of course viewing and reading email. (A clever filesystem/database would need to be layered on top of the online storage system to manage the state of the pipeline and provide fast indexes.) For maximum ease of use the client-side app could even be a rich Gmail-like JavaScript app that stores private keys locally and but stores most data remotely (e.g. uses S3 directly via CORS). This would all allow hackers like us to build interesting (but still encrypted) email services without having to worry about infrastructure. That's something I don't want to manage anyway! Also the barrier to entry of writing a Gmail clone would be much lower because you could do at almost zero cost. Since you don't have to receive email or manage storage your service would mostly be static JavaScript containing the client-side logic. Most - even all - of the service could just be served on a CDN.

LiveTheDream 13y ago

Hushmail and Lavabit sort of do this. They encrypt emails before storing them. However, as far as I can tell they handle the public/private keypair on their own, so the security only goes as far as you trust them.

dmix 13y ago

Countermail does this: https://countermail.com/ https://countermail.com/

richdougherty 13y ago
I was imagining an even lower level service. I guess that CounterMail must store unencrypted email headers in order to serve IMAP, right? I was thinking something that just manages the problem of being online 24/7 to receive email. This (and possibly sending email) is the only thing that can't be done completely client side. A service like I was thinking of would just accept messages, immediately encrypt them (headers and all) with an RSA key and then dump them into some third party online storage system (maybe sending a notification over XMPP too). The rest of the email pipeline could then be run completely client-side. I'm talking about doing everything client side: spam filtering, sorting into folders or tagging, running email rules, indexing, and of course viewing and reading email. (A clever filesystem/database would need to be layered on top of the online storage system to manage the state of the pipeline and provide fast indexes.) For maximum ease of use the client-side app could even be a rich Gmail-like JavaScript app that stores private keys locally and but stores most data remotely (e.g. uses S3 directly via CORS). This would all allow hackers like us to build interesting (but still encrypted) email services without having to worry about infrastructure. That's something I don't want to manage anyway! Also the barrier to entry of writing a Gmail clone would be much lower because you could do at almost zero cost. Since you don't have to receive email or manage storage your service would mostly be static JavaScript containing the client-side logic. Most - even all - of the service could just be served on a CDN.