Create private self-hosted email aliases on the fly

Email aliases are one of the most effective solutions to protect your privacy in the age of surveillance capitalism.

Your personal email is one of the most precious personal resources.

It's one of those rare examples of software technologies that are still relevant more than 50 years after their invention. Its specifications have remained mostly unchanged through all of this time, and we use it for all kind of important things - most notably, as an identifier to log in on most of the Web.

Changing it if compromised is as hard as changing your phone number. Just like changing your mobile number usually involves sending hundreds of messages to all the contacts on your list, so changing your email address usually involves hopping through hundreds of contacts reset forms and 2FA procedures.

You wouldn't easily share your personal phone number with any stranger on the street. And yet, most likely, you regularly share your personal email address with any website that asks you for it.

Being a great candidate for a unique personal identifier, an email address is often the glue that holds more granular data points together (cookies, tracking pixels, Web beacons...) in order to trace a very detailed profile of you as a person that can easily be sold through data brokers to anyone who pays enough for it.

Email aliases make that picture of you less valuable on the data surveillance market by removing that glue.

If you searched for shoes on an online shopping website, and you logged into that website with the same email that you use on your favourite social media platform, you shouldn't be surprised to see some advertisement of shoes on your social media timeline too.

Now multiply the individual e-commerce + social media combination for all the possible combinations of websites that may share your data with one another directly or indirectly, and you get how easy it is for data brokers to paint a very accurate picture of you - and how the combination of private email aliases and mechanisms that block 3rd-party cookies and trackers can throw a wrench into that machinery.

And imagine the case where you use a standard single personal Gmail address to sign up to most of your services. Not only you are providing an army of data brokers out there with a great unique identifier to use to connect together all the pixels of your soul, but you're also providing a single huge advertisement company with access to all of your confirmations, newsletters, orders and customer service interactions to paint an even more accurate picture of you than the one they already have.

Instead, if you registered to the e-commerce and the social media websites using two different email addresses, and took care of disabling 3rd-party cookies, and of installing a few browser extensions that block cross-site trackers, 3rd-party cookies and external login buttons, then it becomes harder to make that connection. The online shopping website may know what you searched, and the social media platform may know what you scrolled and watched, but without an easy common connection it's hard to link that data together to paint a more accurate picture of you.

Not only, but per-domain email aliases also provide you with a big red button to completely stop emails from a certain sender. Did you register to an e-commerce website a while ago and you keep receiving promotional emails from all kind of partners you never heard of, even if you changed your privacy settings on that website and unsubscribed from all the campaigns? No problem - just delete your alias, and all those emails will go to /dev/null.

And it also provide a very intuitive way to automatically sort your emails. If you only use a limited amount of email aliases to sign up to newsletters, then just throw them all in a Sieve filter - any email sent to them will be automatically sent to the newsletters folder.

In this article we will cover:

• The options available on the market if you want an out-of-the-box (and, in most of the cases, paid) solution to manage your email aliases;
• How to set up a self-hosted option. We will cover in particular:
  • How to set up your own mail server with Postfix (but without delving into too much detail, as there are already dozens of detailed guides online for this process);
  • How to configure virtual mail aliases on your server;
  • How to use Platypush to automate the creation of those aliases;
  • How to use ntfy as an easy way to trigger the creation of a new alias - and subscribe your Platypush installation to listen on the topic where you send those requests;
  • How to use Tasker on Android to manage the creation of new aliases in a couple of taps directly from your mobile device.

The options on the market

These are the main out-of-the-box options available on the market if you are ok to spend some money.

ProtonMail

I have been using Proton since it was opened to the public in 2016.

Its record may probably not be spotless from the perspective of a privacy purist, but so far the only cases where Proton shared user details was when authorities were involved, and only in extreme cases such as death threats, binding orders from Swiss authorities or other borderline cases. In spite of a few exceptions, Proton can probably be considered on of the most privacy-respecting companies in today's creepy IT industry.

The killer feature that sold me their product back in the day (and the main reason why I keep using today) is the ability to link multiple email addresses to your main account.

