Mox Mail Server

[corinthian13]

At first sight, this new integrated mail server seems like a great idea - especially to someone who wants to self-host but finds the usual solution of Postfix/Devecot/SpamAssasin/Roundcube to be very difficult to manage.

But the problem is that installing Mox as it is intended, i.e. with DNSSEC records set up optimally for spam rejection, is just too much work and far too much hassle.

DNSSEC is nominally implemented by my own VPS host (OVH) - yet I find no guide documentation on things like editing TLSA, MTA-STS, etc. Needless to say, the more esoteric records like NSEC3 and NSEC3PARAM are given no mention at all.

So, as I see it, if Mox authors want their new mail server adopted by enough people to enable its testing & debugging, I would advise spending some of the NLNet microfinance grant on a technical author to write the necessary procedures for installation and configuration.

I am sorry to have to say this but it is the simple truth. Just look at the "documentation" on the Unbound package . . . It's more like a list of hacks rather than a user's manual.

[RobSlgm]

I've been through the process of installing this myself, and it can be tricky.

While my tutorial is for a different hoster, it might provide some helpful insights. Check it out here: https://community.hetzner.com/tutorials/install-and-configure-mailserver-mox-on-debian

[corinthian13]

@RobSlgm

I think you anticipate more expertise in sys admin than most coders may have.

Our Cloud-init configuration installed "unbound" with a minimal configuration and with adaptions for Mox. Prior to enabling the DNSSEC/DANE setup for the mail server, ensure the functionality of the DNS resolver. There are several requirements to DNSSEC.

This is very much a circular answer in that it presumes proficiency in the very things that are causing the hold-ups preventing Mox installation.

Right now, trying to install and configure Unbound has left me with:

$ delv mysite.org
;; broken trust chain resolving 'mysite.org/A/IN': 127.0.0.53#53
;; resolution failed: broken trust chain

Maybe I need to revert to the Unbound GitHub issues pages before resuming my DNSSEC efforts. Given the lack of guidance documents on this, I may - to paraphrase Lawrence Oates - be outside for some time.

[RobSlgm]

The Unbound configuration given in my example is complete (if used with Debian).

It starts from the place where you bought the domain (Domain/DNS provider, e.g. Cloudfare). The next assumption behind this configuration is that you can manage all the DNS entries at this provider within their UI. The provider must allow you to enter TLSA records (I mention this as unfortunately not all provider do that…). The local Unbound is just a kind of glue to retrieve the DNS entries.

Are you trying to operate your own nameserver? In this much more complex setup you still need to setup at least a DS (delegation) record at your Domain provider. I have not yet found one provider who allows this outside the enterprise world.

[corinthian13]

The Unbound configuration given in my example is complete (if used with Debian).

Step 2.3 - DNSSEC The Unbound configuration given in my example is complete (if used with Debian). Our Cloud-init configuration installed "unbound" with a minimal configuration and with adaptions for Mox.

Your only reference to Unbound seems very scant to me.

This is what I can do on my ISP's control panel for DNS:

The how-to on TLSA records is missing from the user docs.

I'm not trying to operate my own nameservers - I use the hosts default nameservers. By domain provider do you mean the registry of all the .xyz domains ? Or just the ISP that handles the annual fees and associated tasks ? The latter is done by OVH in my case.

As it stands, the DNSSEC records provided by OVH for me include SOA, DS, DSK and ZSK keys.

[RobSlgm]

There are two distinct steps.

Server installation

Step 1 is ensuring that your VPS/server can make DNS queries with DNSSEC. This is unrelated to the fact whether your own domain has DNSSEC enabled. Step 1 is reached in my tutorial with the basic installation (cloud-init, by installation of dns-root-data, unbound-anchor and unbound and the configuration file at /etc/unbound/unbound.conf). The configuration works on Debian (not on Ubuntu). Check the result of this first step with devl xmox.nl, the result needs to contain a RRSIG record.

DNS setup

Step 2 is making sure that your own domain has DNSSEC enabled. Googling gave me following link at OVHcloud https://help.ovhcloud.com/csm/en-dns-secure-domain-dnssec?id=kb_article_view&sysparm_article=KB0051637 Make sure that you enable DNSSEC for your domain, which I understood was bought at OVH directly. Don’t go down the “Your domain name doesn’t use OVHCloud DNS Server” route.

As soon as DNSSEC is enabled you can perform the ./mox quickstart which gives you a list of DNS records. Now enter ALL these DNS records in the UI, which you properly identified in a previous post. This is described in https://help.ovhcloud.com/csm/en-ie-dns-zone-records?id=kb_article_view&sysparm_article=KB0063636 (are you referring to this page as user manual).

