Mailpile: Let’s take email back • Hacker News Board

Re: Mailpile: Let’s take email back

#201

Post by unhammer » Sun, Aug 04, 2013, 7:37 AM UTC

HerraBRE wrote: post #92

alternize wrote: post #54

Earlier quoted context omitted.

so if i understand you comment right: it will be a MUA that accessed through a webbrowser, and one still needs to have an IMAP capable email-account somewhere else?

Yes, at least to begin with, we are not providing people with domains or e-mail addresses. IMAP, POP3, or run your own SMTP server...

sigh … I already have email clients that do PGP on my email that is hosted on Someone Else's Computer. It doesn't seem like Mailpile moves me a single step away from the dragnet.

When I saw the "pagekite" username on github, I immediately hoped for plug-and-play self-hosted IMAP/SMTP. Here is what I envisioned in the blissfully ignorant moments until I read what the project was actually about:

The user gets to download/buy a USB stick image / raspberry pi SD image. After plugging it into a pi or other box and turning that on, user types in the URL "mailpile" on their laptop web browser and on first run, user gets asked by web app to plug in a big harddrive for storing email on[1]. The box runs some IMAP server (dovecot?), connected to some MTA that does TLS (postfix?). The user has paid for an already setup domain name, kept in sync with the IP address of that box (which runs a dyndns-like daemon), user also gets access to some server that relays SMTP without breaking TLS (since most mail servers will not accept SMTP from just any dynamic IP). So on first run, the user also has to enter the credentials for the service they paid for, these credentials are used to let the box get its SSL key signed by the CA, tell the dyndns service that this box gets to update this domain name etc.

Now if two users run this, they don't even need PGP to communicate in an encrypted way, it looks just like any other sent email. Nor can anyone requisition their mail without breaking into their house.

So the paid service would be to get a dyndns-updatable domain name with SSL, and access to some server that relays SMTP. The service would have to dole out domain names and either be a CA itself, or be able to intermediate in the SSL key signing process.

[1] For bonus points, dejadup runs there and user gets to say "send encrypted backups to dropbox/some ssh account/some other USB drive"

Re: Mailpile: Let’s take email back

#202

Post by alextingle » Sun, Aug 04, 2013, 8:42 AM UTC

HerraBRE wrote: post #70

rpdillon wrote: post #59

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 r…

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 hav…

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.

Re: Mailpile: Let’s take email back

#203

Post by Nux » Sun, Aug 04, 2013, 8:50 AM UTC

rufugee wrote: post #29

I just switched back to Zimbra (also open source) after years with Google Apps. It's been a spectacular experience so far, and it's nice to have email fell like email again (not to mention being in full control).. It has everything I need: a rich web client, good smartphone phone support, good spam filtering, and a good community.

+1 for Zimbra as well, is a very nice Exchange replacement! Having said that, Zimbra was just acquired recently (yes, AGAIN) and this fact makes me nervous, not sure whether to despair or rejoice.[1]

Mailpipe, if it ever happens, should help a lot getting some of that mail from the claws of Gmail and the likes. They can have my money.

[1] - https://blog.zimbra.com/blog/archives/2013/07/telligent-acqu...

Re: Mailpile: Let’s take email back

#204

Post by alextingle » Sun, Aug 04, 2013, 9:01 AM UTC

sorbits wrote: post #128

They talk about privacy, but MTAs like Postfix can already encrypt mail via TLS when moving it to another host¹. GPG gives us a better guarantee, but more user overhead, and unreadable by many recipients. Additionally SPF gives us a way to check if the sender address has been forged. GPG signing is more robust, but again, more user overhead. Not to mention, I already have S/MIME support in my mail application and can…

Exim can announce TLS to all comers. Set the tls_advertise_hosts option to '*'. (I believe Debian sets this by default.)

http://www.exim.org/exim-html-current/doc/html/spec_html/ch-...

Re: Mailpile: Let’s take email back

#205

Post by alextingle » Sun, Aug 04, 2013, 9:11 AM UTC

jspaetzel wrote: post #141

mkl wrote: post #26

Earlier quoted context omitted.

"Mailpile is a modern web-mail you run on your own computer." I think this sentence should be the first thing anyone sees when they go to the page. The text at the moment assumes everyone already knows roughly what Mailpile is, so I didn't figure it out until I read HN comments. Also, are there screenshots somewhere?

I think that this sentence needs to be gotten rid of completely. - Webmail is fundamentally not something that can run on your own computer. The word is "web" mail, not desktop mail, it's just going to confuse users. In addition to it being confusing, because of dynamic IPs and residential port blocking you may be able to run it on your computer, you just won't be able to do anything with it due to other internet inf…

> Sending mail from home is almost guaranteed to fail...

