Mailpile
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Einarsson, Bjarni Rúnar
Mailpile is the new kid on the block in the world of F/LOSS e-mail clients. This talk introduces Mailpile from a F/LOSS hacker's perspective, going briefly into the motivation of the project before delving into demos and technical implementation details. Mailpile is a Free and Open Source Software e-mail client which raised over $163,000 USD last September (on IndieGoGo and Bitcoin) to support development of the first version of the software. Mailpile is built around a powerful search engine and uses web technology for the user interface, hoping to rival GMail and other popular web-mail services when it comes to both usability and speed. The project places a strong emphasis on privacy and decentralization and is integrating GPG encryption as a core feature of the user interface. Written in Python and using modern web technology for the user interface, Mailpile aims to very accesible and easy for F/LOSS hackers to tweak and explore. This talk will serve as an introduction both for potential end users and for folks interested in helping us reboot the world of Free Software e-mail.
 Welcome with me, Bjarni Uruna Einassen. He will present MailPile. And let's go, I think. Can you guys hear me? Thank you. Hi. This is a brief introduction to who I am, what my qualifications are. Just a bachelor's in computer science. Not a lot of education, but I've been doing Linux and stuff since the early days. And free software has been my passion for a very long time. As a result, I decided to dedicate myself to it full time in 2010. And I've managed to pull that off one way or another. My latest project, and project that I'm working with Brennan and Smowdy and a nice community of people on, is called MailPile. And in brief, MailPile is an email client. There's been some confusion. We're using web-based technology for the user interface. So some people think maybe it's a server. But no, it's not a mail server, it is a mail client. It's built on web-based technology, so we can use modern web design to make it look nice and make it accessible. It has a powerful search engine, which is actually how the project got started. And we're hoping to make it really easy for people to use PGP, both to sign and encrypt email. Obviously, free software. We're currently in a weird dual licensing phase, where the code is available under two licenses. We plan to drop one of those when our community has voted on what they prefer. And it's written in popular languages, Python and JavaScript. I say it's a project to take email back. And that's sort of what I'm going to be talking about in the first half of this talk, is sort of the motivation and history of the project. Not a long history, so it won't be a long talk. And then in the second half, I'm going to go into some of the technical details, because I know you guys are all techies, and that's what you're interested in. So why another email client? I don't mean to offend anyone, but I feel like the state of free software email has been pretty crap for a while. There's not been a lot of development, and things are... The way we're doing things is kind of stuck in the 90s. And I feel like we need to catch up, because if the free software community is going to compete with Gmail and compete with Microsoft, we need to innovate and we need to provide a better experience to our users. And we just haven't been doing a good job at that. And if we don't, then we will never have mass encryption of email. Email will always be written on the back of a postcard while we're trusting the cloud and while we're using proprietary software. So this is important. Email has been becoming increasingly centralized, in my opinion. People these days, when they think of email, they just sort of assume that it's Gmail or Hotmail. They just assume that it's somewhere running on someone else's hardware. A lot of companies don't bother running mail servers anymore. And a lot of schools don't bother running mail servers anymore. Government organizations don't bother running mail servers anymore. And I think this is a bad trend. But it's going to continue if we don't provide better software. I don't like having email in the cloud filtering my spam for me, because I consider that to be a form of censorship. I would like to have a nice spam filter running on my machine, but that means I have all the data and I can find it if it gets lost. If Google filters something away, I have no idea why. I don't even know what happened. But they provide good service. It's very cheap. All you have to do is pay for it with your privacy. And Edward Snowden has explained one facet of why that's a bad thing. Evan Moglin has talked about this, and Richard Stallman has been talking about this for a long time, but it's not really cool to listen to him anymore, is it? But he's right. Stuff in the cloud, when other people are running things for us, that's worse for our freedoms than closed sources. So I like to piss people off by saying that now Microsoft is our ally, and Google is our enemy. Because honestly, at least Microsoft is letting you run the software yourself. When you put the stuff in the cloud, then they have your data. They will very easily lock you in. It's very hard to move. You have this sort of natural monopoly effect that you've seen. The biggest provider always seems to win. Everyone gravitates there. It's a massive centralized silos of data, and it's terrible for privacy, and it's bad for a lot of things. There's also a risk of something which some people in the room are old enough to remember. Do you guys remember Microsoft's strategy of embrace, extend, extinguish? Show of hands. Oh, great. It's a good crowd. So for the rest of you, this is what Microsoft tried to do to the open web. So they said, hey, this web thing is kind of neat. Let's give everyone a free browser. And you know, in turn explorer, it wasn't a bad browser. It was nice. But it came with this thing called ActiveX. And they encouraged developers in the Microsoft ecosystem to use ActiveX to make their websites more appealing, make them sort of, you know, cool and fancy and do neat things. So they extended the web using proprietary technology. And they were hoping that by doing so, enough websites would move to using their proprietary version of the web that they would kill the open web. Because nobody else had ActiveX, and it was a closed technology. There's a risk of this happening with things like email if we let the cloud run it for us. And we've already seen sort of very small hints of things moving in this direction. And I'm sorry to pick on Google, because I used to work there and they're nice guys, but the example I have does come from Gmail. Gmail has started to add features where if you send messages that are formatted in a particular way, and you're a Google partner, then buttons might show up in the email. You might be able to buy something within your email client. And you'll be able to do stuff that you won't be able to do with any other mail client. So they started to extend email and make it into something that it never was before, and make it into something that is definitely not an open standard, and is not interoperable with the rest of the ecosystem. So this is happening, and it's something that we should be aware of. And then of course, email in the cloud is fundamentally incompatible with encryption. And the reason for that is these cloud providers, they all base their businesses on advertising, and they need to be able to target those ads, and they can't target those ads if they can't read the content of your email. So if they don't know what you're talking about, they can't show you relevant advertisements, they won't make any money. So they're never going to encrypt your mail. Aside from the fact that giving them all the keys is a bad idea, they're just not going to do it. So I was worried about this, a bunch of other people worried about this. So we came up with this idea, let's build MailPile, and let's do it a little bit strategically. We want to achieve five things. We want to make software that the free software community enjoys hacking on. You guys like to play with something that's accessible to the community. We want to build software that regular people want to use. So it has to be attractive and user-friendly and fast at all of those things that we expect from good software. We want to make email encryption understandable, so people will do it without thinking about it. It can't be something that just the techies do, it has to be something everyone can do. And we want to make it easy to decentralize. We want to make it easy for people to take their data back, make it easy for people to run their own infrastructure, and move out of the cloud as much as possible. And even if not everyone does this, this will have a noticeable benefit to the overall tech community, because it'll keep the cloud guys honest. If people can leave, then they will be kept honest. And finally, we need to find better business models, because one of the Achilles heels of the free software community is so much work is done by volunteers, and we have very limited resources. We need to figure out ways to actually do this as a full-time job. So this is the sort of stuff that we're thinking about in MailPile. Timeline of the project so far. In 2011, I wrote an experimental search engine. I was able to search all my email in milliseconds. It was great. And then I went back to my regular job. Kept doing what I was doing. Nothing happened in 2012, so there was no slide. But in 2013, things started to happen. My friend Smowdy had been harassing me and saying, hey, let's do something with this MailPile thing. It's kind of cool. I'm using Thunderbird, and I don't like it. I want something better. And I kept saying, go away. I'm doing my job here. But we bumped into Brennan, who is a user interface designer. We bumped into him in the hot tub at one of the pools in downtown Reykjavik. Had a nice chat. Didn't think any more of it. Bumped into him again at a cafe. I think he was following us. You were, weren't you? We had some coffee. We had some beer. He looked over my shoulder and was like, what are you working on? I'm playing with this email thing. And 10 minutes later, he made a logo for the project, and we're still using it. So we decided to join forces. We came up with this plan, and we decided to do a fundraising campaign. So we raised, we did an Indiegogo fundraising campaign, launched in August. We launched at the Ohm Festival in Netherlands, which was fantastic. And we succeeded. We raised enough money that we can work on this full time for a year. And actually a little bit extra. I think we're going to manage, swing current budget suggests we'll get 16, 17, 18 months out of, out of that. Depends a bit how Bitcoin develops. If Bitcoin keeps going up, then we'll get a few months that way. But, you know, since, since September, we've just had our heads down. We've been writing code. We've gone to a couple of conferences to talk, but for the most part, we've just been working. And 2014, we realized, well, you know, we have to keep some of those promises we made back in August. So we've mailed out most of the things that we promised to people that backed us. We mailed out shirts and stickers and some rocks as well. People that paid enough money got Icelandic rocks. And we're announcing our first milestone here at FOSDEM, which is, the alpha version of it. And we're one day late. Because, you know, it's a real software project. They're never on time. So what's the, what's in the alpha? The highlight of the alpha is that this is not vaporware. We actually are writing software. You can download it and you can play with it. And a big part of, a big part of what we're doing is trying to prove that you can actually crowdfund stuff like this. And it's not a risk. So keeping our promises is really important. We have a nice HTML5-based user interface. We have a fast search engine, which is not based on that much. And we'll discuss why later. We have basic support for PGP encryption signatures. It's a bit clunky. It's new, but it's there. We have spam filtering based on the spam Bayesian filter system. And we have over 30 volunteers translating mailpile into their local languages, which we think is just fantastic. Lowlights. We have to have some lowlights to balance off the highlights. This is an alpha. Don't expect it to work. Or, you know, don't expect it to work well. It's tricky to install and configure. At the moment, it is still very much for developers. We don't have IMAP and POP3 support integrated yet. And the reason for that is I haven't, but we haven't sort of figured out how we're going to store all that data because one of the things you want to do is make sure things are stored encrypted. And we need to think about how we do that. We don't have support for S-MIME. I don't know if anyone cares, but it was on the list of things we talked about. And we don't have a compelling story about how we're going to do PGP key management yet. So handling keys expiring and keys being revoked and all that stuff. We need to put a UI on that that doesn't kill the normal user. And that's going to be tricky. There's lots of stuff, there's lots of work to do still. You can get the source code. You can clone the alpha release. And from this point on, we're going to try and keep that branch sort of stable for people who just want to look at it. And we'll break shit and make things messy on the main branch. We have live demos. Because one of the things that we face here is we're backed by over 3,000 people, most of which are not particularly technical. So they're not going to be able to download the source code from GitHub. So we put some effort into making sure demos were up so they could go and see it and play with it. And they know what we're working on. And of course, I encourage all of you to check them out as well. Oh, maybe I'll do it myself. Demo. So let's see if this... Do we have a new website? I'm refreshed. Oh, hard refresh. Well, I don't know if I even have internet actually. Let's see if that works. So this is the intermission of my talk. I'm going to do a little demo, show you what it looks like, and then I'm going to go through talking about some of the technical implementations. And I may use up all of my time and then some, so I'm going to count on them to stop me, and I will stop so we can take some questions. Oh, look. My pile is now in alpha. So, demo. Demo. This is our demo page. And we can try it. So for the sysadmins in the room, we are running this on four VPSs that... Oh, why? Try the dual stack. Try the dual stack network. Okay. How's the dual stack? Well, if this doesn't work, I just run it off localhost, so that's how we do it most of the time anyway. This is what the demo is supposed to look like. It's an email client. It's not going to do anything if I click on it, because that's a live one. This is my personal mail, which is using a different... I think I've got it zoomed out. There we go. We can make it, you know, bigger. I think. I don't know, did that break too? The demo effect is teasing us today. But if I read an email, you can read about Media Goblin, which is kind of cool. So you can read messages. You can see my cursor there. Here at the top, we have some icons. These are going to signify the state of encryption, so whether the message is signed or encrypted. See, it pops up a tooltip to explain what's going on. This is the first draft. We're going to be improving this interface over time, but we have some things. I can click on reply here. I can try and encrypt it, but it says there's an error, and the reason being I don't have the key for the recipient. Let's see if details work. Yeah, see, here I can try removing Chris, because he doesn't have a key. I'll just send my reply to Smody. And now... Oh, it still can't encrypt. That's a bug. And now, it's encrypted. It's encrypted. It's encrypted. And now, it's encrypted. So this is what we're trying to do. We're trying to make it really easy. And one of the ideas is that if we know that we have a key for the person that we're communicating with, it will suggest that the mail be encrypted by default. And we know that's going to cause problems, because a lot of us are using multiple devices, and one of them can actually decrypt mail. So we're also looking at ways to communicate preferences, so that you can... If we see that we always get encrypted mail from this person, we're always get signed mail, then it's safe to encrypt. But if sometimes we get a message that's not, maybe our default policy for that recipient is to just sign. That's stuff that we need to work on. This is a search engine. I could search for Linux, Iceland, conference. Let's see if I have any email about that. So my mailbox has about 160,000 messages in it. And this is running on a relatively crappy laptop with a spinning disk. That was reasonably fast, right? This is what we're doing. It shows tags here. These are all tagged with inbox. I can browse the tag. It's trying to show the conversations. I think if I do that, it will filter it and only show me the ones I haven't bothered reading yet. So it's an email client. It's making progress. We have a view of contacts. So right here, this is pulling contacts out of my GPG keychain. And one of the sort of core ideas we have is we want to integrate key management with contact management. So there shouldn't really be a difference. You shouldn't have to go to some separate application to manage your keys. You should be able to manage them along with everything else to do with the contacts. So yeah, and we are pulling pictures of people down from gravatar. That's where those images come from. We'd like to pull pictures from other sources. We'd like to grab them from Facebook if we can, but I don't know if that's going to work. How about card dav? That would be cool. We have various plugins for importing. So I'm going to repeat the question. He asked how about card dav. And we have various plugins for pulling in contacts from other sources as well. We can pull in contacts from the Mork database, which is how Thunderbird stores its contacts. And we have a card dav plugin. I haven't tried it myself. But these things are all under development, but they're definitely going to happen. And you can help. Let's see. Here should be a list of my tags. It gives me some stats. Here's where we bank for money so we can keep working on this. Please, please send us all your money. It'll be great. So that's the web interface in a nutshell. But because I know I have a room full of techies here. What about keyboard? Shortcuts? Not yet. We definitely have them soon. It's just a matter of time. We do one thing at a time. So the back end to this is, this is written as a search engine. And every time you hit an API, it's written as a REST API. Every time you hit an endpoint, you'll get JSON back. So you can actually just request that instead of looking at the inbox of HTML. So this is the same data, a lot of data actually. This is all the information about those search results that were visible. So it's got these big blobs here of that there. That's actually someone's thumbnail, an image. It's pulling back a lot of stuff. So you can interact with this programmatically. And we're hoping that will lead to some interesting sort of plug-in type thing. Question there? What was the most commonly implemented code that reads the Malk database? Smale did that. I think he pulled code from somewhere. I based it off of Python translation of the code script from way back when. I'm going to repeat that for posterity. You based it on a Python translation of Perl script. Apparently, it's ugly. Yeah, I showed you guys the composer, the full composer. I showed you the reply one. So this is what the full composer looks like. It has the same attributes as the other. I can choose profiles. I can say I don't want to sign this message and search for people. And this is searching in my personal, you know, list of addresses. Any address that I see is an incoming mail. It shows up as a suggestion there. And the ones that actually have keys, as I said, they get a little lock. Hopefully that will encourage people to use those ones instead of the others. So, slightly geekier demo if I go for this one here. This is the command line interface to MailPython. How? No. How? It's got a bunch of commands. You can search for things. So, I'm going to go for this. So, scary messages. So, there's various things that you can do. It's a relatively powerful search engine. Could you repeat the question? Yes. So, I'm actually going to get into that in a moment. But he's asking if all these mails were offline if they were stored locally. And yes, we are encouraging people to store things locally. We want to take things out of the cloud and decentralize. That's one of the goals. So, yeah. But I know people want to sync with iMac. We just have to go through how we do that in the same way. So, I'm going to go back to my slides and tell you all about the technology behind this. Or some. How does MailPython work? This is your chance to run away and escape. So, the overall architecture of the project. The grinding principles are, this is free software. We're going to use open standards. And we are proponents of decentralization. So, we believe users should own their own data. And we should help them do so. Searching is a critical feature. It's not enough that people have to organize all their mail into folders. Because even a regular user has thousands of messages. And someone like me who's been on the internet for, you know, well over a decade has a couple hundred thousand. How does searching with encrypted mail? I'll get to that in a bit. So, I'm going to go back to my slides. I'm going to go back to my slides. I'm going to go back to my slides. And I'll start by answering that. Our main user interface is the Web. We're going to allow for alternate ones, as well. We want to encrypt by default whenever possible. And we have the expectation that our end users are not the people in this room. They're non-technical people. People sometimes ask me who I'm writing the software for. And I would like this software to be the answer to the question. When someone comes to me and says, I'm worried about my privacy, what can I do? I'm worried about my privacy, what can I do? Because today, we don't have a good answer to that. Someone comes and says, I want my email to be private. We're going to say, install Thunderbird, learn to use Enigmail, and that's kind of hard to do. And Thunderbird isn't even being maintained anymore. So actually, it is being maintained, but it's not being actively developed. Getting into the code, we have a Python core, which is where we handle things like the configuration. Search Engine is part of the core. Reading and writing and sending email is part of the core. Crypto, the HTTP server, and we have a plug-in architecture. It's not stable yet, but we do want to be able to develop those things as plugins. And we're already doing so. We support multiple mailbox formats, and that's starting to become pluggable. Importing contact, as I said, that was written as a plug-in from day one. Setup and systems integration. So when you install MailPile in a new machine, and it goes, and it finds your mail.app, and it finds your settings, and it figures out what to do, that would be plugins that people write for different operating systems. And we have plugins that allow you to tweak the search engine itself. So you can teach the search engine to read your mail and create new keywords, or to create complex queries based on something that makes sense to you. We have a web API. I touched on that briefly in the demo, where you can get things back as data in JSON. So most of the URLs that people see in the web browser, they map directly to a Python method. And that Python method, by default, if you hit, as an API endpoint, returns JSON. If you hit it using the regular interface, it'll give you HTML. But we also provide HTML, which is embedded in JSON, which is useful for doing AJAX-y-type things. And there's plain text. And we might do XML or whatever if there's a demand for it. The HTML that we do render is rendered using the JINJA 2 templating engine. The interface itself, there we're using HTML5 APIs. We're using jQuery, Bootstrap, LES, and all the modern tools. We want to do progressive enhancement. We would like the site to work without JavaScript. It doesn't quite do that yet, but you can use it in a read-only mode. And we want to have responsive design so it scales to different size screens and mobile devices and so forth. Because honestly, it's going to be a while before someone develops a mail pile app for your phone. But we want the web interface to at least look nice in a phone if you've exposed your mail pile to the public web. And it will be female-able and skinnable for people that want to do that. There's some alternate interfaces to the app. I showed you the command line very briefly. There's also a Python interface where you can say import mail pile and instantiate a mail pile instance and interact with it programmatically. We use that for testing. And it could be used for various other weird things. We might support XMLRPC just because that's really easy to do in Python. I would love it if someone ported the user interface of MUT so I could use it on MailPile. That would be cool. And details. How does it work? So I get the question, why are we not using x, y, or z all the time? Why did we write our own search engine? And the honest answer is, because that's how the project started. I was just curious, can I write a search engine? So I went and I did. And it works, and it's fast. And it's under 1,600 lines of code at the moment. I don't really feel any need to change. The other benefit I see to this is that it's very, very simple. I can explain it to you now how it works. And you'll understand it. And I consider that to be a huge benefit. And I don't have that visibility into other tools. We want to do things like we want to make sure that this gives people a good experience that's customized for email. We want to be sure that we're storing all of the data encrypted on disk. We want to have a lot of control over how this behaves. So having a simple, small code base that we wrote ourselves is very appealing. And it also means we don't have another dependency when we start packaging this and shipping to users. So how does it work? Mailpal reads your mail. Out of the message, it'll generate an ID for it. It will extract some metadata, things like the subject, the recipients who sent it, size of the message, that kind of thing. And it will extract a bunch of keywords, which are the things that you can actually search for. It will then create posting lists. These are basically maps that map a keyword to a set of message IDs. These are just very simple files. They just have a list of keywords. And then there's a map to some IDs. And there's a metadata index, which maps these same IDs to the metadata, which tells you something about that message. Metadata index is something that I store in RAM. And that was realizing that I could do this, realizing that email was now small enough, and our computers are now powerful enough, that I can put all that data in RAM and nobody's going to notice. That's what started this project. Because when you can do that, all of a sudden, everything becomes really fast. Because most search queries can be answered by opening one small file, reading it, and then looking up all the other data in RAM. That means I can answer any search query under 200 milliseconds on crappy hardware. If you have good hardware, it just gets faster. This is how you would implement this if you were writing code yourself. My implementation, get the message IDs for a given keyword. You generate a file name by hashing the keyword. You open it up. You parse it. And you return a set. In reality, I'm grouping some of the keywords together so I don't have an infinite number of files. And there are some problems to this. So adding things is easy. Deleting them means I have to go and open all the files and remove stuff. So that's a bit messy. The metadata index, it looks like that. It's just a dictionary. It has an ID, and it maps to a bunch of attributes. What we put in the metadata index is all of the data that we need to generate search results. So when you search for a potato, I get back a list of messages. And I can find the subject lines, senders, all the details I need to show you the list. So I can show you the list immediately. And that's how we get a good experience when you're searching. The metadata we're currently storing encrypted on disk, GBG encrypted. Posting lists are not yet encrypted, but they will be. So putting those two things together, that's a five line search engine. Start with a set of all of the message IDs that exist for each keyword in the query. You narrow down the set. You just look up the message IDs that match that query, and you do a set intersection. Then when you've done that for all of the terms that people are searching for, you go through the results, and you print them out. That's the core of the search engine right there. So building on top of this, we added tags, which are similar to the labels that are in Gmail. And these are basically search terms where you can edit the result set. So you can add and remove message IDs to this keyword. And that allows you to do all sorts of things. That means you can create an inbox, and you can mark certain messages unread, or spam, or whatever. And now we have things that do that automatically. So you have filters, and this allows you to start organizing your email in a structured way. We have plugins, as I mentioned before. This allows you to make new rules for how to generate keywords. I'm really hoping someone will write a plugin to parse PDF files and extract the text, so I can search for those as well. Someone could write a plugin that understands the grammar of their language, or that understands their particular field of specialization. Something that parses. One thing that would be cool is to parse messages that come from Ryanair and come from EasyJet and extract the information about the flight, and make that into a search keyword. There's a lot of things that can be done there. And then there's the other side. So instead of generating keywords, you can create sort of magic keywords that are dynamic. The way you search for dates is implemented as one of these plugins. So you can search for dates that arrange 2010 to 2014. That's not a keyword. But I can create keywords out of that. And that's what this plugin does. It'll actually tell you to search for date 2010, or date 2011, or date 2012. That kind of thing. And of course, plugins can also just use a search engine to generate interesting views, figure out things about your email. Tricky bits, building a search engine like this is mostly to do with actually reading the mail and generating useful terms. So which keywords we put in the index and which keywords we don't. And then, of course, there's the constant optimization battle to make it fast, to make it not too big, and so forth, and so on. Works in progress. We are not able to delete things from the search index right now. That's a bit of a limitation. We'll fix it. The encryption needs work. Why security people tell me that it's not good enough as it is. And it would be nice to have a better query language. The current query language is pretty stupid. So I'm going to pause, actually. Do people have questions about the search engine before I move on? You have a question. So the question from the guy earlier was what about encrypted emails? How do you search those? Oh, yeah. That's in the crypto talk. Yeah. Those are decrypted. So the question is, what do we do about encrypted mail? And the answer is, if you tell mail pilots allowed to, and this has to be a setting because not everyone is comfortable, mail pile will just decrypt your email when it sees it. It'll index it just like anything else. And that's one of the reasons that the search index needs to be kept secure. Because I believe that encrypted email will not be usable unless you can search in it. So this feature needs to work. But in order to do so, we need to be able to encrypt the search index. We need to be able to encrypt the metadata. We need to do so in a way so that we're not leaking the contents of these private messages. Anything on over there? I saw you mentioned auto-tagging. Do you have some kind of crazy classification based on the type you already made? I'm about to talk about that. But yes. Up there? It's not about search, but are you amazing at each one? Actually, if it's not about search, let's do it afterwards. OK. I'll try and leave some time. How am I for time? Oh. OK, well. That means that we don't talk about crypto. But let's talk about spam filtering, because it's cool. So how does it work? Mailpile spam filters are based on statistical analysis of the mail. So we want to have engines that read the mail and give us some sort of result. By default, we're using spam base. Messages that match our auto-tag with a spam tag. And then messages that have that tag are by default hidden from search results. So the spam isn't in your face. We train the base in engine by looking at the user's behavior. So going in a little deeper, statistical analysis, is trying to answer the question, what is spam to you? Because not everyone has the same spam, and not everyone has the same idea about what is spam. We do that by feeding the same keywords as going to the search engine into a Bayesian filter. And it will then hopefully be able to classify the mail into its spam, or it might be spam, or it's definitely not spam. And by default, we use spam base. The training is the important part. If we get this wrong, then the spam filter will perform very poorly. And this is where we need to work a bit more. But what we're trying to do is we're looking at how the user interacts with their mail. So if you take a message and you drag it to the spam folder, that's a pretty clear signal that that's spam. And if you read a message and then you reply to it, that's a pretty clear message that that message was not spam. So we're using things like that to assemble a corpus of messages for training. And my vision for doing this is I want to train on a relatively frequently, because I believe that both your communication patterns and the patterns of spam are going to change over time. So I do not expect your spam filter to match your spam from two years ago, but I would like it to match the spam you're getting this week. So Mailpile is tracking these actions. When you click on a message and read it, that message gets tagged as having been read. When you reply to a message, it gets tagged as this message was replied to. And when you manually organize things, you move them from one tag to another, it tracks that as well. And that allows us to choose messages for training. We also have bacon filters. Turns out nothing that I just said has anything to do with spam. It's just how you organize your mail. So what we're interested in doing is using the exact same plugin and the exact same code and use spam base as a general purpose MailClassifier. So you can go to some tag that you've just created. So this is the FOSDEM tag. And you can just click Auto Tag. And then over time, you put some messages in that tag, you haven't put other messages in. Mailpile should be able to learn which messages belong under the FOSDEM tag and do that for you. I hope it works. I think it's cool. I think yes, I think I am. OK. Should I go through one more? This one's kind of long. I think you will want that one. OK. Last talk here. Yeah. Did anyone want to ask about the spam stuff? Yes. Basically, the baseline expectation from users is going to be the Google experience in spam filtering. But of course, because you're only using one mailbox, your focus is way smaller than whatever Google is using. And so you don't have to cross benefits. And so I'm wondering, is Baze actually still working against the modern spam? So the question is whether Baze is actually good enough on its own. And you raised the question of whether we'll be able to compete with people like Google that have access to lots of other people's mail and can cross correlate. Time will tell. But people, I think Smode has been using Thunderbird and its Baze and spam filter for a while, and he's really happy with it. But this is an area where I do expect that we're going to need to iterate and develop. And if necessary, it might be interesting to look into ways that users can collaborate and share details in a decentralized way. But I mean, that's a big hand-wavy project, so I'm not going to promise that we're going to do that. But yeah, this is a valid question, and I don't really have a clear answer for it. Yeah? It's been a good question. What if Spammer starts GPG encrypting the spam email sending to you, and then you won't be able to do the spam filtering until the user opens the email message because then he encrypts it? So I think what you're asking is what happens when Spammer starts encrypting their mail? At that point, we win, because at that point, Google can't filter it, but we can, because we're doing the spam processing after the mail has been decrypted. So that's one of the reasons that in an encrypted world, you need to move the spam filter out to the edges to where the users are. Yes? That's an administrator. That's an administrator, as sometimes we see mail forwarded by users who get frightened by spam and wonder, oh, how should I react to this? So for one, it's not always an indication of actually a ham. Somebody asked, what is this? Yeah, that's true. What that actually means, though, is that that's an interesting message. The odds are the user is going to forward that to you, but he's also going to put it in a spam folder. And that means I have a very strong signal that that was interesting spam. And you know, I'm perfectly happy with that. It works both ways. So I'm going to move along, talk about crypto. There's one up there. How can a friend of mine benefit from my training? You're asking, how can a friend of yours benefit from your spam training? I'm not sure. I'm not sure that he can. It depends on whether your spam is similar enough to his. And one of the things that we need to look into before we ship this is whether there's value to building a sort of generic pre-trained filter and shipping that, and then having that learn over time. And how we would do that. But that's something that we don't even start looking at until next summer or even later. But it's a good question. I don't know. So crypto. Where should we do crypto? I'm not going to say we do because it's not all implemented yet, but this is what we're talking about. We want to encrypt the data at rest. So all the data that MailPile generates should be stored in a safe way. I know some people have full disconcription, but not everyone does. I would like people to be able to store their MailPiles on USB sticks and just carry them around. There's many reasons for doing this. We're using crypto when we're reading, writing, and sending mail. We're using HTTPS, obviously, wherever appropriate. We would like to anonymize communication with the external network. So when MailPile goes off and downloads those images from Gravatar, it shouldn't really be telling Gravatar that I'm talking to these people. That needs to be anonymized in some way. And we might want to implement some of the proof of work hash-cache things, which relates to one of the other crypto ideas that comes up soon. Data at rest, our strategy there is to just shell out to the existing tools. We're going to use the GPG binary or the OpenSSL binary or wrapper libraries and use that to encrypt basically everything, application settings, contacts, search index, et cetera, et cetera. Using GPG is relatively slow. So we're probably only going to use that for the config file. That will then contain a key that is used for symmetric encryption via OpenSSL because OpenSSL AES encryption is quite fast. That's our strategy there. Reading email, well, there's the basics. You parse the PGP MIME. You call out the GPG to check whether the signature checks out and decrypt things as necessary. But we would like to be able to plug in other things. We would like to be able to plug in other crypto systems because the crypto community is developing all these things. And I'm not sure they have a good platform where they can actually play with them. I would like to be able to plug in some other friends, Steph. He wrote something called TBP, which is pretty bad privacy based on elliptic curves, but does similar things to GPG. And it would be cool if we could just plug that in and let people play with it. As I answered earlier, the question, decrypting can be done during the indexing phase. So encrypted messages can be searched. And when we do that, that means that we bubble up information about the state of the messages into the metadata and into the search index. So you can search for messages that have bad signatures. Or the UI can give visible feedback because everything that the UI shows you is based on what's in the metadata index. So that's important plumbing. And that is mostly working as of this month. Writing email, again, generate PGP MIME, use GPG to actually do the signing and the encrypting. We want to do best effort security. We would like to encrypt messages whenever we can. How we figure out whether we can is an open question. We'd like to sign by default. There's really no reason not to. And we need to give the user the power to change these settings, but for the most part, we want to do our best. We would like to use trust on first use, so tofu for key verification. So that's like SSH, where the first time you see the key, you just say, OK, this is probably the right key. And then you only complain if it changes in the future. And this is because the web of trust is very complicated. I'm not sure we can put a user interface on that, to be honest. And the web of trust is also leaking private information. The web of trust is revealing to anyone who cares to look who's talking to whom and who knows who and how we're connected. And a lot of people consider that to be such a massive privacy problem that it just should not be used. So this is how we're heading right now. You're welcome to talk us out of it. We'll listen to feedback. But this is what we're talking about at the moment. And we're probably going to distribute keys in an ad Hoc way, including just attaching them to outgoing mail. Sending mail, that's a fun one. We should use TLS when possible. That's been an SNTP forever. And obviously, we should use it. But we also have this idea, SMTorrent, or SMTP over Tor. This is when MailPile starts becoming a MailServe. We build a very simple SNTP server into MailPile. We ship MailPile and Tor together. So an end user installs MailPile. They also get Tor. People know what Tor is, right? OK. It's an anonymity tool. It anonymizes communications. And it's also a darknet. So you can register what's called a hidden service on Tor. And people can connect to that. And the anonymity of that connection is strongly guaranteed. But what this means is you get an email address, which looks really ugly. It's your name at some long gibberish string. I think that they very helpfully made those strings longer recently, like 80 characters or something. Ends in dot onion. But what that means is that when your MailPile is connected to Tor, one MailPile can deliver email directly to another. And it doesn't have to go through any outside relays. It never leaves the encrypted Tor network. And we have suddenly closed the metadata leak that people are complaining about with SMTP, where the NSA is just listening to who is sending little messages all the time. Because a lot of the time that happens in the clear. And this is a different problem from the lack of encryption of message headers in PTP. This is the actual SMTP dialogue, where you say mail from somebody, RCPT to somebody else. That's always in the clear unless people are using TLS. And TLS is not widely deployed. We're not widely deployed enough. So this closes that leak completely. And it allows emails to suddenly become a peer-to-peer messaging protocol without inventing any new protocols. I love that. We don't invent anything. We just assemble things. So by building on SMTP, instead of inventing some new protocol, that means we can use the existing infrastructure. We could use something like PostFix or Exim or something, put that on a hidden service instead, and do relaying. If your MailPile is not online often enough for the peer-to-peer solution to work for you. Question about that. What are darkmail doing and is it relevant? I have no idea. Darkmail are the questions, what are darkmail doing and is it relevant? From what I've heard, darkmail are doing something clever with XMPP, which is Java. So in my mind, that's not really email. I don't know if they plan to be backwards compatible with the world of email. They'll just have to answer those questions. I don't know. But if they publish something, we might well implement it. If it's good, we'll implement it. But we just have to wait and see. I think this is my last crypto slide. Yes. HTTPS, that's an O-brainer. We should be using it all the time. And I would like to anonymize the traffic. By shipping with Tor, we can start downloading from Gravatar. We can download from Facebook and here and there without revealing who you're talking to. And in some cases, we will actually also be able to anonymize the outgoing S&P connections. There are providers like Gmail, which is one of the things they do really well. They explicitly allow incoming connections from Tor. And they do this because they want activists to be able to communicate. So there are some providers that are known to behave well. And we should be able to connect to them over Tor instead of going through the clear text internet and revealing data. So that's it for me. Yay, we have an alpha. Can we take some more questions? Do we have some more questions? General type. Please hands up so I can have the microphone maybe. It's like people are running away. Maybe we should gather and talk.
 Welcome with me, Bjarni Uruna Einassen.  He will present MailPile.  And let's go, I think.  Can you guys hear me?  Thank you.  Hi.  This is a brief introduction to who I am, what my qualifications are.  Just a bachelor's in computer science.  Not a lot of education, but I've been doing Linux and stuff since the early days.  And free software has been my passion for a very long time.  As a result, I decided to dedicate myself to it full time in 2010.  And I've managed to pull that off one way or another.  My latest project, and project that I'm working with Brennan and Smowdy  and a nice community of people on, is called MailPile.  And in brief, MailPile is an email client.  There's been some confusion.  We're using web-based technology for the user interface.  So some people think maybe it's a server.  But no, it's not a mail server, it is a mail client.  It's built on web-based technology, so we can use modern web design  to make it look nice and make it accessible.  It has a powerful search engine, which is actually how the project got started.  And we're hoping to make it really easy for people to use PGP,  both to sign and encrypt email.  Obviously, free software.  We're currently in a weird dual licensing phase,  where the code is available under two licenses.  We plan to drop one of those when our community has voted on what they prefer.  And it's written in popular languages, Python and JavaScript.  I say it's a project to take email back.  And that's sort of what I'm going to be talking about in the first half of this talk,  is sort of the motivation and history of the project.  Not a long history, so it won't be a long talk.  And then in the second half, I'm going to go into some of the technical details,  because I know you guys are all techies, and that's what you're interested in.  So why another email client?  I don't mean to offend anyone,  but I feel like the state of free software email has been pretty crap for a while.  There's not been a lot of development,  and things are... The way we're doing things is kind of stuck in the 90s.  And I feel like we need to catch up,  because if the free software community is going to compete with Gmail  and compete with Microsoft,  we need to innovate and we need to provide a better experience to our users.  And we just haven't been doing a good job at that.  And if we don't, then we will never have mass encryption of email.  Email will always be written on the back of a postcard  while we're trusting the cloud and while we're using proprietary software.  So this is important.  Email has been becoming increasingly centralized, in my opinion.  People these days, when they think of email,  they just sort of assume that it's Gmail or Hotmail.  They just assume that it's somewhere running on someone else's hardware.  A lot of companies don't bother running mail servers anymore.  And a lot of schools don't bother running mail servers anymore.  Government organizations don't bother running mail servers anymore.  And I think this is a bad trend.  But it's going to continue if we don't provide better software.  I don't like having email in the cloud filtering my spam for me,  because I consider that to be a form of censorship.  I would like to have a nice spam filter running on my machine,  but that means I have all the data and I can find it if it gets lost.  If Google filters something away, I have no idea why.  I don't even know what happened.  But they provide good service.  It's very cheap. All you have to do is pay for it with your privacy.  And Edward Snowden has explained one facet of why that's a bad thing.  Evan Moglin has talked about this,  and Richard Stallman has been talking about this for a long time,  but it's not really cool to listen to him anymore, is it?  But he's right.  Stuff in the cloud, when other people are running things for us,  that's worse for our freedoms than closed sources.  So I like to piss people off by saying that now Microsoft is our ally,  and Google is our enemy.  Because honestly, at least Microsoft is letting you run the software yourself.  When you put the stuff in the cloud, then they have your data.  They will very easily lock you in.  It's very hard to move.  You have this sort of natural monopoly effect that you've seen.  The biggest provider always seems to win.  Everyone gravitates there.  It's a massive centralized silos of data,  and it's terrible for privacy, and it's bad for a lot of things.  There's also a risk of something which some people in the room are old enough to remember.  Do you guys remember Microsoft's strategy of embrace, extend, extinguish?  Show of hands.  Oh, great. It's a good crowd.  So for the rest of you, this is what Microsoft tried to do to the open web.  So they said, hey, this web thing is kind of neat.  Let's give everyone a free browser.  And you know, in turn explorer, it wasn't a bad browser.  It was nice.  But it came with this thing called ActiveX.  And they encouraged developers in the Microsoft ecosystem to use ActiveX  to make their websites more appealing,  make them sort of, you know, cool and fancy and do neat things.  So they extended the web using proprietary technology.  And they were hoping that by doing so, enough websites would move  to using their proprietary version of the web that they would kill the open web.  Because nobody else had ActiveX, and it was a closed technology.  There's a risk of this happening with things like email if we let the cloud run it for us.  And we've already seen sort of very small hints of things moving in this direction.  And I'm sorry to pick on Google, because I used to work there and they're nice guys,  but the example I have does come from Gmail.  Gmail has started to add features where if you send messages that are formatted in a particular way,  and you're a Google partner, then buttons might show up in the email.  You might be able to buy something within your email client.  And you'll be able to do stuff that you won't be able to do with any other mail client.  So they started to extend email and make it into something that it never was before,  and make it into something that is definitely not an open standard,  and is not interoperable with the rest of the ecosystem.  So this is happening, and it's something that we should be aware of.  And then of course, email in the cloud is fundamentally incompatible with encryption.  And the reason for that is these cloud providers, they all base their businesses on advertising,  and they need to be able to target those ads, and they can't target those ads  if they can't read the content of your email.  So if they don't know what you're talking about, they can't show you relevant advertisements,  they won't make any money.  So they're never going to encrypt your mail.  Aside from the fact that giving them all the keys is a bad idea, they're just not going to do it.  So I was worried about this, a bunch of other people worried about this.  So we came up with this idea, let's build MailPile, and let's do it a little bit strategically.  We want to achieve five things.  We want to make software that the free software community enjoys hacking on.  You guys like to play with something that's accessible to the community.  We want to build software that regular people want to use.  So it has to be attractive and user-friendly and fast at all of those things that we expect from good software.  We want to make email encryption understandable, so people will do it without thinking about it.  It can't be something that just the techies do, it has to be something everyone can do.  And we want to make it easy to decentralize.  We want to make it easy for people to take their data back,  make it easy for people to run their own infrastructure,  and move out of the cloud as much as possible.  And even if not everyone does this, this will have a noticeable benefit to the overall tech community,  because it'll keep the cloud guys honest.  If people can leave, then they will be kept honest.  And finally, we need to find better business models, because one of the Achilles heels of the free software community  is so much work is done by volunteers, and we have very limited resources.  We need to figure out ways to actually do this as a full-time job.  So this is the sort of stuff that we're thinking about in MailPile.  Timeline of the project so far.  In 2011, I wrote an experimental search engine.  I was able to search all my email in milliseconds. It was great.  And then I went back to my regular job. Kept doing what I was doing.  Nothing happened in 2012, so there was no slide.  But in 2013, things started to happen.  My friend Smowdy had been harassing me and saying,  hey, let's do something with this MailPile thing. It's kind of cool.  I'm using Thunderbird, and I don't like it. I want something better.  And I kept saying, go away. I'm doing my job here.  But we bumped into Brennan, who is a user interface designer.  We bumped into him in the hot tub at one of the pools in downtown Reykjavik.  Had a nice chat. Didn't think any more of it.  Bumped into him again at a cafe. I think he was following us.  You were, weren't you?  We had some coffee. We had some beer.  He looked over my shoulder and was like, what are you working on?  I'm playing with this email thing.  And 10 minutes later, he made a logo for the project,  and we're still using it.  So we decided to join forces. We came up with this plan,  and we decided to do a fundraising campaign.  So we raised, we did an Indiegogo fundraising campaign,  launched in August. We launched at the Ohm Festival in Netherlands,  which was fantastic. And we succeeded.  We raised enough money that we can work on this full time for a year.  And actually a little bit extra. I think we're going to manage,  swing current budget suggests we'll get 16, 17, 18 months out of, out of that.  Depends a bit how Bitcoin develops. If Bitcoin keeps going up,  then we'll get a few months that way.  But, you know, since, since September, we've just had our heads down.  We've been writing code. We've gone to a couple of conferences to talk,  but for the most part, we've just been working.  And 2014, we realized, well, you know, we have to keep some of those promises  we made back in August.  So we've mailed out most of the things that we promised to people that backed us.  We mailed out shirts and stickers and some rocks as well.  People that paid enough money got Icelandic rocks.  And we're announcing our first milestone here at FOSDEM, which is,  the alpha version of it.  And we're one day late.  Because, you know, it's a real software project. They're never on time.  So what's the, what's in the alpha?  The highlight of the alpha is that this is not vaporware.  We actually are writing software. You can download it and you can play with it.  And a big part of, a big part of what we're doing is trying to prove  that you can actually crowdfund stuff like this.  And it's not a risk.  So keeping our promises is really important.  We have a nice HTML5-based user interface.  We have a fast search engine, which is not based on that much.  And we'll discuss why later.  We have basic support for PGP encryption signatures.  It's a bit clunky. It's new, but it's there.  We have spam filtering based on the spam Bayesian filter system.  And we have over 30 volunteers translating mailpile into their local languages,  which we think is just fantastic.  Lowlights.  We have to have some lowlights to balance off the highlights.  This is an alpha. Don't expect it to work.  Or, you know, don't expect it to work well.  It's tricky to install and configure.  At the moment, it is still very much for developers.  We don't have IMAP and POP3 support integrated yet.  And the reason for that is I haven't,  but we haven't sort of figured out how we're going to store all that data  because one of the things you want to do is make sure things are stored encrypted.  And we need to think about how we do that.  We don't have support for S-MIME.  I don't know if anyone cares, but it was on the list of things we talked about.  And we don't have a compelling story about how we're going to do PGP key management yet.  So handling keys expiring and keys being revoked and all that stuff.  We need to put a UI on that that doesn't kill the normal user.  And that's going to be tricky.  There's lots of stuff, there's lots of work to do still.  You can get the source code.  You can clone the alpha release.  And from this point on, we're going to try and keep that branch sort of stable  for people who just want to look at it.  And we'll break shit and make things messy on the main branch.  We have live demos.  Because one of the things that we face here is we're backed by over 3,000 people,  most of which are not particularly technical.  So they're not going to be able to download the source code from GitHub.  So we put some effort into making sure demos were up so they could go and see it  and play with it.  And they know what we're working on.  And of course, I encourage all of you to check them out as well.  Oh, maybe I'll do it myself.  Demo.  So let's see if this...  Do we have a new website?  I'm refreshed.  Oh, hard refresh.  Well, I don't know if I even have internet actually.  Let's see if that works.  So this is the intermission of my talk.  I'm going to do a little demo, show you what it looks like,  and then I'm going to go through talking about some of the technical implementations.  And I may use up all of my time and then some,  so I'm going to count on them to stop me,  and I will stop so we can take some questions.  Oh, look.  My pile is now in alpha.  So, demo.  Demo.  This is our demo page.  And we can try it.  So for the sysadmins in the room,  we are running this on four VPSs that...  Oh, why?  Try the dual stack.  Try the dual stack network.  Okay.  How's the dual stack?  Well, if this doesn't work, I just run it off localhost,  so that's how we do it most of the time anyway.  This is what the demo is supposed to look like.  It's an email client.  It's not going to do anything if I click on it, because that's a live one.  This is my personal mail, which is using a different...  I think I've got it zoomed out.  There we go.  We can make it, you know, bigger.  I think.  I don't know, did that break too?  The demo effect is teasing us today.  But if I read an email,  you can read about Media Goblin, which is kind of cool.  So you can read messages.  You can see my cursor there.  Here at the top, we have some icons.  These are going to signify the state of encryption,  so whether the message is signed or encrypted.  See, it pops up a tooltip to explain what's going on.  This is the first draft.  We're going to be improving this interface over time,  but we have some things.  I can click on reply here.  I can try and encrypt it,  but it says there's an error,  and the reason being I don't have the key for the recipient.  Let's see if details work.  Yeah, see, here I can try removing Chris,  because he doesn't have a key.  I'll just send my reply to Smody.  And now...  Oh, it still can't encrypt.  That's a bug.  And now, it's encrypted.  It's encrypted.  It's encrypted.  And now, it's encrypted.  So this is what we're trying to do.  We're trying to make it really easy.  And one of the ideas is that if we know that we have a key  for the person that we're communicating with,  it will suggest that the mail be encrypted by default.  And we know that's going to cause problems,  because a lot of us are using multiple devices,  and one of them can actually decrypt mail.  So we're also looking at ways to communicate preferences,  so that you can...  If we see that we always get encrypted mail from this person,  we're always get signed mail, then it's safe to encrypt.  But if sometimes we get a message that's not,  maybe our default policy for that recipient is to just sign.  That's stuff that we need to work on.  This is a search engine.  I could search for Linux,  Iceland, conference.  Let's see if I have any email about that.  So my mailbox has about 160,000 messages in it.  And this is running on a relatively crappy laptop  with a spinning disk.  That was reasonably fast, right?  This is what we're doing.  It shows tags here. These are all tagged with inbox.  I can browse the tag.  It's trying to show the conversations.  I think if I do that, it will filter it  and only show me the ones I haven't bothered reading yet.  So it's an email client. It's making progress.  We have a view of contacts.  So right here, this is pulling contacts out of my GPG keychain.  And one of the sort of core ideas we have  is we want to integrate key management with contact management.  So there shouldn't really be a difference.  You shouldn't have to go to some separate application  to manage your keys.  You should be able to manage them along with everything else  to do with the contacts.  So yeah, and we are pulling pictures of people down from gravatar.  That's where those images come from.  We'd like to pull pictures from other sources.  We'd like to grab them from Facebook if we can,  but I don't know if that's going to work.  How about card dav?  That would be cool.  We have various plugins for importing.  So I'm going to repeat the question.  He asked how about card dav.  And we have various plugins for pulling in contacts  from other sources as well.  We can pull in contacts from the Mork database,  which is how Thunderbird stores its contacts.  And we have a card dav plugin.  I haven't tried it myself.  But these things are all under development,  but they're definitely going to happen.  And you can help.  Let's see. Here should be a list of my tags.  It gives me some stats.  Here's where we bank for money so we can keep working on this.  Please, please send us all your money.  It'll be great.  So that's the web interface in a nutshell.  But because I know I have a room full of techies here.  What about keyboard?  Shortcuts? Not yet.  We definitely have them soon.  It's just a matter of time.  We do one thing at a time.  So the back end to this is,  this is written as a search engine.  And every time you hit an API,  it's written as a REST API.  Every time you hit an endpoint, you'll get JSON back.  So you can actually just request that  instead of looking at the inbox of HTML.  So this is the same data,  a lot of data actually.  This is all the information about those search results  that were visible.  So it's got these big blobs here of that there.  That's actually someone's thumbnail, an image.  It's pulling back a lot of stuff.  So you can interact with this programmatically.  And we're hoping that will lead to some interesting  sort of plug-in type thing.  Question there?  What was the most commonly implemented code  that reads the Malk database?  Smale did that.  I think he pulled code from somewhere.  I based it off of Python translation of the code script  from way back when.  I'm going to repeat that for posterity.  You based it on a Python translation of Perl script.  Apparently, it's ugly.  Yeah, I showed you guys the composer,  the full composer.  I showed you the reply one.  So this is what the full composer looks like.  It has the same attributes as the other.  I can choose profiles.  I can say I don't want to sign this message  and search for people.  And this is searching in my personal, you know,  list of addresses.  Any address that I see is an incoming mail.  It shows up as a suggestion there.  And the ones that actually have keys,  as I said, they get a little lock.  Hopefully that will encourage people  to use those ones instead of the others.  So, slightly geekier demo  if I go for this one here.  This is the command line interface to MailPython.  How? No.  How?  It's got a bunch of commands.  You can search for things.  So, I'm going to go for this.  So, scary messages.  So, there's various things that you can do.  It's a relatively powerful search engine.  Could you repeat the question?  Yes.  So, I'm actually going to get into that in a moment.  But he's asking if all these mails were offline  if they were stored locally.  And yes, we are encouraging people to store things locally.  We want to take things out of the cloud and decentralize.  That's one of the goals.  So, yeah.  But I know people want to sync with iMac.  We just have to go through how we do that in the same way.  So, I'm going to go back to my slides  and tell you all about the technology behind this.  Or some.  How does MailPython work?  This is your chance to run away and escape.  So, the overall architecture of the project.  The grinding principles are, this is free software.  We're going to use open standards.  And we are proponents of decentralization.  So, we believe users should own their own data.  And we should help them do so.  Searching is a critical feature.  It's not enough that people have to organize  all their mail into folders.  Because even a regular user has thousands of messages.  And someone like me who's been on the internet  for, you know, well over a decade has a couple hundred thousand.  How does searching with encrypted mail?  I'll get to that in a bit.  So, I'm going to go back to my slides.  I'm going to go back to my slides.  I'm going to go back to my slides.  And I'll start by answering that.  Our main user interface is the Web.  We're going to allow for alternate ones, as well.  We want to encrypt by default whenever possible.  And we have the expectation  that our end users are not the people in this room.  They're non-technical people.  People sometimes ask me who I'm writing the software for.  And I would like this software  to be the answer to the question.  When someone comes to me and says,  I'm worried about my privacy, what can I do?  I'm worried about my privacy, what can I do?  Because today, we don't have a good answer to that.  Someone comes and says, I want my email to be private.  We're going to say, install Thunderbird,  learn to use Enigmail, and that's kind of hard to do.  And Thunderbird isn't even being maintained anymore.  So actually, it is being maintained, but it's not  being actively developed.  Getting into the code, we have a Python core, which is  where we handle things like the configuration.  Search Engine is part of the core.  Reading and writing and sending email is part of the core.  Crypto, the HTTP server, and we have a plug-in architecture.  It's not stable yet, but we do want to be able to develop  those things as plugins.  And we're already doing so.  We support multiple mailbox formats, and that's starting  to become pluggable.  Importing contact, as I said, that was written as a plug-in  from day one.  Setup and systems integration.  So when you install MailPile in a new machine, and it goes,  and it finds your mail.app, and it finds your settings,  and it figures out what to do, that would be plugins that  people write for different operating systems.  And we have plugins that allow you to tweak the search  engine itself.  So you can teach the search engine to read your mail and  create new keywords, or to create complex queries based  on something that makes sense to you.  We have a web API.  I touched on that briefly in the demo, where you can get  things back as data in JSON.  So most of the URLs that people see in the web browser, they  map directly to a Python method.  And that Python method, by default, if you hit, as an API  endpoint, returns JSON.  If you hit it using the regular interface, it'll give you  HTML.  But we also provide HTML, which is embedded in JSON, which  is useful for doing AJAX-y-type things.  And there's plain text.  And we might do XML or whatever if there's a demand for it.  The HTML that we do render is rendered using the JINJA 2  templating engine.  The interface itself, there we're using HTML5 APIs.  We're using jQuery, Bootstrap, LES, and all the modern  tools.  We want to do progressive enhancement.  We would like the site to work without JavaScript.  It doesn't quite do that yet, but you can use it in a  read-only mode.  And we want to have responsive design so it scales to  different size screens and mobile devices and so forth.  Because honestly, it's going to be a while before someone  develops a mail pile app for your phone.  But we want the web interface to at least look nice in a  phone if you've exposed your mail pile to the public web.  And it will be female-able and skinnable for people that want  to do that.  There's some alternate interfaces to the app.  I showed you the command line very briefly.  There's also a Python interface where you can say  import mail pile and instantiate a mail pile instance and  interact with it programmatically.  We use that for testing.  And it could be used for various other weird things.  We might support XMLRPC just because that's really easy to  do in Python.  I would love it if someone ported the user interface of  MUT so I could use it on MailPile.  That would be cool.  And details.  How does it work?  So I get the question, why are we not using x, y, or z all  the time?  Why did we write our own search engine?  And the honest answer is, because that's how the  project started.  I was just curious, can I write a search engine?  So I went and I did.  And it works, and it's fast.  And it's under 1,600 lines of code at the moment.  I don't really feel any need to change.  The other benefit I see to this is that it's very, very  simple.  I can explain it to you now how it works.  And you'll understand it.  And I consider that to be a huge benefit.  And I don't have that visibility into other tools.  We want to do things like we want to make sure that this  gives people a good experience that's customized for  email.  We want to be sure that we're storing all of the data  encrypted on disk.  We want to have a lot of control over how this behaves.  So having a simple, small code base that we wrote  ourselves is very appealing.  And it also means we don't have another dependency when we  start packaging this and shipping to users.  So how does it work?  Mailpal reads your mail.  Out of the message, it'll generate an ID for it.  It will extract some metadata, things like the subject,  the recipients who sent it, size of the message, that kind  of thing.  And it will extract a bunch of keywords, which are the  things that you can actually search for.  It will then create posting lists.  These are basically maps that map a keyword to a set of  message IDs.  These are just very simple files.  They just have a list of keywords.  And then there's a map to some IDs.  And there's a metadata index, which maps these same IDs to  the metadata, which tells you something about that message.  Metadata index is something that I store in RAM.  And that was realizing that I could do this, realizing that  email was now small enough, and our computers are now  powerful enough, that I can put all that data in RAM and  nobody's going to notice.  That's what started this project.  Because when you can do that, all of a sudden, everything  becomes really fast.  Because most search queries can be answered by opening one  small file, reading it, and then looking up all the other  data in RAM.  That means I can answer any search query under 200  milliseconds on crappy hardware.  If you have good hardware, it just gets faster.  This is how you would implement this if you were writing  code yourself.  My implementation, get the message IDs for a given  keyword.  You generate a file name by hashing the keyword.  You open it up.  You parse it.  And you return a set.  In reality, I'm grouping some of the keywords together so I  don't have an infinite number of files.  And there are some problems to this.  So adding things is easy.  Deleting them means I have to go and open all the files and  remove stuff.  So that's a bit messy.  The metadata index, it looks like that.  It's just a dictionary.  It has an ID, and it maps to a bunch of attributes.  What we put in the metadata index is all of the data that  we need to generate search results.  So when you search for a potato, I get back a list of  messages.  And I can find the subject lines, senders, all the  details I need to show you the list.  So I can show you the list immediately.  And that's how we get a good experience when you're  searching.  The metadata we're currently storing encrypted on disk,  GBG encrypted.  Posting lists are not yet encrypted, but they will be.  So putting those two things together, that's a five line  search engine.  Start with a set of all of the message IDs that exist for  each keyword in the query.  You narrow down the set.  You just look up the message IDs that match that query, and  you do a set intersection.  Then when you've done that for all of the terms that people  are searching for, you go through the results, and you  print them out.  That's the core of the search engine right there.  So building on top of this, we added tags, which are similar  to the labels that are in Gmail.  And these are basically search terms where you can edit the  result set.  So you can add and remove message IDs to this keyword.  And that allows you to do all sorts of things.  That means you can create an inbox, and you can mark  certain messages unread, or spam, or whatever.  And now we have things that do that automatically.  So you have filters, and this allows you to start  organizing your email in a structured way.  We have plugins, as I mentioned before.  This allows you to make new rules for how to generate  keywords.  I'm really hoping someone will write a plugin to parse PDF  files and extract the text, so I can search for those as well.  Someone could write a plugin that understands the grammar of  their language, or that understands their particular  field of specialization.  Something that parses.  One thing that would be cool is to parse messages that come  from Ryanair and come from EasyJet and extract the  information about the flight, and make that into a search  keyword.  There's a lot of things that can be done there.  And then there's the other side.  So instead of generating keywords, you can create  sort of magic keywords that are dynamic.  The way you search for dates is implemented as one of these  plugins.  So you can search for dates that arrange 2010 to 2014.  That's not a keyword.  But I can create keywords out of that.  And that's what this plugin does.  It'll actually tell you to search for date 2010, or date  2011, or date 2012.  That kind of thing.  And of course, plugins can also just use a search engine to  generate interesting views, figure out things about your  email.  Tricky bits, building a search engine like this is mostly to  do with actually reading the mail and generating useful  terms.  So which keywords we put in the index and which keywords we  don't.  And then, of course, there's the constant optimization  battle to make it fast, to make it not too big, and so forth,  and so on.  Works in progress.  We are not able to delete things from the search index  right now.  That's a bit of a limitation.  We'll fix it.  The encryption needs work.  Why security people tell me that it's not good enough as  it is.  And it would be nice to have a better query language.  The current query language is pretty stupid.  So I'm going to pause, actually.  Do people have questions about the search engine before I  move on?  You have a question.  So the question from the guy earlier was what about  encrypted emails?  How do you search those?  Oh, yeah.  That's in the crypto talk.  Yeah.  Those are decrypted.  So the question is, what do we do about encrypted mail?  And the answer is, if you tell mail pilots allowed to, and  this has to be a setting because not everyone is  comfortable, mail pile will just decrypt your email when it  sees it.  It'll index it just like anything else.  And that's one of the reasons that the search index needs to  be kept secure.  Because I believe that encrypted email will not be  usable unless you can search in it.  So this feature needs to work.  But in order to do so, we need to be able to encrypt the  search index.  We need to be able to encrypt the metadata.  We need to do so in a way so that we're not leaking the  contents of these private messages.  Anything on over there?  I saw you mentioned auto-tagging.  Do you have some kind of crazy classification based on  the type you already made?  I'm about to talk about that.  But yes.  Up there?  It's not about search, but are you  amazing at each one?  Actually, if it's not about search, let's do it afterwards.  OK.  I'll try and leave some time.  How am I for time?  Oh.  OK, well.  That means that we don't talk about crypto.  But let's talk about spam filtering, because it's cool.  So how does it work?  Mailpile spam filters are based on statistical analysis of  the mail.  So we want to have engines that read the mail and give us  some sort of result.  By default, we're using spam base.  Messages that match our auto-tag with a spam tag.  And then messages that have that tag are by default hidden  from search results.  So the spam isn't in your face.  We train the base in engine by looking at the user's behavior.  So going in a little deeper, statistical analysis, is trying  to answer the question, what is spam to you?  Because not everyone has the same spam, and not everyone  has the same idea about what is spam.  We do that by feeding the same keywords as going to the  search engine into a Bayesian filter.  And it will then hopefully be able to classify the mail into  its spam, or it might be spam, or it's  definitely not spam.  And by default, we use spam base.  The training is the important part.  If we get this wrong, then the spam filter will perform very  poorly.  And this is where we need to work a bit more.  But what we're trying to do is we're looking at how the  user interacts with their mail.  So if you take a message and you drag it to the spam folder,  that's a pretty clear signal that that's spam.  And if you read a message and then you reply to it, that's  a pretty clear message that that message was not spam.  So we're using things like that to assemble a corpus of  messages for training.  And my vision for doing this is I want to train on a  relatively frequently, because I believe that both your  communication patterns and the patterns of spam are going to  change over time.  So I do not expect your spam filter to match your spam from  two years ago, but I would like it to match the spam you're  getting this week.  So Mailpile is tracking these actions.  When you click on a message and read it, that message gets  tagged as having been read.  When you reply to a message, it gets tagged as this message  was replied to.  And when you manually organize things, you move them from  one tag to another, it tracks that as well.  And that allows us to choose messages for training.  We also have bacon filters.  Turns out nothing that I just said has anything to do with  spam.  It's just how you organize your mail.  So what we're interested in doing is using the exact same  plugin and the exact same code and use spam base as a general  purpose MailClassifier.  So you can go to some tag that you've just created.  So this is the FOSDEM tag.  And you can just click Auto Tag.  And then over time, you put some messages in that tag, you  haven't put other messages in.  Mailpile should be able to learn which messages belong  under the FOSDEM tag and do that for you.  I hope it works.  I think it's cool.  I think yes, I think I am.  OK.  Should I go through one more?  This one's kind of long.  I think you will want that one.  OK.  Last talk here.  Yeah.  Did anyone want to ask about the spam stuff?  Yes.  Basically, the baseline expectation from users is  going to be the Google experience in spam filtering.  But of course, because you're only using one mailbox, your  focus is way smaller than whatever Google is using.  And so you don't have to cross benefits.  And so I'm wondering, is Baze actually still working  against the modern spam?  So the question is whether Baze is actually good enough on  its own.  And you raised the question of whether we'll be able to  compete with people like Google that have access to lots  of other people's mail and can cross correlate.  Time will tell.  But people, I think Smode has been using Thunderbird and  its Baze and spam filter for a while, and he's really happy  with it.  But this is an area where I do expect that we're going to  need to iterate and develop.  And if necessary, it might be interesting to look into ways  that users can collaborate and share details in a  decentralized way.  But I mean, that's a big hand-wavy project, so I'm not  going to promise that we're going to do that.  But yeah, this is a valid question, and I don't really  have a clear answer for it.  Yeah?  It's been a good question.  What if Spammer starts GPG encrypting the spam email  sending to you, and then you won't be able to do the spam  filtering until the user opens the email message because  then he encrypts it?  So I think what you're asking is what happens when  Spammer starts encrypting their mail?  At that point, we win, because at that point, Google can't  filter it, but we can, because we're doing the spam  processing after the mail has been decrypted.  So that's one of the reasons that in an encrypted world,  you need to move the spam filter out to the edges to  where the users are.  Yes?  That's an administrator.  That's an administrator, as sometimes we see mail forwarded  by users who get frightened by spam and wonder, oh, how  should I react to this?  So for one, it's not always an indication of actually a ham.  Somebody asked, what is this?  Yeah, that's true.  What that actually means, though, is that that's an  interesting message.  The odds are the user is going to forward that to you, but  he's also going to put it in a spam folder.  And that means I have a very strong signal that that was  interesting spam.  And you know, I'm perfectly happy with that.  It works both ways.  So I'm going to move along, talk about crypto.  There's one up there.  How can a friend of mine benefit from my training?  You're asking, how can a friend of yours benefit from  your spam training?  I'm not sure.  I'm not sure that he can.  It depends on whether your spam is similar enough to his.  And one of the things that we need to look into before we  ship this is whether there's value to building a sort of  generic pre-trained filter and shipping that, and then having  that learn over time.  And how we would do that.  But that's something that we don't even start looking at  until next summer or even later.  But it's a good question.  I don't know.  So crypto.  Where should we do crypto?  I'm not going to say we do because it's not all  implemented yet, but this is what we're talking about.  We want to encrypt the data at rest.  So all the data that MailPile generates should be stored in  a safe way.  I know some people have full disconcription, but not  everyone does.  I would like people to be able to store their MailPiles on  USB sticks and just carry them around.  There's many reasons for doing this.  We're using crypto when we're reading, writing, and  sending mail.  We're using HTTPS, obviously, wherever appropriate.  We would like to anonymize communication with the  external network.  So when MailPile goes off and downloads those images from  Gravatar, it shouldn't really be telling Gravatar that I'm  talking to these people.  That needs to be anonymized in some way.  And we might want to implement some of the proof of work  hash-cache things, which relates to one of the other  crypto ideas that comes up soon.  Data at rest, our strategy there is to just shell out to  the existing tools.  We're going to use the GPG binary or the OpenSSL binary or  wrapper libraries and use that to encrypt basically  everything, application settings, contacts, search  index, et cetera, et cetera.  Using GPG is relatively slow.  So we're probably only going to use that for the config  file.  That will then contain a key that is used for symmetric  encryption via OpenSSL because OpenSSL AES encryption is  quite fast.  That's our strategy there.  Reading email, well, there's the basics.  You parse the PGP MIME.  You call out the GPG to check whether the signature checks  out and decrypt things as necessary.  But we would like to be able to plug in other things.  We would like to be able to plug in other crypto systems  because the crypto community is developing all these things.  And I'm not sure they have a good platform where they can  actually play with them.  I would like to be able to plug in some other friends, Steph.  He wrote something called TBP, which is pretty bad privacy  based on elliptic curves, but does similar things to GPG.  And it would be cool if we could just plug that in and let  people play with it.  As I answered earlier, the question, decrypting can be  done during the indexing phase.  So encrypted messages can be searched.  And when we do that, that means that we bubble up  information about the state of the messages into the metadata  and into the search index.  So you can search for messages that have bad signatures.  Or the UI can give visible feedback because everything  that the UI shows you is based on what's  in the metadata index.  So that's important plumbing.  And that is mostly working as of this month.  Writing email, again, generate PGP MIME, use GPG to actually  do the signing and the encrypting.  We want to do best effort security.  We would like to encrypt messages whenever we can.  How we figure out whether we can is an open question.  We'd like to sign by default.  There's really no reason not to.  And we need to give the user the power to change these  settings, but for the most part, we want to do our best.  We would like to use trust on first use, so tofu for key  verification.  So that's like SSH, where the first time you see the  key, you just say, OK, this is probably the right key.  And then you only complain if it changes in the future.  And this is because the web of trust is very complicated.  I'm not sure we can put a user interface on that, to be  honest.  And the web of trust is also leaking private information.  The web of trust is revealing to anyone who cares to look  who's talking to whom and who knows who and how we're  connected.  And a lot of people consider that to be such a massive  privacy problem that it just should not be used.  So this is how we're heading right now.  You're welcome to talk us out of it.  We'll listen to feedback.  But this is what we're talking about at the moment.  And we're probably going to distribute keys in an ad  Hoc way, including just attaching them to outgoing mail.  Sending mail, that's a fun one.  We should use TLS when possible.  That's been an SNTP forever.  And obviously, we should use it.  But we also have this idea, SMTorrent, or SMTP over Tor.  This is when MailPile starts becoming a MailServe.  We build a very simple SNTP server into MailPile.  We ship MailPile and Tor together.  So an end user installs MailPile.  They also get Tor.  People know what Tor is, right?  OK.  It's an anonymity tool.  It anonymizes communications.  And it's also a darknet.  So you can register what's called a hidden service on Tor.  And people can connect to that.  And the anonymity of that connection  is strongly guaranteed.  But what this means is you get an email address, which  looks really ugly.  It's your name at some long gibberish string.  I think that they very helpfully made those strings  longer recently, like 80 characters or something.  Ends in dot onion.  But what that means is that when your MailPile is connected  to Tor, one MailPile can deliver email directly to another.  And it doesn't have to go through any outside relays.  It never leaves the encrypted Tor network.  And we have suddenly closed the metadata leak  that people are complaining about with SMTP, where the NSA  is just listening to who is sending little messages  all the time.  Because a lot of the time that happens in the clear.  And this is a different problem from the lack of encryption  of message headers in PTP.  This is the actual SMTP dialogue, where you say mail  from somebody, RCPT to somebody else.  That's always in the clear unless people are using TLS.  And TLS is not widely deployed.  We're not widely deployed enough.  So this closes that leak completely.  And it allows emails to suddenly become a peer-to-peer  messaging protocol without inventing any new protocols.  I love that.  We don't invent anything.  We just assemble things.  So by building on SMTP, instead of inventing some new  protocol, that means we can use the existing infrastructure.  We could use something like PostFix or Exim or something,  put that on a hidden service instead, and do relaying.  If your MailPile is not online often enough for the peer-to-peer  solution to work for you.  Question about that.  What are darkmail doing and is it relevant?  I have no idea.  Darkmail are the questions, what are darkmail doing and is  it relevant?  From what I've heard, darkmail are doing something clever  with XMPP, which is Java.  So in my mind, that's not really email.  I don't know if they plan to be backwards compatible with  the world of email.  They'll just have to answer those questions.  I don't know.  But if they publish something, we might well implement it.  If it's good, we'll implement it.  But we just have to wait and see.  I think this is my last crypto slide.  Yes.  HTTPS, that's an O-brainer.  We should be using it all the time.  And I would like to anonymize the traffic.  By shipping with Tor, we can start downloading from  Gravatar.  We can download from Facebook and here and there without  revealing who you're talking to.  And in some cases, we will actually also be able to  anonymize the outgoing S&P connections.  There are providers like Gmail, which is one of the things  they do really well.  They explicitly allow incoming connections from Tor.  And they do this because they want activists to be able to  communicate.  So there are some providers that are known to behave well.  And we should be able to connect to them over Tor  instead of going through the clear text internet and  revealing data.  So that's it for me.  Yay, we have an alpha.  Can we take some more questions?  Do we have some more questions?  General type.  Please hands up so I can have the microphone maybe.  It's like people are running away.  Maybe we should gather and talk.