For the TLSA record the quickstart gives you something like

_25._tcp.mail.example.org. TLSA 3 1 1 99……………………………13e21131

I don’t have access to OVH, but I assume the screen will look similar to this screenshoot from Cloudfare DNS service:

Your local unbound is not involved in the second step at all.

[mjl-]

Thanks for reporting @corinthian13, and thanks for the answers @RobSlgm!

It's true that DNSSEC isn't the easiest aspect to get right in a mox setup. As Robert mentioned, there are two parts to DNSSEC:

1. DNSSEC-verifying resolving of DNS names on your server (mox needs to see the DNSSEC-results of a DNS lookup). Most linux systems don't come with a (properly functioning) DNSSEC-verifying resolver. Installing unbound takes care of this.
2. DNSSEC-signing the records of your own domain. So that anyone with a DNSSEC-verifying resolver that looks up your domain can detect forged DNS responses. If you're lucky, enabling DNSSEC for your domain is a matter of checking a checkbox in some UI. If you're unlucky, it's not supported by a DNS operator/registrar at all. I used to have my DNS hosted at AWS (Route 53). They support DNSSEC (though enabling it is tricky and feels designed to make you fail; I always need my notes to guide me through the process), but do not support TLSA records.

The mox quickstart is pointing you in the right direction for setting these things up, but it doesn't explain all steps in full detail. In part because the details are best described elsewhere (e.g. unbound documentation, or guides for each DNS registrar/operator/software). But also because the quickstart isn't interactive and I don't want to make the output too long. I still have plans to make an interactive step-by-step setup that guides you through the process, including asking you to install unbound, then checking it is working properly, and including checking dnssec for your domain (and again after you've made changes). But it's not at the top of the todo-list yet.

Some more comments:

But the problem is that installing Mox as it is intended, i.e. with DNSSEC records set up optimally for spam rejection, is just too much work and far too much hassle.

One correction: DNSSEC isn't needed for spam rejection. Spam analysis is done based on verifying sender addresses with DKIM/SPF and keeping tracking of reputation of verified senders. Having DNSSEC doesn't (currently) play a part.

DNSSEC is needed to protect MX records. It ensures email directed to a domain really makes it to the correct, verified mail servers for that domain. Without DNSSEC, a single forged DNS response to a lookup of MX records (during delivery) can cause email addressed to your domain to be misdirected to another server (and that other server may have TLS set up and look very secure and TLS verified, it's just that it may be someone else's mail server!). This indirection through MX records is not present for most other internet protocols (which typically just connect to a hostname from a user-visible URL and verify the connection has a TLS cert for that host name, i.e. they rely on WebPKI), that's why other protocols don't need DNSSEC as badly as email does.

DNSSEC is nominally implemented by my own VPS host (OVH) - yet I find no guide documentation on things like editing TLSA, MTA-STS, etc. Needless to say, the more esoteric records like NSEC3 and NSEC3PARAM are given no mention at all.

