Much more foolproof in simple setups, because it allows all servers
mentioned in a domains MX record to also send out mail, without having to
track them here manually again.
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.
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
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.
Add a certificate scheme for using an existing ACME certificate without
setting up Nginx.
Also use names instead of magic numbers for certificate schemes.
Martin Weinelt
Martin Weinelt
Jeremy Fleischman
Antoine Eiche
Naïm Favier
Nigel Bray
Linus Heckemann
Luflosi
Stefan Ladwig
Henri Menke
Niklas Hambüchen