On 13/10/15 16:07, Viktor Dukhovni wrote:
> 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.
>
(off-list)
Viktor, please stop using the exim-users mailing list for advocacy.
--
Jeremy
