6 ms·

This is exactly what I've been looking for! It seems the product is aimed at technical users (at least initially), though there are some technical details I di

This is exactly what I've been looking for! It seems the product is aimed at technical users (at least initially), though there are some technical details I didn't see in the video, description or FAQ: - This is an MUA, correct? Based on the features on the project page, it sounds like MailPile will not act as an MTA or MDA, and is predominantly interfacing with mbox/maildir. I see features for IMAP and POP3 on the roadmap, but its not clear if using those protocols is idiomatic for MailPile. - How is PGP/GPG handled? The server-side code for MailPile must have access to my secret key, correct? Is MailPile's web interface then accessible via HTTPS (given the proper cert)? - Is there a plan for a key management interface? - It sounds like the MUA itself (MailPile) is a server, and it would access maildir/mbox directly. Is there any API planned for accessing that data through MailPile's programatically, or is MailPile's main goal to provide a browser interface? - This might have been covered, but will the web interface support mobile as well? Thanks for working on this...it really sounds like a great project!

aet 13y ago
Also check lavabit.com
HerraBRE 13y ago
Thanks! The idea is you run Mailpile on a machine you control (it is an MUA), either your laptop (and connect to localhost) or a home server like a plug computer or something like that - basically somewhere where you feel comfortable storing your secret keys. And yes, API access to mail is something we already support, every "command" can return either HTML, plain text or JSON. Probably XML to come as well. We'll have to help with key management, otherwise it won't be usable by normal folks. Mobile web support, yes, probably sooner than later. Hope this clarifies!
- rsync 13y ago
  Yes, this is also something I very much want. I personally use (al)pine over SSH, so I don't need this ... my email is already on my own mailserver and I already access it over a secure channel, etc. But my wife ... she's not going to put up with pine. So then I run a pop daemon. And she pops from gmail. And her email is in third party hands, etc. If there were a decent web mail client, I could turn off popd, one less open port, and access only over SSL. Which I would hide with port-knocking, of course. I can teach her port-knocking, right ?
