After bumping the generation of new DKIM keys to RSA 2048 in NixOS 25.11
key rotation for existing users could not be done safely.
To resolve this situation we now support multiple generations of
selectors per domain to enable proper DKIM key transitions as described
in RFC6376 3.1. The added documentation introduces and motivates DKIM
and guides the user through a DKIM key rotation.
Additionally, DKIM key material can now also be treated as a managed
secrets when autogenerated state on the mail server host is undesirable.
This change is fully backwards compatible in behavior and will continue
to use the previously generated DKIM key without any additional
configuration up until the point when DKIM selectors are configured
explicitly.
Drop most of the existing certificate handling, because we're effectively
duplicating functionality that NixOS offers for free with better
design, testing and maintainance than what we could provide downstream.
The remaining two options are to reference an
existing `security.acme.certs` configuration through
`mailserver.x509.useACMEHost` or to provide existing key material via
`mailserver.x509.certificateFile` and `mailserver.x509.privateKeyFile`.
Support for automatic creation of self-signed certificates has been
removed, because it is undesirable in public mail setups.
The updated setup guide now displays the recommended configuration that
relies on the NixOS ACME module, but requires further customization to
select a suitable challenge.
Co-Authored-By: Emily <git@emilylange.de>
With the eSLD normalization feature in rspamd subdomains actually use the
DKIM key for their parent domain, which simplifies the setup if you serve
multiple subdomains.
We however currently create DKIM key pairs for every given domain
name, no matter if it is a second-level domain or subdomain for one, so
disabling eSLD normalization aligns with the current intent behind our
configuration.
In the future it would be nice if we could reuse the parent domain DKIM
key for all its subdomains, but that requires some thought on how to
achieve that normalization in nixos-mailserver first.
Reapplies 1a3a618a30 to the correct
configuration file.
With the eSLD normalization feature in rspamd subdomains actually use the
DKIM key for their parent domain, which simplifies the setup if you serve
multiple subdomains.
We however currently create DKIM key pairs for every given domain
name, no matter if it is a second-level domain or subdomain for one, so
disabling eSLD normalization aligns with the current intent behind our
configuration.
In the future it would be nice if we could reuse the parent domain DKIM
key for all its subdomains, but that requires some thought on how to
achieve that normalization in nixos-mailserver first.
Bring them up from the DMARC reporting section to the mailserver toplevel
so they become reusable for the upcoming TLSRPT integration.
We default to the first domain in the domains option, if not set
explicitly, so that `systemDomain` doesn't become a blocker for existing
setups. We still encourage picking out the intended one, which is likely
the one used for the MX hostname.
This also simplifies the DMARC reporting configuration, which doesn't
need to be so fine-grained.
Co-Authored-By: Emily <git@emilylange.de>
Enabling the rspamd debug log drowns out everything else and should be
selected explicitly as needed.
The external test does not require it and removing it makes it much
(~40.5%) faster, since it now does not block on terminal output anymore.
Before:
```
Benchmark 1: nix build .#hydraJobs.x86_64-linux.external-unstable --rebuild
Time (mean ± σ): 151.737 s ± 1.074 s [User: 0.310 s, System: 0.289 s]
Range (min … max): 150.321 s … 153.512 s 10 runs
```
After:
```
Benchmark 1: nix build .#hydraJobs.x86_64-linux.external-unstable --rebuild
Time (mean ± σ): 90.531 s ± 0.557 s [User: 0.054 s, System: 0.045 s]
Range (min … max): 89.579 s … 91.278 s 10 runs
```
OpenDKIM has not been updated in the last 7 years and failed to adopt
RFC8463, which introduces Ed25519-SHA256 signatures.
It has thereby held back the DKIM ecosystem, which relies on the DNS
system to publish its public keys. The DNS system in turn does not handle
large record sizes well (see RFC8301), which is why Ed25519 public keys
would be preferable, but I'm not sure the ecosystem has caught up, so we
stay on the conservative side with RSA for now.
Fixes: #203#210#279
Obsoletes: !162!338
Supersedes: !246
Both rspamd and redis run on the same host by default, so a UNIX domain
socket is the cheapest way to facilitate that communication.
It also allows us to get rid of overly complicated IP adddress parsing
logic, that we can shift onto the user if they need it.
The option `exclude_domains` for dmarc reporting in `rspamd`[1] allows
to configure a list of domains and/or eSLDs (external effective second level
domain) to be excluded from dmarc reports.
Helpful because e.g. dmarc reports to hotmail.com always fail for me
with the following undeliverable notification:
The recipient's mailbox is full and can't accept messages now.
[1] https://www.rspamd.com/doc/modules/dmarc.html
Since we are now using services.redis.servers.rspamd, the port defaults
to 0 (i.e. do not bind a TCP socket). We still want rspamd to connect to
redis via TCP, so set a default port that is one above the default redis port.
The sqlite backed is deprecated, and the redis backend is the default
since rspamd 2.0.
Not having redis started results in such errors:
rspamd_redis_init: cannot init redis backend for BAYES_SPAM
To migrate the sqlite database, run
rspamadm statconvert --spam-db /var/lib/rspamd/bayes.spam.sqlite --ham-db /var/lib/rspamd/bayes.ham.sqlite -h 127.0.0.1:6379 --symbol-ham BAYES_HAM --symbol-spam BAYES_SPAM
The current module implements the recommended configuration that this
utility prints out.
- restructure rspamd config. It's nicer now, and it was getting
overridden the old way.
- "scan_mime_parts = false" apparently must be used in rspamd for ClamAV
to work
- refactor the clamav test a bit for cleanliness
- wait for rspamd and clamd sockets to open, before testing
- use clamdscan for speed, and verify that the virus was found
- verify msmtp returns virus scan result