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 openbsd.amsterdam - 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
@tronto.net 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 poolp.org 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 mailbox.org. 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 mailbox.org’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
firstname.lastname@example.org. Then I would manage those different
Setting the aliases up on mailbox.org was easy, but unfortunately all my
@tronto.net 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 mailbox.org 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 mailbox.org
and adding a couple of lines to
On my mailbox.org webmail I simply set up a filter to redirect any email
email@example.com (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
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
188.8.131.52 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
/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
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 "firstname.lastname@example.org" action "list" > EOF
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
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
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
email@example.com and a copy to be kept on the
mailbox.org server, so that I can easily access it from my phone’s app as
well. Then I add two slightly different lines to
# cat << EOF >> /etc/mail/smtpd.conf > action "seb" maildir "~/mail/inbox" user sebastiano > match from any for rcpt-to "firstname.lastname@example.org" action "seb" > EOF
And the new setup is ready!
I did not change the way I send email: I still use msmtp.
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.