In short. Open-source email software publishes its code, so anyone can read how it works and look for mistakes. That helps with the code that runs where you can see it: an app on your device, the code your browser loads for webmail, or a mail server you run yourself. It doesn’t show what a provider runs on its own servers, and open code isn’t the same as reviewed code.
What open source means
Open source is more than being able to read the code. Under the Open Source Definition, the license has to let anyone share the software, change it and share their changed versions, and the published code has to be the form a programmer would actually work in, not a deliberately obscured one [1].
For email, “open source” can describe three different things, and a provider may open some of them and not others. Each of them is also built on libraries, other people’s code for things like encryption, which may be open or not:
- An email app on your computer or phone. It connects to your provider and handles your mail and password on your device.
- Webmail, the email you open in a browser tab. Each time you open it, the browser downloads a copy of the code from the provider’s server and runs it [2].
- A mail server, the software that stores mail and passes it to other servers. Every message travels from the sender’s server to the recipient’s, whatever app either person uses [3].
When a provider says it is open source, ask which of these parts are open.
The code on your side and the code on the server
Open code is most useful for the part that runs on your side. With end-to-end encryption, messages are encrypted and decrypted on your device, in the app or the webmail code: what end-to-end encryption is. If that code is open, anyone can read in it:
- what is encrypted on your device before it’s sent, and what isn’t;
- where the app sends its requests;
- which data it hands to the server.
The server is different. Even if a provider publishes its server code, you can’t see which code actually runs on its machines, or what it keeps there. And most mail from other providers arrives as ordinary email, readable by the receiving server until it’s encrypted for storage: what zero-access encryption covers. That step happens on the server, where open code can’t show you what runs.
If you run an open-source mail server yourself, you know what runs on it, because you become the provider: the updates, the backups and the spam are yours to handle, and your mail still travels through the recipients’ servers [3].
Is the app you run built from that code?
Published code tells you what an app should do. Whether the app on your screen was built from it is a separate question, and reproducible builds answer it.
A build is reproducible when anyone who takes the same source code, build environment and build instructions gets bit-for-bit identical files. The comparison is usually done with cryptographic hashes [4]. That lets people outside the project confirm that the files you download match the published code [5].
- An installed app. If its builds are reproducible, people can rebuild it and compare the result with the app that is handed out.
- Webmail. The code arrives from the server every time [2]. A check shows what the server delivered to you at the time you checked. The browser doesn’t compare anything by itself, so a check can’t stop a server from delivering a changed version to someone: a swap can only be noticed afterwards, and only by someone who was sent the changed version and checked it.
What open code doesn’t prove
- That anyone has reviewed it. Heartbleed, a serious flaw in OpenSSL, the open-source library behind many encrypted connections, was released in March 2012 and fixed in April 2014 [6]. The code was open for more than two years before the flaw was fixed.
- What runs on the provider’s servers, and what the provider keeps about you there. Open server code doesn’t show this.
- That your copy matches the code, unless the build is reproducible and the copy you run is the one compared.
- What the provider sees about your mail. Even with open code and end-to-end encryption, the servers handle who wrote to whom and when: what email metadata reveals.
Questions to ask any provider
- Is the code of the app or webmail you’ll use open?
- Is the server code open, and which parts of your mail does the server handle unencrypted?
- Are the builds reproducible, and is there a published way to check them?
- Has an independent audit been published, and which parts of the code did it cover?
Our answers, before launch: We will open the source code of the Methmail web app before the closed beta. The server code stays closed for now. End-to-end encryption will run in your browser, and you will be able to check it in the open code. Mail from other providers will be encrypted by our server as it arrives, and that part can’t be checked in the open code. There is no published way to check our builds yet, and no independent audit has been published.
Questions
Is open-source email more secure? Not by itself. Open code makes checking possible; how secure an email service is depends on how it’s designed, whether the code has been reviewed, and what runs on the server, where open code can’t show you anything.
Is an open-source email app enough to keep my email private? The app handles your mail on your device. Your provider still stores your mail and sees its metadata, and whether it can read your messages depends on encryption, not on the app’s license: how to choose a secure email provider.
Can I check webmail code myself? You can read the published code. To know that your browser got that code, the build has to be reproducible and you have to compare the files you were sent with your own build, and the check covers only that one time [4].
What’s next
- What is end-to-end encryption?
- Zero-access encryption: what it is and how to check it
- Most secure email provider: how to check for yourself
Sources
- Open Source Initiative: The Open Source Definition, last modified February 16, 2024. https://opensource.org/osd
- MDN Web Docs: How the web works (“a copy of the webpage code is downloaded from the server to the client machine”). https://developer.mozilla.org/en-US/docs/Learn_web_development/Getting_started/Web_standards/How_the_web_works
- RFC 5321: Simple Mail Transfer Protocol. IETF, October 2008. https://www.rfc-editor.org/rfc/rfc5321
- Reproducible Builds: Definitions. https://reproducible-builds.org/docs/definition/
- Reproducible Builds: Why reproducible builds matter. https://reproducible-builds.org/
- The Heartbleed Bug (CVE-2014-0160). https://heartbleed.com/