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.
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 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.
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.
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>
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.
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
```
It has been default enabled since Postfix 3.9 and can still be configured
from the NixOS option mentioned in the removal warning.
Removing the option makes our interface leaner.
Information is based on https://www.postfix.org/smtp-smuggling.html#long.
With upcoming changes to the dovecot home and maildirectories we need to
introduce a way to nudge users to inform themselves about manual
migration steps they might need to carry out.
The idea here is to allow us to safely make breaking changes and notify
the user of required migration steps at eval time, so they can make the
necessary changes in time.
This switches the full-text search plugin from fts-xapian to
fts-flatcurve, the now preferred indexer still powered by Xapian,
which will be integrated into Dovecot core 2.4.
This sets a sane minimal configuration for the plugin with
international language support.
The plugin options marked as "advanced" in Dovecot's documentation
aren't re-exposed for simplicity. They can nevertheless be overridden
by module consumers by directly setting keys with
`services.dovecot2.pluginSettings.fts_*`.
The `fullTextSearch.maintenance` option is removed as the index is now
incrementally optimised in the background.
GitLab: closes https://gitlab.com/simple-nixos-mailserver/nixos-mailserver/-/issues/239
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
This is not a feature specific to the mailserver. Indeed, the feature
was added to `system.autoUpgrade.allowReboot` with NixOS 19.09 and it
has better detection if a reboot is necessary.
For the system.autoUpgrade there is no kexec option, but the use was
discouraged.
Since NixOS 19.09 autoUpgrade also has the ability to do automatic
reboots. Its detection on whether a reboot is necessary is a bit more
sophisticated. Having this option in the mail-server implied to me that
it did something additionally, though it was just a feature which was
not included in NixOS at the time it was introduced for the mail-server.
Mentioning the fact in the documentation might help people not to get
confused why they should turn the `system.autoUpgrade.allowReboot` off
and instead use the mail-servers reboot flag.
fts xapian does not publish configuration changes in a changelog. As a
result, some options that nixos mailserver was setting for it have been
ignored for several years. New options (process_limit) are now
recommended. This adapts the module to these changes.
The default value of partial= is 2, but fts_xapian 1.8.3 now requires it
to be at least 3, and fails loudly in case it is 2. As a result, this
change is required to support fts_xapian 1.8.3 and later.