The "login" prefix makes this option more confusing rather than clearer,
because what other account types are there? LDAP ones for example, but
you can login with those too, so the prefix is pointless.
In conflicts between local addresses and LDAP addresses the local one
will always take priority in mail routing.
This is something we now document and guarantee through tests.
I fail to understand how mail became the uidAttribute way back when LDAP
support was introduced, but it was unintentional and clearly a mistake.
The uid attribute is the standard system login name per RFC4519 2.39 and
what we default to going forward.
Now that we have more experience with how we use the LDAP module options
we can make smarter decisions in how to organize them. We can also
explain much better what these options imply, which results in more
extensive option documentation.
The only storage scheme we support is a single declarative user with
fixed uid/gid. The default_fields are overridable if these fields leak
in from LDAP, so promote them to override_fields instead.
The LDAP support was not in a good shape when it was merged. This is a
breaking change and course correction to apply best practices going
forward.
This fixes various issues experienced with the Dovecot LDAP home
directory.
The gravest issue is that the `homeDirectory` attribute from
the `posixAccount` schema would overwrite the Dovecot home directory and
cause permission errors. This was possible because we defined the home
variable in `default_fields` that is inherently mutable and just a preset
if no other value gets transmitted from LDAP. This did not surface in
tests, because our LDAP schema was too minimal compared to a common
production dataset.
The most annoying issue and the actual breaking change is that we now
default to UUID based home directories. Every entry in an IDM that
supports LDAP comes with a unique identifier that does not change upon
account name changes. We want those to enable simple account name
migrations that don't require any manual data migration.
To migrate existing dovecot home directories a migration script is
included, which will be backported to the 25.11 release, so the migration
can already be started from the previous release version.
In TLS1.2 available cipher suites depend on the available key material,
so the last round of cipher suites updates broke TLS1.2 support with RSA
key pairs.
The NixOS ACME module has been defaulting to EC256 (and earlier EC384)
key material, so I assume this did not affect many setups in practice.
With the growing number of option refactors centralize the module import
within the mail-server directory.
Also group deprecations by release, so we can eventually yank them in
bulk after a while.
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.
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>
In nixpkgs we expose `services.dovecot.hasNewUnitName` option that can be
safely inspected to understand that whether to use the `dovecot` systemd
service name instead of `dovecot2`.
Martin Weinelt
lennart
Ryan Gibb
teutat3s
Martin Weinelt
Antoine Eiche
Giel van Schijndel