It must be said: big tech companies offer great e-mail solutions. Good, user-centric applications along with attractive pricing make for a golden combination that is hard to pass up. Running your own e-mail server on dedicated hardware – and having a team of administrators on call to solve problems – seems ludicrous when you can get the same kind of support from the cloud.
Still, we decided we wanted to reduce our reliance on these all-inclusive services because of the political, legal, and operational risks we observed — including the potential for external interruption of critical services.
Why we decided to move away
It comes as no surprise that US companies such as Google and Microsoft are bound by US law. These companies should not offer products or services to entities that are subject to international sanctions. The US federal government should be able to inspect data kept by US businesses in the interest of national security. This is not unexpected, unknown or unfair. and should only become a problem when the interests of the US and EU member states are not aligned.
Unfortunately this became all too clear when Microsoft (allegedly) interrupted it’s e-mail service for a prosecutor of the International Criminal Court based on an executive order. The ICC has now decided to migrate away from Microsoft’s services, and organizations throughout the EU are now aware of the severe risk this “kill-switch” can pose.
Back in February we wrote about the shift in global political relations. People were worried about what this could mean for their organizations as their reliance on US owned tech was becoming a risk. Now that we’ve had a preview of what this dependence means, we decided to try out free or open source alternatives to see if we could limit our exposure to non-EU big tech. The results are encouraging, but we are no where near a situation where we can truly operate independently.
Replacing Office365 E-mail
One of the first things we wanted to migrate is e-mail hosting and delivery. We used to have a Microsoft Office365 subscription that manages all of our incoming and outgoing e-mail. Now that we have to move away, our inner sysadmin instincts started to act up, asking why we wouldn’t want to run our own e-mail server? If you want to have full control over where your e-mail is stored and how it is delivered, nothing beats running your own e-mail service.
Note: if you want to avoid the hassle of running your own services, there are plenty of cloud-based solutions for e-mail services such as Proton or Strato.
After looking around for different virtual server and hosting solutions – and finding an excellent one with Cyso – we looked into mail-server solutions. We didn’t want to go into the details of e-mail delivery and management too much, so the free Mailcow Dockerized offering was right up our ally: it allows for self hosting, as long as you have enough experience with Linux and Docker. The setup documentation is clear and complete, and after about an hour of configuring we had our e-mail service running.
One thing that we could not do ourselves, however, is e-mail delivery. Years of spam and abuse have made it impossible for servers with IP-addresses that do not have a good reputation to deliver any e-mail over SMTP. Moreover, companies offering virtual servers often block outgoing SMTP ports to prevent spam originating from their IP range. Luckily, this can be solved relatively easily by employing the services of an e-mail relay company (we picked MX-Relay).
Now that e-mail was up and running, we needed to migrate our old e-mail from Office365 to Mailcow. We managed to export our e-mail as a PST using the Exchange Administration console, and import it using a relatively old e-mail client on Linux called Evolution. There might be other ways of importing a PST into your mail account, but this one worked for us. Note that this did require us to migrate each e-mail individual e-mail account separately.
Finally we added a daily backup mechanism based on BorgBackup. Mailcow offers some convenient config definitions and docker containers to set this up without too much hassle.
It has been nearly a year since we transitioned from Office365 to Mailcow. E-mail is running smoothly and we have all of our mailboxes stored on our own servers. We’ve been able to cut the cord from Microsoft and we’ve gained some advantages to using Office as your e-mail solution. But there are downsides as well.
Upsides
- Running your own e-mail server allows you to create new e-mail accounts at no additional cost. You can have as many e-mail accounts as you want, as long as your hardware and disk space can keep up.
- You can also run multiple domains on the same server. Next time we launch a new startup or product, we just co-host the e-mail server on the same instance!
- The features you want to use are not based on how much you pay. You get everything Mailcow Dockerized has to offer out of the box.
- Integration with an office platform like NextCloud is available.
Downsides
- You can forget about easy, one-click setup. We knew we we’re going down a rabbit hole when we allowed our sysadmin instincts to get the better of us. Still, setting up a virtual server and deploying Mailcow is not for the uninitiated. I would not recommend people to vibe through the setup using an AI agent.
- Depending on your requirements, renting a virtual service along with SMTP relay can set you back €100/month minimum. Whether you break-even compared to Office365 depends on the number of accounts you administer.
- Do not discount the time spent on maintaining your virtual server infrastructure and updating Mailcow. Updates occur frequently and the process is setup well, but it does require your full attention – no one wants to be that person who accidentally purged all e-mail during an update.
What’s next
Office offers a lot more than just e-mail. In an upcoming post we will look at our experiences moving to NextCloud, a free and open-source office suite replacement.
Leave a Reply