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/
We have other tests that are minimal, e.g. the multiple test. And this
test wasn't even hooked up in flake.nix, so I'm doubtful that we really
need it.
These will never suceed while running the tests in the Nix sandbox, and
skipping them leads to very noticable (~51%) speedups.
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 ± σ): 74.010 s ± 0.746 s [User: 0.269 s, System: 0.266 s]
Range (min … max): 72.814 s … 75.190 s 10 runs
```
Provides a small (~7.5%) reduction in the test runtime measured for the external
test:
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 ± σ): 140.647 s ± 1.092 s [User: 0.331 s, System: 0.296 s]
Range (min … max): 138.536 s … 142.298 s 10 runs
```
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
```
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.
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.
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
All ciphers in TLSv1.2/TLSv1.3 are considered secure, so we can allow the
client to choose the most performant cipher according to their hardware
and software configuration.
This is in line with general recommendations, e.g. by Mozilla[1].
[1] https://wiki.mozilla.org/Security/Server_Side_TLS
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.
Sets up a declaratively configured OpenLDAP instance with users alice
and bob. They each own one email address,
First we test that postfix can communicate with LDAP and do the expected
lookups using the defined maps.
Then we use doveadm to make sure it can look up the two accounts.
Next we check the binding between account and mail address, by logging
in as alice and trying to send from bob@example.com, which alice is not
allowed to do. We expect postfix to reject the sender address here.
Finally we check mail delivery between alice and bob. Alice tries to
send a mail from alice@example.com to bob@example.com and bob then
checks whether it arrived in their mailbox.
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
