On Mon, Oct 12, 2015 at 01:19:07PM +0200, Felix Engel wrote:
> Hi,
>
> coming from postfix, it is (to me) impossible to setup
> a mechanism which will attempt a "delivery in clear",
> ONLY if there is truly no TLS support present and not
> when cipher/protocol is simply failing/missing.
>
> How can it be done?
I am not aware of any current support for that in Postfix either.
Perhaps you're not explaining yourself very clearly.
In Postfix, when TLS is opportunistic (TLS security level is "may"),
cleartext will be tried when either the handshake or data tranmission
fails via TLS. In recent enough versions of Postfix, this normally
won't happen on the first delivery attempt, the message age in the
queue has to exceed the "backoff time" before fallback to cleartext
is enabled.
The TLS levels are:
none - TLS disabled
may - Opportunistic TLS + cleartext fallback on handshake or
transmission error
encrypt - Mandatory TLS with no authentication
dane - Opportunistic DANE TLS, which authenticates when destination
uses DNSSEC and publishes DANE TLSA records
dane-only - Mandatory DANE TLS, which requires the destination to use
DNSSEC and publish TLSA records, which are then used for
authentication.
fingerprint - Authenticate destination via certificate or public
key fingerprint
verify - Backwards compatible version of "secure" that by default
trusts MX hostnames obtained via DNS for verification.
secure - Mandatory TLS with authentication via trusted CAs. Unlike
verify, the default peername matching policy uses the destination
domain name, not the MX hostname.
Nowhere in the above list is there a mode that avoids cleartext
fallback when "STARTTLS" is offered, but the handshake or data
transmission fails. We've been thinking about adding parameters
that tweak "may" in that way, but no code has been written.
--
Viktor.