_FOSDEM_2014__Mailpile_wha5goRMCho_0_419.png _FOSDEM_2014__Mailpile_wha5goRMCho_420_4043.png _FOSDEM_2014__Mailpile_wha5goRMCho_4044_7067.png _FOSDEM_2014__Mailpile_wha5goRMCho_7068_8903.png _FOSDEM_2014__Mailpile_wha5goRMCho_8904_9407.png _FOSDEM_2014__Mailpile_wha5goRMCho_9408_9659.png _FOSDEM_2014__Mailpile_wha5goRMCho_9660_9863.png _FOSDEM_2014__Mailpile_wha5goRMCho_9864_10091.png _FOSDEM_2014__Mailpile_wha5goRMCho_10092_10235.png _FOSDEM_2014__Mailpile_wha5goRMCho_10236_10463.png _FOSDEM_2014__Mailpile_wha5goRMCho_10464_10595.png _FOSDEM_2014__Mailpile_wha5goRMCho_10596_12587.png _FOSDEM_2014__Mailpile_wha5goRMCho_12588_12743.png _FOSDEM_2014__Mailpile_wha5goRMCho_12744_14555.png _FOSDEM_2014__Mailpile_wha5goRMCho_14556_14663.png _FOSDEM_2014__Mailpile_wha5goRMCho_14664_14975.png _FOSDEM_2014__Mailpile_wha5goRMCho_14976_15515.png _FOSDEM_2014__Mailpile_wha5goRMCho_15516_22439.png _FOSDEM_2014__Mailpile_wha5goRMCho_22440_26279.png _FOSDEM_2014__Mailpile_wha5goRMCho_26280_26603.png _FOSDEM_2014__Mailpile_wha5goRMCho_26604_28691.png _FOSDEM_2014__Mailpile_wha5goRMCho_28692_28919.png _FOSDEM_2014__Mailpile_wha5goRMCho_28920_28979.png _FOSDEM_2014__Mailpile_wha5goRMCho_28980_29303.png _FOSDEM_2014__Mailpile_wha5goRMCho_29304_29507.png _FOSDEM_2014__Mailpile_wha5goRMCho_29508_30371.png _FOSDEM_2014__Mailpile_wha5goRMCho_30372_30983.png _FOSDEM_2014__Mailpile_wha5goRMCho_30984_31619.png _FOSDEM_2014__Mailpile_wha5goRMCho_31620_34259.png _FOSDEM_2014__Mailpile_wha5goRMCho_34260_35207.png _FOSDEM_2014__Mailpile_wha5goRMCho_35208_35303.png _FOSDEM_2014__Mailpile_wha5goRMCho_35304_37055.png _FOSDEM_2014__Mailpile_wha5goRMCho_37056_37319.png _FOSDEM_2014__Mailpile_wha5goRMCho_37320_42131.png _FOSDEM_2014__Mailpile_wha5goRMCho_42132_50387.png _FOSDEM_2014__Mailpile_wha5goRMCho_50388_50663.png _FOSDEM_2014__Mailpile_wha5goRMCho_50664_50819.png _FOSDEM_2014__Mailpile_wha5goRMCho_50820_52583.png _FOSDEM_2014__Mailpile_wha5goRMCho_52584_52751.png _FOSDEM_2014__Mailpile_wha5goRMCho_52752_59039.png _FOSDEM_2014__Mailpile_wha5goRMCho_59040_59087.png _FOSDEM_2014__Mailpile_wha5goRMCho_59088_59423.png _FOSDEM_2014__Mailpile_wha5goRMCho_59424_59723.png _FOSDEM_2014__Mailpile_wha5goRMCho_59724_59903.png _FOSDEM_2014__Mailpile_wha5goRMCho_59904_60431.png _FOSDEM_2014__Mailpile_wha5goRMCho_60432_61223.png _FOSDEM_2014__Mailpile_wha5goRMCho_61224_61547.png _FOSDEM_2014__Mailpile_wha5goRMCho_61548_62051.png _FOSDEM_2014__Mailpile_wha5goRMCho_62052_64139.png _FOSDEM_2014__Mailpile_wha5goRMCho_64140_73103.png _FOSDEM_2014__Mailpile_wha5goRMCho_73104_73223.png _FOSDEM_2014__Mailpile_wha5goRMCho_73224_73547.png _FOSDEM_2014__Mailpile_wha5goRMCho_73548_74939.png _FOSDEM_2014__Mailpile_wha5goRMCho_74940_77147.png _FOSDEM_2014__Mailpile_wha5goRMCho_77148_77682.png