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.
This helps so much during development as it tells me openldap failed and
doesn't require me to do a root cause analysis on a postmap failure much
later in during the test.
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.
- 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=*).
Martin Weinelt
Martin Weinelt
lennart
headpats
Lin Jian