Fork me on GitHub

Progress Report: events, packages, 1.0

Posted by Bjarni Rúnar on 27 October, 2018

Hello world! How are you?

I'm writing this, sitting on a bus in Luxembourg, realizing that we have been very quiet for quite some time. Our last posts were in May, first a report on the results of our first round of desktop package usability testing, quickly followed by a statement on how the EFail flaw impacted Mailpile.

Since then we may have been quiet, but we have not been idle:

  • Many, many bugs have been found and fixed
  • The first round of our desktop packaging project is complete, we have packages and very basic desktop integration for both Windows and the Mac
  • Mailpile's multi-user Apache integration (Multipile) has been simplified and reworked
  • Mailpile's internal (in-memory) master security key is now protected against memory corruption
  • Mailpile is now compatible with Autocrypt Level 1, but not yet fully compliant
  • I attended the OpenPGP e-mail summit in Brussels

I would like to publicly thank Alex and Pétur for their hard work on the Mailpile Desktop packages, and in particular for how they took delays and slow responses from my end graciously and in stride.

Read on to learn a bit more about the OpenPGP E-mail Summit, our CCC plans, the state of the desktop packaging work, and of course the elusive 1.0 release.

The OpenPGP Summit and 35c3

Last weekend I visited the Mailfence office in Brussels, to attend the annual OpenPGP E-mail Summit.

The OpenPGP E-mail Summit is one of my favourite community events. Just two days long, it is an informal event focused on getting people from the world of e-mail encryption to exchange knowledge and collaborate.

This year there were (by my rough guesstimate) about 50 people from over 20 projects present, including Phil Zimmermann himself, the creator of PGP. I was very happy to meet him and shake his hand. We ended up having about 20 different sessions, discussing topics ranging from key server management, to user interfaces, to updating the OpenPGP standard itself.

Notes from all the sessions have been published.

There was also a dinner and plenty of socializing, the value of which is not to be understated. Meeting people face-to-face almost always makes collaboration online easier and more productive.

For Mailpile, the main outcomes of the summit were the following:

  1. There seems to be potential for partnerships with 2-3 other businesses in the OpenPGP space, which we look forward to exploring further.
  2. The Web Key Directory specification is still evolving in ways which may require we re-evaluate how we use it in Mailpile.
  3. Mailpile will aim for Autocrypt Level 1 compliance, soon! Our aim is to get a member of the community to review and confirm our implementation at the 35c3 conference. We have a volunteer to perform the review.
  4. I have a voucher and will be representing Mailpile at 35c3. Come say hi!

It was a productive weekend!

When will Mac and Windows packages be available?

If you've e-mailed me asking this question; my apologies for not answering. I haven't replied, because I don't know! If I did, our download page would just say so.

There are three main tasks we need to complete before we make the desktop packages available to the wider Internet:

  1. A short private beta, to reassure ourselves the packages don't have any blindingly obvious bugs.
  2. Launch a Discourse forum, so our users have a venue to help each other out.
  3. Finish our "build robot" so packaging becomes an automated process without any human bottlenecks.

I am not going to commit to a time-line for getting this done, but this work is all in progress and won't take forever. This year? This year.

It's worth mentioning that some important tasks have been postponed and will not be blocking the availability of packages - so these packages will not be "Mailpile 1.0". But they're close.

So, what about Mailpile 1.0?

Our current release is 1.0.0rc4, tagged and pushed earlier today.

At times it feels like we're chasing the tortoise from one of Zeno's paradoxes, always getting closer but never able to catch up. For every issue we close, others are opened...

But in spite of that, my to-do list for the elusive "Mailpile 1.0" release really is starting to get shorter and the issues that remain are not as complex as the ones we've resolved. I've updated the GitHub Milestone to reflect the current priority issues. It's not a long list, mostly relatively minor bugfixes.

The two big items left on my 1.0 roadmap are:

  1. Fully implement Autocrypt Level 1
  2. Implement easy remote access (PageKite and Tor Hidden Services)

The former is necessary for an interoperable and complete implementation of "PGP for everyone", and the latter is needed so people can access their Mailpiles remotely - in particular to access their Mailpile from their smart-phones.

Again, I'm not going to make any promises about when these will get done.

But this mini roadmap is still worth sharing, because if you liked the vision behind Mailpile and those two issues aren't critical for your use-case... then maybe Mailpile is already ready for you. Maybe!

One-point-oh is an important label, but it's not everything.

Mailpile is already a great e-mail client. Give it a try!

PGP Security Alert

Posted by Bjarni Rúnar on 14 May, 2018

Dear Mailpile users,

The EFF have publicized advice from a group of security researchers, who claim there is a serious problem with PGP encrypted e-mail. Users are advised to disable automatic decryption of e-mail and exercise caution or avoid decrypting e-mails entirely until the vulnerabilities have been addressed.