I think what we need is a good explanation of how all these concepts and techniques relate to each other. DANE requires a few TLSA records to be created (and DNSSEC enabled on the domain; mox shows the TLSA records to create and that's enough). MTA-STS needs a few DNS records and a simple policy file served over HTTPS (mox shows the DNS records to create and serves the MTA-STS policy file). NSEC* are DNSSEC concepts that chosen as part of DNSSEC setup (your DNS operator has probably made a decision on them). Then there is SPF, DKIM, DMARC, reporting (mox shows DNS records and creates keys). The quickstart does try to give a bit of context (which helps as a reminder if you already pretty much know how it works), but it's not enough to learn the concepts. You either need to know already, or start looking for more complete explanations. There are probably good resources on the internet about all these concepts. With a step-by-step guided setup in the future, we could give more explanation during the process. But it doesn't fit in the one-shot quickstart.

@RobSlgm

While my tutorial is for a different hoster, it might provide some helpful insights. Check it out here: https://community.hetzner.com/tutorials/install-and-configure-mailserver-mox-on-debian

That's nice, hadn't seen that yet (or I didn't remember). Tiny nit: the "import mailboxes" links to the export command docs.

$ delv mysite.org ;; broken trust chain resolving 'mysite.org/A/IN': 127.0.0.53#53 ;; resolution failed: broken trust chain

That IP 127.0.0.53 indicates the resolved used is not unbound, but probably systemd-resolved, which may have been disabled/uninstalled when unbound was installed. I've seen this more often, and I don't know why that's considered good default behaviour. It's also a good idea to check DNSSEC lookups with "dig". The "delv" command does its own DNSSEC-verification. But you want to check that unbound is doing DNSSEC verification, and "dig" shows the DNSSEC-result that unbound found. See issue #158 for details.

There has been a commit to the quickstart output (that isn't in a release yet) that would point future users in that direction, see https://github.com/mjl-/mox/commit/83004bb18e3cd2d525fee82ad9a754dde6c77a2f#diff-e7bc0318a31a2b51c6d7393f325e4555f474fb1d72a461f823507703fdd1a4d4

It's probably time for a FAQ entry about this, I'm making a note to add an entry.

[corinthian13]

@mjl-

Thanks for your response.

I well realize that DNSSEC is awkward to get running on a server and that it's more complex than simply switching on an Enable DNSSEC button on a host's control panel.

Problem 1 is this Unbound package and how its repos on apt can be missing config or key files. It's easy to be left with neither a running systemd-resolved service not a working Unbound resolver.

$ delv mysite.org
;; broken trust chain resolving 'mysite.org/A/IN': 127.0.0.53#53
;; resolution failed: broken trust chain

resulted from not enabling and restarting the systemd-resolved service after throwing out the misfiring Unbound.

One correction: DNSSEC isn't needed for spam rejection. Spam analysis is done based on verifying sender addresses with DKIM/SPF and keeping tracking of reputation of verified senders. Having DNSSEC doesn't (currently) play a part.

Well, DNSSEC protects against hijacked email and mail hijacking - which strictly speaking isn't spam, I admit. But if DNSSEC protects MX records, it can also offer protection to all other DNS records - including the SPF, DKIM and DMARC records that combat spam per se.

Quickstart need not explain SPF, DKIM or DMARC records to us as numerous tutorials exist on how to create and edit these. It is unlikely that anyone unfamiliar with these records would be trialling a new mail server like Mox. (But it's thoughtful of Mox to offer us a nice choice of DKIM keys !)

Look, I don't want to be overly critical of your initiative here. You've done a lot of unpaid private time work on this project. It's towards the goal of secure and manageable self-hosted email. Without the awkwardness of coordinating 4 separate packages like Postfix/Exam, Dovecot, SpamAssassin & Roundcube. And without the likely loss of privacy by using a pre-packaged & pre-configured version of the same agglomerate, e.g. iRedMail, DockerMail, MailCow, etc.

But proper user guidance documents (no dry definitions, please) have an important role to play in the testing and adoption by users of Mox - and, since Mox depends a lot on Unbound, we all need better user guides on the latter package too.

[RobSlgm]

It would be beneficial to know the Linux distro used as otherwise some guidance is misleading.

I took after trying other distro's, Debian for the mox installation. Why is this relevant?

Debian 12 is not using systemd-resolved.

Note that systemd-resolved was not, and still is not, the default DNS resolver in Debian. If you have not configured your machine to use systemd-resolved as the DNS resolver, no action is required. (Source https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#systemd-resolved)

It than just works with a basic installation of unbound.

I have no opinion on systemd-resolved, it was just the more reliable and repeatable way installing mox on Debian and avoiding the hassle.

[corinthian13]

I'm using Ubuntu 22.04 LTS.

But don't worry on providing guidance on Mox for Ubuntu.

My issue is principally with Unbound repos and seeing if my ISP allows DNS querying - something beyond Mox's scope.

I'll report back in due course if I progress this.

[DeltaLaboratory]

if Unbound is challenging to use, using a DNS resolver that supports DNSSEC, such as Cloudflare DNS or Quad9, would be enough for most situations.

[corinthian13]

If Unbound is challenging to use, . . .

It's actually a problem of getting an Unbound version installed that contains an unbound.conf file !

The discussion with NLNet's Overeinder didn't go well as he refuses to accept that Unbound 1.13.1 lacks any files . . . The fault, he thinks, must lie elsewhere - either with apt, the user's Ubuntu installation, the user themselves, etc.

There is talk that Ubuntu 24.04 LTS will include Unbound 1.19 - I am not sure if it is to be the default resolver or not - we will soon see !

I will look into your alternatives. Issues detected by Mox quick-start program (PTR, TLSA) have been largely sorted out so once a resolver is available, it should work, inshallah.

[corinthian13]

I have quad9 (9.9.9.9) as my remote resolver. I have a TLSA record on my domain name. Still I get issues:

/home/mox# ./mox quickstart sandsoft@sandbarsoftware.ie
Checking if DNS resolvers are DNSSEC-verifying...

WARNING: It looks like the DNS resolvers configured on your system do not
verify DNSSEC, or aren't trusted (by having loopback IPs or through "options
trust-ad" in /etc/resolv.conf).  Without DNSSEC, outbound delivery with SMTP
used unprotected MX records, and SMTP STARTTLS connections cannot verify the TLS
certificate with DANE (based on a public key in DNS), and will fall back to
either MTA-STS for verification, or use "opportunistic TLS" with no certificate
verification.

Recommended action: Install unbound, a DNSSEC-verifying recursive DNS resolver,
ensure it has DNSSEC root keys (see unbound-anchor), and enable support for
"extended dns errors" (EDE, available since unbound v1.16.0). Test with
"dig com. ns" and look for "ad" (authentic data) in response "flags".

cat <<EOF >/etc/unbound/unbound.conf.d/ede.conf
server:
    ede: yes
    val-log-level: 2
EOF

Looking up IPs for hostname mail.sandbarsoftware.ie...

NOTE: It looks like the DNS records of your domain (zone) are not DNSSEC-signed.
Mail servers that send email to your domain, or receive email from your domain,
cannot verify that the MX/SPF/DKIM/DMARC/MTA-STS records they receive are
authentic. DANE, for authenticated delivery without relying on a pool of
certificate authorities, requires DNSSEC, so will not be configured at this
time.
Recommended action: Continue now, but consider enabling DNSSEC for your domain
later at your DNS operator, and adding DANE records for protecting incoming
messages over SMTP.

Checking if outgoing smtp connections can be made by connecting to gmail.com mx on port 25... OK
Checking whether host name IPs are listed in popular DNS block lists...
WARNING: checking your public IP 51.75.246.218 in DNS block list sbl.spamhaus.org: fail Error: open resolver; https://check.spamhaus.org/returnc/pub/66.185.123.249/
Other mail servers are likely to reject email from IPs that are in a blocklist.
If all your IPs are in block lists, you will encounter problems delivering
email. Your IP may be in block lists only temporarily. To see if your IPs are
listed in more DNS block lists, visit:

- https://multirbl.valli.org/lookup/51.75.246.218.html

creating file "config/adminpasswd": open config/adminpasswd: file exists
root@mail:/home/mox# 

[mjl-]

@corinthian13 What is in your /etc/resolv.conf? If you're using a non-local resolver (IP), the "ad"-flag isn't trusted. You would need a line with "options edns0 trust-ad" in /etc/resolv.conf.

As for the error about config/adminpasswd: You already ran the quickstart in that directory. Mox is careful not to overwrite previous files (consider what happens if you accidentially ran "mox quickstart" in the directory with your existing mox install). While you're still setting up, you can just remove the previously generated files before running the quickstart again. But this is another reason why having an interactive setup will be helpful.

[mjl-]

Another note (also mentioned in other issues about DNS-related problems, and in the already committed diff referenced above): You can check the actual DNSSEC status as mox sees it with "mox dns lookup ...", for example:

$ mox dns lookup mx ueber.net
mx records (1, with dnssec):
- mail.axillis.nl., preference 10

[corinthian13]

What is in your /etc/resolv.conf? If you're using a non-local resolver (IP), the "ad"-flag isn't trusted. You would need a line with "options edns0 trust-ad" in /etc/resolv.conf.

GNU nano 6.2                                 resolv.conf                                          
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.
nameserver 9.9.9.9
nameserver 149.112.112.112
nameserver 127.0.0.53
search openstacklocal

Another note (also mentioned in other issues about DNS-related problems, and in the already committed diff referenced above): You can check the actual DNSSEC status as mox sees it with "mox dns lookup ...",

/home/mox# sudo mox dns lookup mx sandbarsoftware.ie
sudo: mox: command not found

[mjl-]

That /etc/resolv.conf shows you're using 3 nameservers. This doesn't look intentional... It also explains why the AD flag isn't used: There is no trust-ad option. But I wouldn't recommend adding option trust-ad for DNS requests over the public internet (the ad bit isn't protected in transit).

That "mox dns lookup" error should be easy to fix. Give it a try, you can do it. You don't even have to run it as root.

[corinthian13]

That "mox dns lookup" error should be easy to fix. Give it a try, you can do it. You don't even have to run it as root.

It's clear that you are in the wrong directory or using the wrong title for the command.

I'll let you unravel the puzzles in getting after the folder holding commands in Mox.