These can be either email addresses managed by Proton itself, or, if you manage your own mail server, you can bind your own domains (it's just a matter of changing the SPF, DKIM and DMARC records on your DNS) to get Proton to manage those mailboxes for you.

It requires however a paid plan, and even in my cases (with an Unlimited plan) there is a limit of 15 email addresses.

As of March 2024 Proton has also added the ability for paid users to generate unlimited read-only email aliases/masks. This is exactly the kind of feature that we want if we want to have a pool of addresses big enough to prevent as many data points as possible from being linked to us, but it comes with a couple of downsides:

➖ The feature is only available to paid users - it's not a lot though, $4/month for the most basic package, but still more than the most basic plan for Firefox Relay Premium, which offers more features.

➖ The UX for generating new masks may not be ideal - generation is only possible in the Web UI or through the desktop client.

➖ No possibility to customize the email aliases (only random aliases will be generated), nor the domain/subdomain (only @simplelogin.com).

Firefox Relay

Firefox Relay is great.

It's been around since 2021, and I've been using it since then as the primary way of generating my email masks.

➕ Being developed by Mozilla itself, it has great integration with Firefox and a dedicated browser add-on that works also on mobile, and it lets you generate new masks very quickly through an overlay button added to all email field on Web pages.

➕ Free accounts can create up to 5 randomly generated email masks. Firefox Premium users have unlimited masks, either random or with custom names, and the possibility of creating a custom subdomain (e.g. @spambox.mozmail.com) for their aliases.

➕ Native possibility to block promotional emails.

➕ Very affordable - the basic service starts from $1/month.

➕ It's very easy to disable a mask - the link is directly added to the forwarded emails.

➖ It supports a maximum message size of 10MB - but at least it's better than their initial limit of 150KB.

➖ Mileage may vary. After a few years of usage I have noticed that some domains refuse to deliver emails to the Relay domain or its subdomains. Luckily it's not many of them, but enough to create problems sometimes. I have recently experienced an issue where I got myself locked out of my TicketMaster account while trying to change my email address to use a Relay mask instead, and after completing 2FA I couldn't receive the email to finalize the change.

➖ I trust Mozilla a bit less than I trust Proton when it comes to the handling of my data - controversies such as data broker removal services managed by data brokers and weird updates to their ToS aren't new to them.

➖ Just like Google, Mozilla is also a company quite notorious for killing its services, often with very short notice. One of the last things I'd want is for the relay service that manages most of my email IDs to shut down in the future and shut me out of my own accounts in the process.

The self-hosted way

Unhappy with the trade-offs of the commercial email relay services, I have recently embarked in building a service that allows me to easily generate my own.

Let's break down the steps involved in this process.

The mail server

Feel free to skip this section if you already have a personal mail server.

I won't lie to you: running your own mail server isn't easy.

The configuration process is quite tedious, but you can find some very good guides (like the one from DigitalOcean or the Arch Linux wiki) on how to spin up a modern mail server with Postfix (mail transfer agent), Dovecot (IMAP/POP3 server) and Spamassassin.

I advise to follow the guide from DigitalOcean as much as possible. Unlike the Arch wiki and most of the other guides, it shows how set up your domains, users and aliases configuration on an external database rather than in Postfix' configuration files - this makes it much easier to change the configuration on the fly.

The DigitalOcean guide is however quite dated, so feel free to cross check against the Arch's guide for anything that might have changed.

Getting your emails actually delivered

After setting up your mail server, there's actually the most painful part: getting your email delivered to mailboxes managed by Google or Microsoft.

Those two companies together host a huge share of all the email accounts used in the world - the share is 22-28% for Google and >10% for Microsoft. Their combined shares increase to much more than half of the total number of email accounts if you consider only Europe and the Americas.

And they are also quite notorious for being extremely picky when it comes to accepting emails from other (especially self-hosted) domains.

You'll find plenty of tips online to get your emails delivered to accounts hosted on their servers. But since both the companies are known for being very opaque about how they calculate their domain risk scores (and probably for good reasons, getting the secret recipe would be a jackpot hit for many spammers) it's a lot of trial-and-error, a lot of waiting before your server has been online for long enough for them to trust it, and a lot of factors that can just end up with all emails from your server to be blocked (such as the use of either a residential dynamic IP for the server, or an address from the subnets of some cloud providers).

After a long time trying, I decided to give up trying to read their minds, while not even being guaranteed to receive or send emails to their mailboxes.

The quickest solution is probably to configure Postfix to use a relay that is already trusted by the major email providers.

In my case I've been using DuoCircle for quite some time, and they also provide some good documentation on how to set up Postfix to use their relay.

Technically their service is paid and you'll have to enter a credit card upon registration, but in practice the threshold for being billed in so high for an average personal case (like >1000 emails sent per month) that in all this time using the service I have never been billed once. Also, I have almost never encountered a case where emails from my mailbox were not received.

A relay basically instructs your Postfix server to forward your outgoing emails through the configured server, which will be in charge to deliver it to the recipient. Incoming email will instead be sent directly to your server. By using a known relay with a good reputation you can start sending emails right away without having to follow esoteric rituals to get your new server in the graces of Google and Microsoft.

Configuring the aliases

If you followed the guide on DigitalOcean you should have a mail server configured with a MySQL/MariaDB backend to store your domains, users (actual mailboxes that you can access with username+password and can send email from) and aliases (which must point to an actual user record).

I also recommend to register at least two domains on the mailserver - one will be used by your actual users, and the other only by your email masks. It adds an additional layer of meddling to the patterns that data brokers may harvest.

This is a likely list of SQL statements to kickstart your mailserver database:

After creating your records, try and validate the setup by sending an email to your newly created alias (dontsend@spam.com in the snippet above). If everything is configured correctly you should get the email forwarded to your personal address.

Set up ntfy

ntfy is a great simple service with a simple purpose:

• It exposes a Websocket topic-based interface where any client can listen for messages
• It exposes an HTTP API that allows any client to send messages to those topics

And it integrates quite well with Platypush without having to deal with MQTT, Kafka, Redis or other asynchronous pub/sub architectures that usually require more dependencies.

Running your own ntfy instance over Docker is quite straightforward, but if you don't want to host the service, configure the reverse proxy etc. you can also use the main public instance, or any other public instance.

Once you have the Web app and/or the mobile app, using ntfy is quite straightforward: simply subscribe to two topics from the Web UI or the mobile app - one for your mail aliases requests and one for the responses from the server.

NOTE: since ntfy doesn't provide HTTP authentication by default you should consider your topic names as sensitive information, and preferably append some random identifier at the end to make unauthorized access much harder.

Automate the creation of aliases

We will use Platypush to:

• Listen for alias creation requests on a ntfy topic
• Create the alias on the mail server database
• Send a notification with the created email address to a dedicated ntfy topic

Start the service via docker compose up.

Now test that everything works by sending a request for an alias to your ntfy requests topic. The semantics of the script works as it follows:

• If the message is empty or contains a single . then a random email aliases will be generated for the domain you specified.
• Otherwise, a new email alias in the format your-msg@your-domain.com will be generated.
• If successful, the script delivers the newly created email address to the responses topic - any client that subscribed to it will receive it.

Mobile setup

This solves the problem on desktop, but the procedure is a bit clunky on mobile.

Thanks to Tasker we can make it much easier on Android.

Here you can find a task that I've put together that does a simple job:

• It promps the user to specify the username for the new alias (empty strings are not supported, but if you want to generate a random alias you can simply pass .);
• It sends the request to the ntfy topic to create the alias.

Download it and replace the strings marked with TODO in the file with your actual configuration (namely, the ntfy host and topic you configured for your requests).

Then you can import the task in your app this way:

• Open Tasker
• Long press on Tasks
• Select Import Task

Note that this requires the ntfy app to be installed on your phone.

It's also advised to subscribe through the app to the email aliases response topic, so you can get a notification on your phone when a new alias is created and you can copy it on the fly.

A great feature of Tasker is the ability to export tasks as stand-alone apps. The procedure is simple:

• Long press on the task
• Select Export
• Select As App

At this point your task can run outside of Tasker. You can add the launcher to your home screen so you can create email aliases on the fly. Or, if your device and Android version support it, you could even associate the app to some custom physical buttons or gestures.

The next time you have to sign up to a new web site you've got a quick way of creating a private email alias just for it - without limitations, and without having to pay any subscriptions!