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.
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>
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.
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`.
I'm working on deprecating the top-level options, that configure main.cf
upstream in nixpkgs. With this change we stay ahead of the curve.
The `networks_style` option already defaults to `host` since Postfix 3.0,
so I dropped the setting.
```
$ postconf -d | grep networks_style
mynetworks_style = ${{$compatibility_level} <level {2} ? {subnet} : {host}}
````
- Groups settings between server and client
- Uses a range comparator for supported TLS versions
- Prune excluded primitives to what affects the supported TLS versions
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.
The sslCert and sslKey options are going away, because they do too much,
e.g. provision the keypair for client certificate authentication, which
is not at all what we want or need.
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
Allow configuring lookups for users and their mail addresses from an
LDAP directory. The LDAP username will be used as an accountname as
opposed to the email address used as the `loginName` for declarative
accounts. Mailbox for LDAP users will be stored below
`/var/vmail/ldap/<account>`.
Configuring domains is out of scope, since domains require further
configuration within the NixOS mailserver construct to set up all
related services accordingly.
Aliases can already be configured using `mailserver.forwards` but could
be supported using LDAP at a later point.
Martin Weinelt
lennart
Martin Weinelt
lewo
Robert Schütz
Sandro Jäckel
Philipp Bartsch
Isabel
Alvar Penning
Jean-Baptiste Giraudeau
Steve Purcell