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.
- add many motivation, helpful comments and important details
- improve formatting through use of more native sphinx/rst elements, like
the csv-table for DNS records
- clarify the basic requirements
- use dig for uncached DNS propagation checks against an authoritative
nameserver
- explain the basic feature set of the setup example
- adjust DNS TTLs; 1h is a common duration in modern setups and does not
hurt caching much
- remove mention of the announce mailinglist, users can just expect
releases to be ready around branch-off
Radicale and Roundcube don't fit so well with the other how to's in
that they configure additional external services instead of directly
modifying the NixOS mailserver setup.
We also sort the How-To section alphabetically. his unclutters the nav
somewhat
Adds a short explanation what roundcube even is.
Extract and extend the roundcube example showing plugin and spellchecking
support. We also inherit a plausible maximum attachment size based on
Postfix's message_size_limit. The nginx vhost forces TLS and manages
certificates using the ACME integration.
We now explain what Radicale even is and classify reusing the hashed
passwords of login accounts as limitation because it requires using
compatible password hashes.
This is difficult because compatible password hashes need an overlap
between libxcrypt and Radicales choice of libraries: libpass, argon2 and
bcrypt.
Extract the source code into a proper .nix file so we get source linting
and formatting for free. Pruned from bad practices of the past, like
global `with lib`.
Stop explicitly restriciting us to email services. This would require
an update for tlsrpt (s=email:tlsrpt) use but the benefit of restricting
key use like that has limited practical benefit, when there are so very\
few services defined.
Not setting the service type key defaults it to all services (s=*).
Much more foolproof in simple setups, because it allows all servers
mentioned in a domains MX record to also send out mail, without having to
track them here manually again.
By passing no method to mkpasswd we make it select the strongest cipher
that libxcrypt recommends.
Replaces the example hashes with yescrypt hashes, which is the current
default.
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>
instead of explicit TLS (STARTTLS).
We disabled STARTTLS for IMAP by default in 54f37811dd
and we will likely do the same for (client) SMTP in the future.
This migrates the key exchange curve group configuration into the OpenSSL
configuration format, which is the only path forward to configure these.
We now prefer a hybrid key exchange for TLS handshake and as a client
we'll send key shares for that and pure X25519, while keeping backwards-
compat for P256 and P384.
The statistics for my personal mail server over the last month show a
clear trend for X25519 key exchanges:
156 secp384r1
225 secp256r1
19541 x25519
When enabled the tlsrpt services will send out aggregated reports about
TLS connections the local Postfix made to interested parties, who set up
a `_smtp._tls` TXT record with a rua attribute.
Introduces mailserver.systemContact to specify an administrative contact
advertised in these automated reports.
Postfix with plain DANE only secures domains that configure DNSSEC and
publish TLSA records. With postfix-tlspol we support MTA-STS protected
connections and get caching for its policy results.
Finally, we use this as a stepping stone to build TLSRPT support on top.
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>
Eval does not stop on the first assertion failure it encouters.
Instead, it tries to evaluate all assertions and returns with a list of
those that failed.
This means our very top `config.mailserver.stateVersion != null`
assertion does not gate against any other assertions trying to compare
null against an integer.
The error prior to this commit can be reproduced by removing
`mailserver.stateVersion = 999;` in tests/lib/config.nix and then trying
to evaluate any of the tests:
~~~bash
# nix eval --raw .#checks.x86_64-linux.internal-unstable
error:
… while evaluating the attribute 'outPath'
at /nix/store/syvnmj3hhckkbncm94kfkbl76qsdqqj3-source/lib/customisation.nix:421:7:
420| drv.drvPath;
421| outPath =
| ^
422| assert condition;
… while calling the 'getAttr' builtin
at «internal»:1:500:
(stack trace truncated; use '--show-trace' to show the full trace)
error: cannot compare null with an integer
~~~
Per the dovecot documentation[0] we were previously running with an
unsupported home directory configuration, because we shared them among
all virtual users at /var/vmail.
After resolving this by creating per user home directories at
/var/vmail/%{domain}/%{user} this now also overlaps with the location of
the Maildir, which is not recommended.
As a result we now need to migrate our Maildirs into
/var/vmail/%{domain}/%{user}/mail, for which a small shell script is
provided as part of this change.
The script is included in the documentation because we cannot provide it
in time for users, because they might already be seeing the relevant
assertion and there is no safe waiting period that would allow us to skip
shipping it like that.
[0] https://doc.dovecot.org/2.3/configuration_manual/mail_location/
headpats
Lin Jian
Martin Weinelt
Martin Weinelt
yeoldegrove
emilylange
Guillaume Girol
Tom Herbers