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>
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.