Second (and 3rd) Update

The actual research is now public.

As far as I can tell, Mailpile is [mostly] not vulnerable to these flaws and the table of tested mail clients in the paper itself is misleading in that regard. This is unfortunate.

There are some exceptions though, see below.

Why is Mailpile [mostly] not vulnerable?

Because of defense in depth.

  1. Mailpile does not display HTML content by default
  2. Before displaying HTML, Mailpile cleans up malformed and incomplete tags.
  3. When displaying HTML, Mailpile does not load remote content by default.
  4. Mailpile respects the GnuPG error messages which warn of invalid data.
  5. Mailpile never sends auto-replies to incoming mail.

The direct exfiltration attack is completely thwarted by #2, and would be mitigated in any case by #1, #3 and #5.

The CBC/CFB Gadget Attack is mostly thwarted by #4, and would also be mitigated in any case by #1, #3 and #5.

As far as I can tell, most Mailpile users will not be vulnerable to EFail. Don't let the red mark in the PDF deceive you! Also, it's worth mentioning that this isn't a lucky accident - this is a direct validation of how we approach security.

Part of that approach is simply taking these things seriously. If anyone disagrees with my analysis or finds other flaws in Mailpile, we want to know about it and will do our best to remedy things as quickly as possible.

Wait.. mostly? When is Mailpile vulnerable?

Mailpile is vulnerable to the CBC/CFB Gadget Attack in the following cases:

  1. Something is obsolete, either:
    1. Mailpile is configured to use an out-of-date version of GnuPG, or
    2. The encrypted data being exfiltrated is so old that GnuPG doesn't expect and require it to have a Modification Detection Code (MDC).
  2. And:
    1. The user manually displays HTML and loads remote images, or
    2. The user has previously enabled HTML and images for the sender

In practical terms, this means even if you are running up-to-date software, then old content (messages that are 10-20 years old, or more) could potentially be stolen - but only with a bit of social engineering, and only if you still have the keys on your keychain.

The risk is more serious if you have configured Mailpile to use an obsolete version of GnuPG - use of GnuPG 1.4.x is still relatively common, and our tests suggest it is probably vulnerable. In this case more recent messages may be at risk, but the social engineering is still required for attacks to succeed.

Fixes addressing both of these attack vectors have been pushed to our GitHub repository and will be included in our next release candidate. They are already present in our nightly Debian packages.

First Update

Further details have emerged.

Werner, the lead developer of GnuPG, claims that the flaw has to do with an interaction between HTML mail and GnuPG error handling in common e-mail clients and PGP plugins.

If this is indeed the case, most Mailpile users are not vulnerable since HTML messages are not rendered by default - and even when HTML is rendered, loading of images and other remote assets are also disabled by default.

If you would rather take the EFF's advice, in spite of Werner's update, our original advice is included below.

Disabling Automatic Decryption

This advice is obsolete! It is preserved here for historic reasons.

Within Mailpile, the way to disable automatic decryption is as follows:

  1. In the web interface, visit the Settings page
  2. Open the CLI
  3. Run the following command: set prefs.index_encrypted = false

This will disable automatic decryption of incoming mail. However, manual decryption (decryption when messages are read) will still work and it is advisable to not read any encrypted mail until we know more about the attack and whether Mailpile is actually vulnerable.

If you absolutely must read encrypted e-mail, we recommend taking your computer offline before doing so, so as to prevent network-based side channels from leaking sensitive key material.

To re-enable indexing of encrypted messages, perform the same steps again, except set prefs.index_encrypted = true at the end.

What is going on?

What follows is idle speculation. Please take it with an appropriately sized grain of salt!

I don't know what is going on. However, I trust the EFF. They would not be advising we disable such an important tool unless it was of critical importance. The implications of the advisory, are that automatic e-mail decryption can leak details of your private key material back to a malicious attacker. The mechanism is unknown, but the common denominator in the EFF's list of vulnerable e-mail clients is use of GnuPG - which Mailpile also relies upon. My guess, is that there is a flaw in GnuPG which allows attackers to craft encrypted messages that force GnuPG to leak key material back over the network to an attacker.

See updates from myself and Werner above. The situation is not as bad as it first appeared - in fact, it appears Mailpile is not vulnerable to this problem.

All the same, because we take these things seriously, I have filed issues in our issue tracker for follow-up work and proactive improvements: #2072, #2073, #2074, #2075, and #2077.

We will post updates as more information becomes available.

Desktop Usability Tests

Posted by Bjarni Rúnar on 3 May, 2018

Last week was exciting!

The Mailpile desktop platform team got together for a miniature developer summit in Reykjavík, Iceland. Alex, Pétur and myself all flew in from our corners of the globe, and Oktavía welcomed us and made sure everything went as smoothly as possible.

