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

Update: as of 2023 I no longer recommend this service.

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. ↩︎

Articles from blogs I read Generated by openring

Status update, April 2024

Hi! The X.Org Foundation results are in, and I’m now officially part of the Board of Directors. I hope I can be of use to the community on more organizational issues! Speaking of which, I’ve spent quite a bit of time dealing with Code of Conduct matters latel…

via emersion April 16, 2024

M2dir: treating mails as files without going crazy

Sometime recently in the past I complained about Maildir. You can go read the post, but the executive summary is that I think Maildir uses an actively user-hostile directory structure and extremely convoluted filenames that do not convey any meaning at all. …

via blogfehler! April 15, 2024

Go Developer Survey 2024 H1 Results

What we learned from our 2024 H1 developer survey

via The Go Blog April 9, 2024