> On Dec 19, 2018, at 3:34 PM, Wietse Venema <wie...@porcupine.org> wrote:
>
>> If there are no objections, I can change the default to "may" when
>> TLS is compiled in.
>
> Unrelated but related, what should happen when someone unwittingly
> builds Postfix without TLS support, and Postfix configuration a)
> enables opportunistic TLS or b) Postfix configuration requires TLS?
Perhaps we should honour the configured (main.cf or per-destination)
security level, and thus, with TLS support not compiled in:
* A main.cf security level > "none" generates a warning at process
start.
* Deliveries to a destination with a security level > may, fail.
* Deliveries to a destination with security level == may, proceed
with no TLS.
Consequently, we would need to engage the TLS policy lookup mechanism,
far enough to determine the per-destination security level (whether
from main.cf or the policy table), but not so far as to look for
DANE TLSA records, as their processing requires some TLS support.
Thus, e.g. "dane" in the absence of "TLS" support may be a static
failure, rather than opportunistic based on TLSA RRs.
> Will b) result in mail being sent as plaintext?
If so, "b" would defer, but "a" would deliver in cleartext.
> Should the build system be updated to use -DUSE_TLS by default and
> to explicitly require -DNO_TLS if people want to build without TLS?
This is also an option, but probably not important, since O/S
packages generally enable TLS. The "USE_TLS" requirement is
only a barrier for the handful of users who build from source.
Perhaps a few more would make an extra effort to specify the
set of OpenSSL header files and libraries.
--
Viktor.
