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/
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
SNM supports DMARC reporting, but it's disabled by default. For email
greybeards, that's fine, but I think it would be useful to teach email newbies (as I was a few
months ago) that this is something you should seriously consider
enabling.
I opted to put this in a new "Advanced Configurations" section that
points experienced mailserver admins to our howto guides, and newbies to
a couple of important things.
refs: https://github.com/NixOS/infra/pull/635
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.
I recently went through this, and the generated file looks a bit
different than was previously documented.
I opted to be explicit about `k=rsa` (even though [the default is
"rsa"](https://datatracker.ietf.org/doc/html/rfc6376#section-3.6.1)).
I also opted to be explicit about `s=email` ([the default is
"*"](https://datatracker.ietf.org/doc/html/rfc6376#section-3.6.1)).
Honestly not sure what the consequences of this are, I don't know if
DKIM is used for anything besides email.
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.