Re: [exim] tls_tempfail_tryclear and "delivery in clear" on …

Inizio della pagina
Delete this message
Reply to this message
Autore: Viktor Dukhovni
Data:  
To: exim-users
Oggetto: Re: [exim] tls_tempfail_tryclear and "delivery in clear" on no-TLS-support only and not cipher/protocol failure
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.