- mtgx 13y ago
  I'm not sure how you plan on doing it, but I think you should tie everyone's public keys to their names/id's. So let's say you know someone who uses Mailpile. You shouldn't have to ask him what's his key. You should just "enable PGP" (if it's not default, though maybe it should be), and he should just get the e-mail. So try to do the key management as automatic and "out of the way" for users as possible. That's the biggest hurdle with using PGP right now.
  - icebraining 13y ago
    That's how PGP itself works - you have keyservers, to which the keys can be submitted and then other people can query it using the person's name and/or email. The problem is, of course, ensuring the key is correct, and not some hijacker's.
  - chongli 13y ago
    But that just defeats the whole purpose of PGP. If you don't even know where the key is coming from, how do you know it's secure?
    - amenod 13y ago
      Easy: http://www.xkcd.com/1181/ http://www.xkcd.com/1181/ :)
- iuguy 13y ago
  Am I right in saying that this is something accessed in a browser? What's the backend?
- alextingle 13y ago
  It sounds like your approach to storing the secret key is going to be an issue for some people. I see the reasoning behind your current design, but still none of the options look really great... a. Home server. Most people don't have a fixed IP or domain name, so it's going to be a pain for them to access their home server on the run. I do have a fixed IP, but I'd still hesitate to rely on my home connection whilst I'm roaming. b. Localhost. No one can complain about reliability or accessibility when you are hosting the service right there on your own PC. But now I'm tied to that one PC - I can't check my e-mail from work, or from my phone. c. Cloud / co-location. Now we have reliable hosting, but privacy?? I'd hesitate to upload my private key to a cloud server. Also, I now need 24/7 internet access even to read my old mail. Perhaps localhost is the best place for it. My canonical e-mail store can remain IMAP in the cloud, but I can run an instance of Mailpile on each of my devices. Will the client/server model work on a phone? - Surely most phones refuse to give enough CPU time to apps in "the background". I suppose you could weld a browser instance on to the front of it, and call it a standalone app.
  - HerraBRE 13y ago
    a. and b. are actually significantly mitigated by https://pagekite.net/ https://pagekite.net/ , which just happens to be my other project. :-) c. might be OK for some, but we don't recommend it. Another solution is to run Mailpile in multiple places and teach it to sync multiple instances. Complicated, but might be worth doing.
OGC 13y ago
> The server-side code for MailPile must have access to my secret key, correct? Dealbreaker right there.
- icebraining 13y ago
  Why? You can just run the server on your own machine. That's how the git annex assistant works, for example - start a local webserver, then launch the browser pointing to it.
- claudius 13y ago
  There is no possibility to build this in a web app without the server having access to the key. The only way to get this is by some (currently) non-standard support in the browser, e.g. by an extension – given the auto-update functionality of most such extensions, this is the same game again.

aet 13y ago

Also check lavabit.com

HerraBRE 13y ago

Thanks! The idea is you run Mailpile on a machine you control (it is an MUA), either your laptop (and connect to localhost) or a home server like a plug computer or something like that - basically somewhere where you feel comfortable storing your secret keys. And yes, API access to mail is something we already support, every "command" can return either HTML, plain text or JSON. Probably XML to come as well. We'll have to help with key management, otherwise it won't be usable by normal folks. Mobile web support, yes, probably sooner than later. Hope this clarifies!

rsync 13y ago
Yes, this is also something I very much want. I personally use (al)pine over SSH, so I don't need this ... my email is already on my own mailserver and I already access it over a secure channel, etc. But my wife ... she's not going to put up with pine. So then I run a pop daemon. And she pops from gmail. And her email is in third party hands, etc. If there were a decent web mail client, I could turn off popd, one less open port, and access only over SSL. Which I would hide with port-knocking, of course. I can teach her port-knocking, right ?
mtgx 13y ago
I'm not sure how you plan on doing it, but I think you should tie everyone's public keys to their names/id's. So let's say you know someone who uses Mailpile. You shouldn't have to ask him what's his key. You should just "enable PGP" (if it's not default, though maybe it should be), and he should just get the e-mail. So try to do the key management as automatic and "out of the way" for users as possible. That's the biggest hurdle with using PGP right now.
- icebraining 13y ago
  That's how PGP itself works - you have keyservers, to which the keys can be submitted and then other people can query it using the person's name and/or email. The problem is, of course, ensuring the key is correct, and not some hijacker's.
- chongli 13y ago
  But that just defeats the whole purpose of PGP. If you don't even know where the key is coming from, how do you know it's secure?
  - amenod 13y ago
    Easy: http://www.xkcd.com/1181/ http://www.xkcd.com/1181/ :)
iuguy 13y ago
Am I right in saying that this is something accessed in a browser? What's the backend?
alextingle 13y ago
It sounds like your approach to storing the secret key is going to be an issue for some people. I see the reasoning behind your current design, but still none of the options look really great... a. Home server. Most people don't have a fixed IP or domain name, so it's going to be a pain for them to access their home server on the run. I do have a fixed IP, but I'd still hesitate to rely on my home connection whilst I'm roaming. b. Localhost. No one can complain about reliability or accessibility when you are hosting the service right there on your own PC. But now I'm tied to that one PC - I can't check my e-mail from work, or from my phone. c. Cloud / co-location. Now we have reliable hosting, but privacy?? I'd hesitate to upload my private key to a cloud server. Also, I now need 24/7 internet access even to read my old mail. Perhaps localhost is the best place for it. My canonical e-mail store can remain IMAP in the cloud, but I can run an instance of Mailpile on each of my devices. Will the client/server model work on a phone? - Surely most phones refuse to give enough CPU time to apps in "the background". I suppose you could weld a browser instance on to the front of it, and call it a standalone app.
- HerraBRE 13y ago
  a. and b. are actually significantly mitigated by https://pagekite.net/ https://pagekite.net/ , which just happens to be my other project. :-) c. might be OK for some, but we don't recommend it. Another solution is to run Mailpile in multiple places and teach it to sync multiple instances. Complicated, but might be worth doing.

OGC 13y ago

> The server-side code for MailPile must have access to my secret key, correct? Dealbreaker right there.

icebraining 13y ago
Why? You can just run the server on your own machine. That's how the git annex assistant works, for example - start a local webserver, then launch the browser pointing to it.
claudius 13y ago
There is no possibility to build this in a web app without the server having access to the key. The only way to get this is by some (currently) non-standard support in the browser, e.g. by an extension – given the auto-update functionality of most such extensions, this is the same game again.