We spent some time working at Stofan, my favourite café, and some time hanging out at the offices of 1984, who graciously lent us desks and a meeting room. Thank you, 1984!

It was really nice to have the whole team together in one place.

We ate some traditional Icelandic food, tasted some Icelandic hipster-beer, chatted and just gelled a bit as a team. I got a chance to give everyone a bit more insight into Mailpile's background, discussing everything from PayPal freezing our funds to GnuPG integration challenges to extracting spreadsheets from e-mail to introducing Mailpile Mel.

The main event though, was to get a bunch of helpful humans to come test the Mailpile installers and desktop integration.

Usability testing!

Why usability test?

The more familiar you are with something, the harder it can be to see it clearly. You see what you expect to see.

In software, this means software developers quickly become blind to the flaws of their own code. We literally cannot see them! Getting a fresh pair of eyes is invaluable, especially if you are interested in understanding which parts of an interface are confusing or unclear.

To compound matters even further, everyone uses their computer in a slightly different way. The way I use Mailpile may work perfectly, but if you do things in a different order, use a different mail server, run on a different version of Linux ... any of those differences may trigger a poorly tested code path and uncover a bug.

Usability tests can be as simple as asking a friend to try your thing and just watching how they do and taking notes. It doesn't have to be complicated to provide value and I encourage all software developers to just grab a pen and some paper and watch people use their stuff. You always learn something!

In our case, we had some quite specific goals, so we were a little bit more methodical.

How we tested, and why

For this round of tests, these were our main goals:

  1. To verify that our draft installers actually work.
  2. To check whether the software "makes sense" to a new user.

The first goal ws relatively straightforward, technical.

The latter was much more subtle, and relates to the fact that Mailpile is quite complex and in many ways unusual software. The general public is not used to running servers on their computers - Mailpile is a web server. The general public is not used to interacting with local software using a web browser - but that's how Mailpile works.

As a result, our installation sequence and the initial setup process needs to gradually introduce these concepts. We wanted to get a feel for whether it was actually succeeding.

Oktavía scheduled and recruited a moderately diverse group of volunteers to come test. All told we had 3 men and 3 women, of mixed ages. Some were Windows users, others Mac users. They were all tech-savvy enough to own their own laptops, but not necessarily programmers themselves. Some digital natives, some less so. Roughly our target demographic for our next release.

The structure of the test itself was relatively simple.

We tested with one volunteer at a time. Each time we started with introductions, explaining roughly what Mailpile was and what we expected of our volunteers. We warned them we wouldn't help them much, asked them to think out loud if they could. Made sure they understood that failures and problems were good, that breaking things would help us identify things to fix.

Next, each person was given a USB stick with an installer on it and instructions to attempt to install Mailpile and go through the initial setup until we told them to stop. Once stopped, they were to exit and shut down the app. We watched over their shoulder and made notes. We tried to resist the urge to answer any questions, to see if they could figure things out themselves.

Finally Oktavia asked a few questions about the experience, we thanked them, gave them stickers and chocolate and sent them on their way!

That was it.

Easy, right?

What we learned

Even a simple, short test like this has many potential pitfalls.

  • Does the installer work?
  • Does the app run?
  • Does the tester successfully navigate from the installer to the app, and from the app to the browser?
  • Does the tester understand that shutting down Mailpile and logging out from the web UI are not the same things?
  • Is the process confusing or uncomfortable?

If the answer to any of these questions is "no", then we would like to understand why, so we can fix the problem.

The answers in this case were mostly good news! Which is refreshing, since last time we tested Mailpile in this environment, the result was so many failures and so much confusion that we went back to the drawing board.

We found some minor bugs, but everyone managed to install the app and complete the first stage of the test. Good news! Nobody was frustrated, most confusion was minor. Also good news!

Shutting down the app was the main failure; most of our participants thought they were done when they had logged out of the web interface. But, we have ways to address this. And worst-case, we need to make sure Mailpile shuts down cleanly when the computer powers down anyway.

To sum up the main lessons:

  • The installers work!
  • The app runs!
  • People didn't read the text in the GUI: less is probably more here
  • Windows users expect the installer to launch the app when done
  • Our Mac build process created a broken GnuPG
  • Our Mac build was launching the in-browser UI prematurely
  • Our desktop notifications on the Mac were spammy
  • The logged-out page should explain that the app is still running
  • Nobody notices systray or status bar icons on first run
  • Our testers were comfortable and happy, most chose to keep the app installed so they could play more at home.

We learned a lot!

Watching people use the app and interact with our work was very stimulating. The next day we had a (somewhat hung over) brainstorming session, discussing how things could be different or better. In the end we felt comfortable continuing with a mostly unchanged design. The issues were mostly minor and felt fixable.

