Email service provider recommendations June 19, 2020 on Drew DeVault's blog

Email is important to my daily workflow, and I’ve built many tools which encourage productive use of it for software development. As such, I’m often asked for advice on choosing a good email service provider. Personally, I run my own mail servers, but about a year ago I signed up for and evaluated many different service providers available today so that I could make informed recommendations to people. Here are my top picks, as well as the criteria by which they were evaluated.

Unfortunately, almost all mail providers fail to meet my criteria. As such, I can only recommend two: Migadu and mailbox.org.

#1: Migadu

Migadu is my go-to recommendation for a mail service provider.

Advantages

Disadvantages

Full disclosure: SourceHut and Migadu agreed to a consulting arrangement to build their new webmail system, which should be going into production soon. However, I had evaluated and started recommending Migadu prior to the start of this project, and I believe that Migadu fares well under the criteria I give at the end of this post.

#2: mailbox.org

Mailbox.org may be desirable if you wish to have a more curated experience, and less hands-on access to postmaster-specific features.

Advantages

Disadvantages

Others

Evaluated but not recommended: disroot, fastmail, posteo.de, poste.io, protonmail, tutanota, riseup, cock.li, teknik, runbox, megacorp mail (gmail, outlook, etc).

Criteria for a good mail service provider

The following criteria are objective and non-negotiable:

  1. Support for open standards including IMAP and SMTP
  2. Support for users who wish to bring their own domain

This is necessary to preserve the user’s ownership of their data by making it accessible over open and standardized protocols, and their right to move to another service provider by not fixing their identity to a domain name controlled by the email provider. It is for these reasons that Posteo, ProtonMail, and Tutanota are not considered suitable.

The remaining criteria are subjective:

  1. Is the business conducted ethically? Are their incentives aligned with their customers, or with their investors?
  2. Is it sustainable? Can I expect them to be around in 10 years? 20? 30?
  3. Do they make unfounded claims about security or privacy, or develop techniques which ultimately rely on trusting them instead of supporting or improving standards which rely on encryption?1
  4. If they make claims about privacy or security, do they explain the limitations and trade-offs, or do they let you believe it’s infallible?
  5. Do you trust them with your personal data? What if they’re compelled by law enforcement? What is their government like?2

Bonus points:

If you represent a mail service provider which you believe meets this criteria, please send me an email.


  1. This also rules out ProtonMail and Tutanota, doubly damning them, especially because it provides an excuse for skipping IMAP and SMTP, which conveniently enables vendor lock-in. ↩︎

  2. This rules out Fastmail because of their government (Australia)’s hostile and subversive laws regarding encryption. ↩︎

  3. Alarmingly rare, this one. It seems to be either this, or a captcha like mailbox.org does. I would be interested in seeing the use of client-side proof of work, or requiring someone to enter their payment details and successfully complete a charge instead. ↩︎

Have a comment on one of my posts? Start a discussion in my public inbox by sending an email to ~sircmpwn/public-inbox@lists.sr.ht [mailing list etiquette]

Articles from blogs I read Generated by openring

Command PATH security in Go

Today’s Go security release fixes an issue involving PATH lookups in untrusted directories that can lead to remote execution during the go get command. We expect people to have questions about what exactly this means and whether they might h…

via The Go Programming Language Blog January 19, 2021

Status update, January 2021

Hi all! This month again, my main focus has been wlroots. I’ve focused on the internal renderer refactoring (the so-called “renderer v6"). A lot of the work has now been completed, and all backends now use the new interfaces under-the-hood. With the help …

via emersion January 18, 2021

What's cooking on Sourcehut? January 2021

Another year begins, and hopefully with better prospects for us all. SourceHut has emerged from 2020 relatively unscathed, thankfully, and I hope the same is true of most of our users. A body which, by the way, today numbers 19,647 strong, up 623 from Decemb…

via Blogs on Sourcehut January 15, 2021