Previously, only postfix-relaymap.cf and postfix-accounts.cf would be
used to populate the relayhost_map file.
Now, also use postfix-virtual.cf when present. To me, there is nothing
absurd about sending mail "From:" a virtual account (or more
specifically its domain) so it makes sense that when a $RELAY_HOST is
defined it should be used for virtual accounts as well.
check-for-changes.sh did not have a special case to handle lines in
postfix-relaymap.cf consisting of only a domain (indicating that said
domain should never be relayed). This case is handled by
start-mailserver.sh so when such a line existed, things would work well
until a config file update was detected by check-for-changes.sh. After
that, the generated relayhost_map file would be corrupted.
Fixed by factoring a 'populate_relayhost_map' function out of
start-mailserver.sh and into helper_functions.sh and reusing it in
check-for-changes.sh.
Note: There are certainly quite a few more pieces of code that could be
refactored in a similar fashion.
Note2: check-for-changes.sh would previously never update the
relayhost_map file when $ENABLE_LDAP was set to 1. I don't think this
was intended —there is after all no such condition in
start-mailserver.sh— and so this condition no longer applies.
If a change to one of the tracked files happened soon after (<1 second?)
a previously detected change, it could end up going undetected. In
particular, this could cause integration tests to fail (see next
commits).
Fixed by computing the new checksum file _before_ checking for changes.
Will extract certificates from acme.json as written by traefik for usage in dovecot and postfix.
Also watches acme.json for changes. For this to work the file has to be mounted/present at `/etc/letsencrypt/acme.json`
To prevent announcing software or version to malicious people or scripts, it is advised to hide such information.
This information is provided as part of the Lynis community project. It is related to Lynis control MAIL-8818 and should be considered as-is and without guarantees.
https://cisofy.com/lynis/controls/MAIL-8818/
[Postfix docs](http://www.postfix.org/postconf.5.html#tls_ssl_options):
> Disable SSL compression even if supported by the OpenSSL library. Compression is CPU-intensive, and compression before encryption does not always improve security.
[Postfix mailing list discussion](http://postfix.1071664.n5.nabble.com/patch-mitigate-CRIME-attack-td57978.html):
> The CRIME attack does not apply to SMTP, because unlike SMTP, there is no javascript in SMTP clients that makes them send thousands of email messages with chosen plaintext compressed together in the same packet with SASL credentials or other sensitive data.
> The auditor completely failed to take the context into account.
[Mailing list discussion of potential compression CRIME-like attack](https://lists.cert.at/pipermail/ach/2014-December/001660.html)
> keeping compression disabled is a good idea.
If you need a good test score, PCI compliance will likely flag compression despite not having any known risk with non-HTTP TLS.