It's an MUA - it can sent mail just as well as any other MUA. Use your ISP's smarthost if you are using it from home.

> Webmail is fundamentally not something that can run on your own computer.

This statement is plain wrong, even if by "your own computer" you really mean "your desktop box". I can run any server I like on my desktop box. If it has a well designed installer, then it would be as easy to set up as a "normal" app - the end user might not ever know the technical details.

> The word is "web" mail, not desktop mail, it's just going to confuse users.

Now I do agree with you. The product seems to be a little bit of both, so there is some potential for confusion. "Web-mail you run on your own computer" does seem to explain it pretty well though.

Re: Mailpile: Let’s take email back

#206

Post by alextingle » Sun, Aug 04, 2013, 9:14 AM UTC

HerraBRE wrote: post #37

guygurari wrote: post #28

Earlier quoted context omitted.

I applaud your efforts! I did not see mobile mentioned. Will there be a mobile-friendly version of the web client? Will there be IMAP access from (e.g.) mobile devices? (Under 'Current Features' you mention IMAP, but I did not understand if this refers to you acting as an IMAP client or server.) By the way, there seems to be a copy-paste typo in the description for 'Spam Detection'; it reads 'PGP encryption and verif…

Yes, making the web mobile friendly is definitely on the list of things to do. Native apps may come later, once the APIs have stabalized a bit. The current IMAP support is functioning as an IMAP client, we haven't started work on the server side yet. And thanks for the typo report :)

Why would this MUA need to behave as an IMAP server?

Re: Mailpile: Let’s take email back

#207

Post by alextingle » Sun, Aug 04, 2013, 9:18 AM UTC

beachstartup wrote: post #52

HerraBRE wrote: post #39

Earlier quoted context omitted.

It is a custom search engine, written in Python. It works surprisingly well, most queries are answered under 200ms and tens of milliseconds are common once caches are warm.

any plans for a solr support? there's a lot of knowledge out there on how to scale solr for large webmail deployments like i.e. inside a large company or for forensic mail analysis.

Solr is written in Java. How is that compatible with something that's hassle-free for end users?

Re: Mailpile: Let’s take email back

#208

Post by alextingle » Sun, Aug 04, 2013, 9:26 AM UTC

HerraBRE wrote: post #40

jeffbr13 wrote: post #9

Earlier quoted context omitted.

And what would be your approach to spam-filtering? One of Google Mail's strengths is that it can use data from millions of accounts' emails to train its spam-filter. Do you see Mailpile offering some way to do the same thing in the future, with clients flagging spam and the result being used to train a 'community' filter?

This is still largely an open question. But there are some interesting possibilities for those who actually make their Mailpile visible on the public web - Mailpiles could talk to each other and exchange data of this sort. But ideally things like this would be a community effort shared between projects and we would join, not necessarily lead.

If encrypted & signed mail becomes common enough, then I suspect the spam problem goes away. I suspect spammers won't want to sign their mail, and if they do, it would be trivial to distrust new public keys and maintain a global blacklist of bad established ones. Then almost all encrypted mail can be simply trusted, and spam filtering only has to pick out the occasional real message from the unencrypted dross.

Re: Mailpile: Let’s take email back

#209

Post by alextingle » Sun, Aug 04, 2013, 9:36 AM UTC

oakaz wrote: post #179

icebraining wrote: post #178

Earlier quoted context omitted.

Criticizing Google doesn't "hurt my feeling". I've moved away from Gmail and other Google services (not all) a few years ago because I disagreed with their options. But that doesn't mean I have to agree with nonsensical claims such as Google having a monopoly on email. Maybe they do on Silicon Valley, but I'm sure you realize that's a pretty insignificant subset of email users.

I believe we aren't in the same planet.

You sound like you're getting pretty emotional. Time for a cup of tea and a sit down?

Re: Mailpile: Let’s take email back

#210

Post by icebraining » Sun, Aug 04, 2013, 9:36 AM UTC

binarycrusader wrote: post #200

icebraining wrote: post #166

Earlier quoted context omitted.

Ugh, why? You're just discouraging people from contributing by forcing them to accept that their code might be used in a matter they don't approve of in the future.

Because it prevents a choice of more liberal licensing later. Ogre3D was able to successfully transition from LGPL to MID/BSD because of contributor agreements. The Apache Software Foundation, Free Software Foundation, and others all require contributor agreements for very good reasons. If your projects starts out with very liberal licensing, it's not necessary strictly speaking (unless you're concerned about patents…

Yeah, but the Apache Foundation already has a permissive license, and nobody expects the FSF to re-license a project, except maybe to a new version of the same.

By choosing the (A)GPL but forcing contributors to grant relicensing rights, you've excluded both those who consider copyleft licenses non-free, and those who consider copyleft licensing an important requirement.