logo

drewdevault.com

[mirror] blog and personal website of Drew DeVault git clone https://hacktivis.me/git/mirror/drewdevault.com.git

Mail-service-provider-recommendations.md (5580B)


  1. ---
  2. date: 2020-06-19
  3. layout: post
  4. title: Email service provider recommendations
  5. tags: [email]
  6. ---
  7. Email is important to my daily workflow, and I've built many tools which
  8. encourage productive use of it for software development. As such, I'm often
  9. asked for advice on choosing a good email service provider. Personally, I run
  10. my own mail servers, but about a year ago I signed up for and evaluated many
  11. different service providers available today so that I could make informed
  12. recommendations to people. Here are my top picks, as well as the criteria by
  13. which they were evaluated.
  14. Unfortunately, almost all mail providers fail to meet my criteria. As such, I
  15. can only recommend two: Migadu and mailbox.org.
  16. # #1: Migadu
  17. [Migadu](https://www.migadu.com/) is my go-to recommendation
  18. for a mail service provider.
  19. **Advantages**
  20. - Migadu is a small company with strong values and no outside capital (i.e.
  21. no profit-motivated external influence). Email support and a human being
  22. answers, and their leadership is accessible if you have questions or feedback.
  23. - Their pricing is based on bandwidth usage, and does not rely on artificial
  24. scarcity like limited domain names or mailboxes.
  25. - Has lots of features for your postmaster - you can treat it as a managed mail
  26. server for your organization.
  27. **Disadvantages**
  28. - They have suffered from some outages in the past. The global mail system is
  29. tolerant of such outages - you don't have to worry about messages being lost
  30. if they were sent during an outage. Still, being unable to access your mail is
  31. a problem.
  32. - ~~If you are on a trial account, they will put an advertisement into your email
  33. signature. I don't think that it's ever appropriate for a mail service
  34. provider to edit your outgoing emails for any reason, and certainly not to
  35. advertise.~~ Updated 2021-03-12: this is no longer the case.
  36. Full disclosure: SourceHut and Migadu agreed to a consulting arrangement to
  37. build their [new webmail system](https://git.sr.ht/~migadu/alps), which should
  38. be going into production soon. However, I had evaluated and started recommending
  39. Migadu prior to the start of this project, and I believe that Migadu fares well
  40. under the criteria I give at the end of this post.
  41. # #2: mailbox.org
  42. *Update: as of 2023 I no longer recommend this service.*
  43. [Mailbox.org](https://mailbox.org/en/) may be desirable if you wish to have a
  44. more curated experience, and less hands-on access to postmaster-specific
  45. features.
  46. **Advantages**
  47. - Excellent first-class support for PGP, and many other strong security and
  48. privacy features are available.
  49. - Was able to speak to the CEO directly to discuss my concerns and feedback, and
  50. have my questions answered. Raised some bugs and they were fixed in short
  51. order.
  52. **Disadvantages**
  53. - The interface is a little bit too JavaScript heavy for my tastes, and suffer
  54. from some bugs and lack of polish.
  55. - They are a German company serving mostly German customers - German text leaks
  56. into the UI and documentation in some places.
  57. - Completing a Google captcha is required to sign up.
  58. # Others
  59. Evaluated but not recommended: disroot, fastmail, posteo.de, poste.io,
  60. protonmail, tutanota, riseup, cock.li, teknik, runbox, megacorp mail (gmail,
  61. outlook, etc).
  62. # Criteria for a good mail service provider
  63. The following criteria are objective and non-negotiable:
  64. 1. Support for open standards including IMAP and SMTP
  65. 2. Support for users who wish to bring their own domain
  66. This is necessary to preserve the user's ownership of their data by making it
  67. accessible over open and standardized protocols, and their right to move to
  68. another service provider by not fixing their identity to a domain name
  69. controlled by the email provider. It is for these reasons that Posteo,
  70. ProtonMail, and Tutanota are not considered suitable.
  71. The remaining criteria are subjective:
  72. 1. Is the business conducted ethically? Are their incentives aligned with their
  73. customers, or with their investors?
  74. 2. Is it sustainable? Can I expect them to be around in 10 years? 20? 30?
  75. 3. Do they make unfounded claims about security or privacy, or develop
  76. techniques which ultimately rely on trusting them instead of supporting or
  77. improving standards which rely on encryption?[^1]
  78. 4. If they make claims about privacy or security, do they explain the
  79. limitations and trade-offs, or do they let you believe it's infallible?
  80. 5. Do you trust them with your personal data? What if they're compelled by law
  81. enforcement? What is their government like?[^2]
  82. Bonus points:
  83. - What is their relationship with open source?
  84. - Can I sign up without an existing email address? Is there a chicken and egg
  85. problem here?[^3]
  86. - How well do they handle plaintext email? Do they meet the criteria for
  87. recommended clients at
  88. [useplaintext.email](https://useplaintext.email/#implementation-recommendations)?
  89. If you represent a mail service provider which you believe meets this criteria,
  90. please [send me an email](mailto:sir@cmpwn.com).
  91. [^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.
  92. [^2]: This rules out Fastmail because of their government (Australia)'s hostile and subversive laws regarding encryption.
  93. [^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.