Keeping my email sorted (the hard way)

I have recently made some changes to my email setup. In this post I’ll explain the motivation behind these changes and what I did in practice.


When I got my virtual machine up and running at - the one where this website is hosted - I originally planned to host my private email server there too. I knew this was probably a hard task, but you know, everything is hard until you learn how to do it.

I wanted to do this for a couple of reasons. The main one was to use my email address, but I also liked the idea of staying away from large internet companies (my main email address was connected to my Google account). Not that there is anything inherently wrong with using services from this big companies, but I like the idea of not being too dependent on them.

After reading a nice tutorial at I was a bit discouraged. The guide was well-written, all the steps seemed doable if taken one by one, and I was happy to have dug into this topic because I learned a lot. However, an email server apparently consists of a lot of moving pieces: an smtp server, spam filter, DNS, DKIM… it is a lot to keep track of. Even assuming that I would be able to set this thing up AND to keep in mind what each of these pieces does, as soon as a problem of any kind arises - config-breaking updates? domain registration expiring? me messing up with my VM and making it unreachable? - I knew I had to be one to fix the mistake. And I cannot afford to be immediately available whenever something bad happens. Sometimes I might just have a full week were I don’t have time to fiddle around with smtpd and whatnot, and I can’t afford being unreachable via email for a week.

My old setup (until September 2022)

Having abandoned the idea of self-hosting, I looked for alternatives. I figured that if my goals were just to use my own domain and stay away from Google, I could sign up for a smaller email provider that offers custom domains. It turns out there are a lot of them. After some careful considerations I decided to go with I like their transparency and privacy focus and the fact that they are based in the EU. I pay 3€ per month (the 1€ tier does not offer custom domains) and I am happy with their service.

Setting up the server side was quite simle. Using custom domains requires a tiny bit of work, but it was all well explained in the FAQs.

On my local machine I used (and still use) the amazing mblaze, which is essentially MH for Maildir folders. In practice, mblaze is a set of commands to manage emails directly from the command line, without using a graphical environment or a TUI like Mutt. This system is incredibly flexible, check it out if you don’t know it!

Being just a mail user agent, mblaze cannot retrieve or send email. These tasks can be accomplished by other small pieces of software: I used msmtp for sending email and mpop for downloading it from’s server. As the name suggests, mpop uses the POP3 protocol instead of the more common IMAP. The main difference is that POP3 simply retrieves your email, while IMAP keeps the server and client folders synchronized. There are many advantages and disadvantages to this choice, I won’t go into detail on them in this post.

As for my other devices, my local mailfolder is kept in sync with my server using syncthing. I also use an amail client on my phone with IMAP, connected directly to the mail server.


Since I am subscribed to a couple of high-traffic mailing lists that I read just for curiosity, it is necessary for me to have an easy way to download and view regular emails separately from that coming from mailing lists.

This was kinda easy to set up with mpop’s filters, but my configuration was a bit of a hack. One disadvantage of this soution was that it only solved the problem on my laptop(s). On my webmail and on my phone, my inbox was a complete mess of mailing lists, newsletter and a few important emails.

After thinking about it for a while I figured that an elegant solution would be to set up alternative email addresses for receiving mailing list emails, like Then I would manage those different mailboxes separately.

Setting the aliases up on was easy, but unfortunately all my address used the same inbox, so I did not solve any problem at all. I could add some sub-folders and set up filters so that incoming mail gets sorted out, but the app on my phone could not read sub-folders and mailbox did not allow top-level folders (or I could not find a way to create them). Besides, tinkering with IMAP folders was not something that I found particularly exciting.

But there was another solution…

My current setup (since September 2022)

I decided to try and redirect the mailing list emails to my personal server. Configuring OpenBSD’s smtp to receive emails from one specific outside source (my account) and sort them into some local folders is order of magnitudes easier than setting up a full-fledged email server. No problems with DKIM, no incoming spam, no nothing.

It took me a few hours to figure our how to do this, but in the end it is just a matter of configuring a few filters on and adding a couple of lines to /etc/mail/stmp.conf. filters

On my webmail I simply set up a filter to redirect any email sent to (a made-up name for the mailing list I am subscribed to) to my private server. No copy of these emails is kept on the server, so they don’t clutter my normal (IMAP) inbox. I risk missing a few of these emails if my server goes down, but it is a public mailing list and I can always check the archives online.

I could not just send these emails to, otherwise they would simply be taken care of by mailbox - the MX records for my domain point to their servers. But it turns out you can send mail to a server using its IP address, as long as the server is configured to accept such mail. So I set up the redirects to list@[] - where is the IP address of my server.


The second step is configuring smtpd, OpenBSD’s default mail server daemon, to deal with incoming email.

First of all we need to list the virtual user list in /etc/mail/aliases so that any mail sent to it is interpreted as being sent to my regular user.

# cat 'list: sebastiano' >> /etc/mail/aliases

Then we have to change the line listen on lo0 to listen on all in /etc/smtp.conf.

Then we need to add an action and a match lines to the same file:

# cat << EOF >> /etc/mail/smtpd.conf
> action "list" maildir "~/mail/list" alias <aliases>
> match from any for rcpt-to "list@[]" action "list"

And finally restart smtpd with rcctl restart smtpd.

This does the trick: now all email I receive from the mailing list is redirected by my mailbox account to my private server, where smtpd takes care of sending it to the mail directory ~/mail/list.

No mpop needed

Once the mail is delivered to ~/mail/list, I can get it from there to my laptop in any way I like - for example using syncthing, like I do for all my important files. In this way the mailing list emails are regularly downloaded and kept in sync, and I don’t need to use mpop to retrieve them.

This is quite convenient, one less piece of software to keep track of! In fact, I can do the same for all other email I receive. I just need to set up the appropriate rules on mailbox: this time I want the mail to be sent to sebastiano@[] and a copy to be kept on the server, so that I can easily access it from my phone’s app as well. Then I add two slightly different lines to /etc/mail/smtpd.conf:

# cat << EOF >> /etc/mail/smtpd.conf
> action "seb" maildir "~/mail/inbox" user sebastiano
> match from any for rcpt-to "sebastiano@[]" action "seb"

And the new setup is ready!

Sending email

I did not change the way I send email: I still use msmtp.

Happy now?

Yes, this new setup works and I am always happy when things work. Of course, one might make the case that things worked before as well…

I am happy that I could work my way around a basic smtpd configuration. Besides being useful knowledge on its own, it may make a second attempt at self-hosting my email less daunting. I don’t know if I am ever going to try that, though.