Getting Chasquid up and running on Debian

For quite some time I have been looking into setting up my own mail server. But having configured postfix for a little service I run, I’d been cautious making changes into that direction. Postfix offers too many configuration options, too many settings and all in a way that’s too arcane to me; every change in fear of accidentally creating an open relay by accident.

But recently I came across an article by SIDN about four modern systems for self hosting e-mail and I was intrigued. Especially about Chasquid, with its limited scope and focus on security, also through ease of configuration.

Getting started

Actually the tool comes with a nice setup guide. And first bonus, it suggest to just make use apt (although it won’t get you the latest); no special repos. So I made sure a test server I had running was updated to the latest Debian and installed Chasquid according to the Chasquid installation and configuration guidelines.

Errors I ran into

The “promise” was that it would be fairly easy to get up and running with it, but here a few things I ran into:

Clearing other services on port 25

First of all, this was a long running server, I wanted to replace postfix, but having postfix still there resulted in Chasquid and postfix fighting over port 25 (smtp), so I decided just to remove postfix. But this removed also logwatch, a simple tool I use to get daily summaries of my server status. So reinstalled logwatch, but now it came with Exim, which also listens on port 25. Funny how these dependencies work… anyway logwatch obviously wants to deliver emails, but no need for an incoming server running. The final solution: uninstall exim4 (which by dependency again removes logwatch), install the dma package (Dragonfly Mail Agent), which is a known “mta” by logwatch, satisfying the dependency to have one, and doesn’t listen to outside messages. This is why we need simpler solutions. Not more complicated ones.

open domains/%domain%/users: permission denied

I was a bit surprised by this. The Chasquid process runs using its own user (good), but it is not a user in a traditional sense. So I created the first user by prefixing the chasquid-util user-add user@domain command with the trusted sudo command, which basically executes it as root. Hence all directories the command created were created as root and consequentially owned by root.

Fixed it by letting these folders be owned by chasquid:chasquid; but perhaps should have been something the chasquid-util should do automatically.

No SSL/TLS certificates found / At least one valid certificate is needed

I created a TLS certificate using Letsencrypt, but it was connected to the mail-subdomain. So thinking went on; perhaps I also had to add a certificate for the naked domain (without the mail subdomain). But also that wasn’t the solution. Then I read a bit more carefully: the hostname was set to a default from the server. Not the domain I wanted to use for mailing. I updated the hostname to match the server. STILL not the solution.

$ sudo -u chasquid ls /etc/letsencrypt/live
mail.example.com example.com README

Everything is there (as expected, Let’s Encrypt really just works)…

$ sudo -u chasquid ls /etc/letsencrypt/live/example.com
cert.pem  chain.pem  fullchain.pem  privkey.pem  README

Also, plenty of valid certificates now to choose from if the demand is to have just “one valid certificate”.

Then I finally got it… after reading the source code … The docs suggest:

$ sudo ln -s /etc/letsencrypt/live/ /etc/chasquid/certs

But when the directory certs already exists, executing above command creates a symlink to a directory live in /etc/chasquid/certs, but what is desired is that certs directly links to live. I made this error, that cost me more time than this post perhaps suggests, because I forgot to perform the command just above in the docs, a line that suggest to move the existing certs directory to somewhere else.

Up to the next error…

permission denied on the reading of the certificates.

For this it is necessary to run:

sudo setfacl -R -m u:chasquid:rX /etc/letsencrypt/{live,archive}

But this get’s reset everytime certbot renews, so make sure you add a hook. Edit the file /etc/letsencrypt/renewal-hooks/post/restart and make sure at least the following is present:

#!/bin/bash
sudo setfacl -R -m u:chasquid:rX /etc/letsencrypt/{live,archive}
systemctl restart chasquid

Caching directory issue

/var/lib/chasquid/sts-cache wasn’t writable by Chasquid running as chasquid-user. Easily fixed again, by sudo chown chasquid:chasquid /var/lib/chasquid/sts-cache, but this should probably have been part of the installation.

Firewall…

Sigh, my VPS provider has a simple firewall that I configured; next to UWF running directly on the server. Had to open the right ports: 25, 465, and 587.

ClamAV failing

Another attempt at sending email. Both redirect (redirecting to an external inbox) and local inbox failed. Mails got a virus detected warning, even if the body was near empty. I had installed the clamdscan package as suggested, but it threw an error. Since I wasn’t running any antivirus on the other host, decided to revert the installation of this package, for now.

DCIM not working

Sadly, I’m on Debian Bookworm, so a few versions behind. It seems Trixie is soon to be released as stable (stable releases seem to be on a biyearly schedule, and the first version of Bookworm was released about two years ago), which will deliver a more up to date version. There are instructions to get DCIM working using hooks, but I will probably wait for an updated version. I enjoy simplicity, and missing DCIM hasn’t been a major issue for me (as a low volume mailer ;))

Some observations

Other suggestions for the documentation

I’m kinda old school, so first attempt for looking into the logs was doing tail -f /var/log/chasquid.log, only learning that it didn’t exist. Chasquid is a modern tool, so should have checked journalctl -eu chasquid…

Mailing from another domain

The documentation suggests that after authentication you’re open to send as any user. But this a) typically break SPF checks but b) even if SPF for that other domain has designated your Chasquid mail server as as a permitted sender Chasquid might decide to rewrite the sender if the domain is not listed, breaking SPF checks anyway. Perhaps I shouldn’t even have tried to attempt to send mails from someotheruser@otherdomain.com using mailer@maildomain.com, but an edge case to be aware of. I’ll probably implement a hook anyway to block sending from other domains anyway, and would hope that Chasquid would actually adopt that as a default.

Spam filtering is still slow

Of course this is outside of Chasquid’s control, but every time I was observing postfix’s mail.log I was thinking: why is mail delivery relatively slow? When following the logs you’d see the steps processed after an e-mail comes in sequentially appearing in the logs, consuming about 2 seconds in total. Perhaps someone should consider looking into the performance of spamd? I’m running a light weight server, and this load has never been an issue, but it doesn’t fail to suprise me.

Conclusion

The sell of Chasquid was ease of deployment (and configuration). The above notes seem to suggest it wasn’t, but I can see how Chasquid will relieve maintenance, and the lack of options to configure it make it easy not to make the obvious mistakes (creating an open relay). The only thing I’m a bit worried about is that Chasquid is made by a single person maintaining it, but seems Alberto Bertogli (a Googler) has the capacity to do so. The code is also readable, so perhaps if it must be done, changes can be made. It is nice that it can all be managed using apt. I am a big fan of simplicity.