This solves an issue where an attacker would strip the STARTTLS keyword
from the EHLO response, thereby preventing connection upgrade; or spoof
DNS responses to route outgoing messages to an attacker-controlled
SMTPd, thereby allowing message MiTM'ing.  With key material pinning in
place, smtp(8postfix) immediately aborts the connection (before the MAIL
command) and places the message into the deferred queue instead:

    postfix-out/smtp[NNN]: … dsn=4.7.5, status=undeliverable (Server certificate not verified)

This applies to the smarthost as well as for verification probes on the
Mail Submission Agent.  Placing message into the deferred queue might
yield denial of service, but we argue that it's better than a privacy
leak.

This only covers *internal messages* (from Fripost to Fripost) though:
only messages with ‘fripost.org’ (or a subdomain of such) as recipient
domain.  Other domains, even those using mx[12].fripost.org as MX, are
not covered.  A scalable solution for arbitrary domains would involve
either DANE and TLSA records, or MTA-STS [RFC8461].  Regardless, there
is some merit in hardcoding our internal policy (when the client and
server are both under our control) in the configuration.  It for
instance enables us to harden TLS ciphers and protocols, and makes the
verification logic independent of DNS.

And drop -ldap from all roles other than MX.  -lmdb is included in
roles/common but it can be helpful to have it individual roles as well
as they can be run individually.

Use admin@fripost.org instead.  We were sending out (to the admin team)
system messages with non-existing or invalid envelope sender addresses,
such as <logcheck@antilop.fripost.org> or <root@mistral.fripost.org>.

Interhost communications are protected by stunnel4.  The graphs are only
visible on the master itself, and content is generated by Fast CGI.

First generate all certs (-t genkey), then build the TLS policy maps (
-t tls_policy).

(Unless a new instance is created, or the master.cf change is modified.)
Changing some variables, such as inet_protocols, require a full restart,
but most of the time it's overkill.

And don't restart or reload either upon change of pcre: files that are
used by smtpd(8), cleanup(8) or local(8), following the suggestion from
http://www.postfix.org/DATABASE_README.html#detect .