On Thu, May 27, 2021 at 05:42:34PM +0100, Matthew Richardson wrote:
> >I'm afraid that's not currently possible. You can mandate DANE via a
> >setting of "dane-only" or opportunistically use DANE via "dane", which
> >in the absence of TLSA records defaults to opportunistic TLS, which may
> >in turn send in the clear when TLSA records are determined to be absent.
>
> Just to clarify, will a selection of "encrypt" disable any DANE checking?
Yes, naturally. Only one policy at a time can be expressed. There is
no "dane else encrypt" policy.
> >That's right, we'd need a new dane-or-encrypt level, or a more complex
> >policy specification syntax which supports "fallback" levels when a
> >non-deterministic level such as DANE does not find its pre-requisites to
> >be available.
>
> Where does one go to make a formal feature request for this please?
There are no "formal" feature requests for Postfix. Informal feature
requests are discussed on this list or postfix-devel.
> smtp_tls_security_level = dane
> smtp_tls_note_starttls_offer = yes
You typically don't need the second of these, it is only needed when
your policy is "none" (possibly for a particular set of domains via the
policy table).
> and I am wanting to enhance this for certain specific domains to
> require mandatory encryption, without neutering DANE if present.
> Thus, the suggestion of an additional "dane-or-encrypt" level seems
> like a very good idea!
Presumably, in practice you'd use that only for specific destinations
via the policy table, rather than globally.
The barrier to progress is deciding whether a point solution such as
a new level like "dane-or-encrypt" is good enough, or whether the right
way forward is a more general syntax for specifying what happends when
a dynamic level like dane finds its preconditions missing.
A more complete set of options might be:
* "dane", or else "encrypt"
* "dane", or else "secure" (equivalently "verify" with explicit
"match" patterns).
* "dane", or else "mta-sts" (built-in "mta-sts" is not presently
supported or even planned, but perhaps some day...)
* "dane", with an "on fail" override to deliver anyway, but the
possible MiTM is logged and is "tamper-evident". (This
should/would be discouraged, except as a limited-duration
work-around).
* "mta-sts", or ... (again if some day implemented)
which requires some design.
If a "dane-or-encrypt" feature is implemented it would have to be
supported for a long time, and would need to have a clean mapping onto
the long-term approach, allowing its implementation to be subsumed by
any later more general solution. So some care is required in deciding
the path forward.
--
Viktor.