So, we're on track! The next step will be to fix the bugs and get some "alpha" packages ready for wider testing.


Building up Steam

Posted by Oktavía on March 29, 2018

Wow, we've been so busy making progress we forgot to let you all know how we are progressing!

So far, Mailpile in 2018 has been all about building up steam for the Mailpile train! We hired me (or rather – Bjarni hired me!) and I have been working on project management and thinking towards the future, including human resource work (I spent a lot of time looking to lessons learned on diverse and inclusive hiring practices). This has resulted in the hiring of two more persons –

Alexander and Pétur who, along side Bjarni and myself, will be taking Mailpile to as many users as possible!

Who are these new additions to the Mailpile Team? Well, Alex Haase is a self-proclaimed generalist, who has a background spanning kernel modules to javascript, bare metal to Windows. He lurrvvs tinkering on Open Source side projects and refereeing Roller Derby when he‘s not Mailpiling. Pétur is all about high level software engineering. Specifically modelling and automatic programming. He loves collaborative design by prototyping, designing and exploring new ideas using scissors, papers, glue and different shades of colour. His favorite movie quote?

"It's a UNIX system." — Jurrasic Park :)

What will they be doing with us? We're glad you asked! Their main tasks relate to packaging Mailpile for the Mac and Windows platforms, and in doing so making Mailpile more accessible to more people! Hooray!

Contracts were signed in mid-March and we are on track to deliver packages and an improved native user experience within 3-4 months. So soon, soon, at long last, our downloads page won't tell people our packages are being reworked. IT will tell people to go forth and install what Alex and Pétur have built!

We are now well settled in our virtual working space, as our physical selves are spread over Europe and the US. We would love a visit, so please come by the Mailpile IRC - #mailpile (Freenode, or Riot), but bring your own coffee!

Older stuff

Some Tweets

we are back in the virtual office after co-working in Reykjavík! We are already incorporating the awesome input from our usability study and looking dorky doing it! (as we should)
More soon! /okta
@MailpileTeam, Thu, 03 May 2018 18:34

Second day of co-working in person for the #Mailpile team :) Reykjavík may be cloudy, but team spirits are up as we user-test installers today!
#Mailpile4Win #returnoftheMac #okayIwillStopwiththeHashtags
@MailpileTeam, Tue, 24 Apr 2018 11:43

Halló Reykjavík residents!

#Mailpile is doing a small usability test tomorrow Tuesday (real Smol!) and we are a couple of folks short. Are you in Reykjavík, using email, free tomorrow afternoon and interested in privacy? Send us a DM for details!
@MailpileTeam, Mon, 23 Apr 2018 10:54

Wuddyah look at that! The first in-person meeting of the Mailpile Team!

We will be hanging around Reykjavík the next days - so ping us if you want to come say hi!
@MailpileTeam, Mon, 23 Apr 2018 10:42

Don't panic: Our website is temporarily unavailable as we migrate to a beefier VPS.

In other news, we successfully hired a couple of clever people to help with our Windows and Mac packaging. Work has begun!
@MailpileTeam, Tue, 13 Mar 2018 16:19

Its Friday afternoon in some parts of the world - your inbox is hassling you & you drift off to better future where you have an email client that is a search engine & a personal webmail server that has email encryption built in!
Help us build that future!
@MailpileTeam, Fri, 09 Feb 2018 15:43

Iiiitttt´ssss "Hump Day" everybody!
Did you know that Mailpile is still looking for developers? we would luurv to get Mailpile out to as many as possible, make it accessible for most! Join us to package for Windows and MacOS!
@MailpileTeam, Wed, 07 Feb 2018 15:46

Hey developers! We are still looking for you <3 so much so that we have extended our deadline for MacOS and Windows developers to Feb. 14th <3 <3
Ping us for questions - more info here:
@MailpileTeam, Thu, 01 Feb 2018 12:00

The Mailpile Team is back after being dormant for a while and we are looking for developers to help us Mailpile out for more people to use! Check out for details
@MailpileTeam, Mon, 29 Jan 2018 09:57

We are hiring!

We are looking for Windows and Mac OS developers to help us get Mailpile 1.0 in the hands of as many people as possible.

Check out and spread the word!
@MailpileTeam, Mon, 22 Jan 2018 21:25

Oh, hi! We're not dead. In fact, we're in the process of hiring a project manager to get the ball rolling a bit more visibly again. More news soon.
@MailpileTeam, Thu, 16 Nov 2017 00:21

Have you tried the Mailpile Debian 1.0rc1 packages? We're looking for feedback on what works and what doesn't.
@MailpileTeam, Mon, 21 Aug 2017 10:45

As announced at #SHA2017, we now have a first release candidate for Mailpile 1.0. Linux (deb) packages are here:
@MailpileTeam, Wed, 16 Aug 2017 16:30


Please do not send mail to