Today I finally ditched Google for my personal domain’s email.

Google has announced that on May 1, 2022, it’s ending the free tier I’ve been using for more than 10 years to host my domain’s email. I knew this was coming long ago, but I was lazy.

The easiest way to solve this is moving the kids email accounts to free email accounts, and paying Google $3/user monthly for the remaining accounts for the first year and $6/user afterwards¹. I don’t like this solution. For many reasons, I’m not so fond of Google the advertising company anymore. Why would I choose for my kids a free email provider with most of the issues I’m trying to avoid by moving away from Google?

My main criteria for looking for a new provider, aside from pricing considerations, was looking for a stable company with supports for open standards, i.e., IMAP and SMTP. This is important because I want to minimize vendor lock-in. For example, it allows me to keep a local backup my email.

For example, Hey may be a great platform from the email-workflow point of view. I have great respect for Basecamp and its founders. But not being able to import my existing messages to their platform is a deal breaker for me. Something similar applies to ProtonMail and other alternatives.

Apple Blues

My first attempt was trying iCloud+ custom domain’s feature. Maybe you don’t like Apple. Apple as a company may have its flaws, but selling your information to third parties or intentionally compromising your security and privacy is not one of them.

iCloud+ custom domains would have allowed me to create an email account for each family member, using the storage I’m already paying for. It didn’t work, however. Innocent of me. I should have suspected of anyone recommending to surround your SPF record with double double-quotes. I spent hours tweaking my DNS configuration, even changed DNS servers… but iCloud+ refused my domain insisting it couldn’t find my SPF records. (mxtoolbox had no trouble finding the records, however.)

I searched for a solution in countless forums, subreddits, etc. I commiserated with other people with SPF records problems. Finally, I found what seems the most likely explanation: iCloud+ doesn’t allow you to use a domain associated with your Apple ID as a custom domain. Anyway, by then iCloud+ custom domains had more than exhausted my time and patience without any results. Bad starter for what should be a long term relationship.

Migadu

After discarding naive and dangerous thoughts about self-hosting my email, I remembered about Migadu. I found about Migadu thanks to Drew DeVault’s excellent blog. They not only offer fair pricing and email support, but they base their pricing on resource allocation, not user accounts. That means you pay for storage and bandwidth, and can create as many email accounts for your domain as you need.

I signed for a trial account and set up my DNS records as recommended by Migadu’s no-nonsense clear documentation. In minutes I was using imapsync to copy my mail from Google’s servers to Migadu. It worked flawlessly, the first time. (Copying everything took longer because of the volume of messages involved.)

In 30 minutes I was changing my trial to a paid plan.

Some time ago I subscribed to r/selfhosted, a subreddit about “alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.”

It’s difficult not to resonate with the ideals of the self-hosted movement: being in control of your data, retaining privacy, no vendor lock-in… As a friend of mine would say, who can argue against freedom? In practice, however, nowdays people don’t want to run their own servers, even if they know how to do it.

For years I’ve hosted blogs on my own server. At different times I ran my own mail server. Not anymore. I don’t want to run a server if there is an alternative. I’m migrating my sites to Jamstack alternatives when possible.

For example, at the time of this writing this site is running on Netlify. Its content resides in a private Github repository, and Netlify automatically rebuilds the site using Hugo every time I publish a new article by pushing it to the repository. I don’t need to manage nor do care which Linux distribution they are deploying. I don’t need to apply the latest security patches to keep the OS up to date. I don’t care if they are serving my content using Apache or other webserver. They provide the results I need.

For 2022, I’ll migrate my other other site to Hugo, and publish it on Netlify or Vercel.

When possible, use a Jamstack or similar solution. Focus on delivering value, automate or delegate the rest.

Last year I read this article by Derek Sivers. What he proposes is to ignore arbitrary calendar dates if they don’t make sense.

We are on the second week of 2022 and I have a bad feeling in my stomach because I’ve not gone through last year’s review, nor finished my planning for 2022.

That’s not exactly so, because I’ve spent some hours here and there in November and December taking notes, reflecting on 2021, and thinking what I want to achieve in 2022. Also important, I’ve been pondering how I’m going to achieve those goals. What I need is some hours of quiet time to wrap things up, polish my systems/routines, and declare a new year.

What is nagging me is that I need to deliver some enhanced functionality for IDECON’s platform, and it has been taking me more time than expected. I need some days of deep work, and having three diverging priorities each day is not going to work.

So, returning to Derek Siver’s idea, I’ll finish planning the year as soon as I finish coding.

I was recently in the process of upgrading a system running Django 2.2 to 3.2. Django 3.2 requires Python 3.6+. This system is running on a cloud instance of Ubuntu 16.04, which only supports Python up to 3.5.

Upgrading the server to Ubuntu 18.04 or 20.04 is out of the question. (Just the thought of someone typing do-release-upgrade in a production server makes me shiver…) Also, the system is from a pre-docker era, so no luck there.

The cleanest way to run a more recent Python version is to install pyenv. pyenv is a Python version management system which takes care of downloading, compiling, and installing the Python version you need without messing with the system configuration.

Python now requires OpenSSL version 1.1.1+, and Ubuntu 16.04 only provides OpenSSL up to version 1.0. So, if you try to install, for example, Python 3.10.0 using pyenv, you’ll get an error complaining about OpenSSL. (The error is actually silent. You’ll need to run pyenv with the verbose/-v in order to see the output.)

$ pyenv install -v 3.10.0


(Several lines and minutes later...)
ERROR: The Python ssl extension was not compiled. Missing the OpenSSL lib?

$

To fix this:

Install OpenSSL 1.1.1 from source:

Compile OpenSSL and install it.

   $ wget https://www.openssl.org/source/openssl-1.1.1l.tar.gz
   $ tar xvfz openssl-1.1.1l.tar.gz
   $ cd openssl-1-1-1l
   $ ./config
   $ make
   $ sudo make install

Add /usr/local/lib and /usr/local/local/lib64 to your library path in .bashrc (or whatever your system uses) and reload your shell using $ exec $SHELL.

export LD_LIBRARY_PATH=/usr/local/lib/:/usr/local/lib64:$LD_LIBRARY_PATH

Check that OpenSSL installed OK:

   $ openssl version

   OpenSSL 1.1.1l  24 Aug 2021

Tell pyenv where are the OpenSSL files located so the compiler and liker can find them and then run pyenv to install the desired Python version.

$ export LDFLAGS="-L/usr/local/lib/ -L/usr/local/lib64/"
$ export CPPFLAGS="-I/usr/local/include -I/usr/local/include/openssl"
$ export PYTHON_CONFIGURE_OPTS="--enable-shared"
$ pyenv install -v 3.10.0

You should have now a working Python 3.10.0 that you can use with pyenv.