I think that the mistake was to make smtp_tls_dane_insecure_mx_policy
dependent on smtp_tls_security_level
Will it please Viktor and Omer if I change the default to
smtp_tls_dane_insecure_mx_policy = dane
That seems to have less of a WTF factor.
Here is my motivation to make make dane policy evaluation NOT
dependent on smtp_tls_security_level.
In today's world it seems natural, to me at least, to set
smtp_tls_security_level to 'may' as a default baseline for all
deliveries, and then use policy lookup for sites that are ready for
stronger security.
For this reason alone, smtp_tls_security_level is not a good
way to express how to handle a DANE half-edge case.
Asking people to configure different transports for this case,
kind of defeats the purpose of having smtp_tls_policy_maps.
Thus, I propose to decouple smtp_tls_dane_insecure_mx_policy
from smtp_tls_security_level
Starting with today's baseline level of 'may', Over time one can
evolve the baseline to 'encrypt', and eventually use 'secure' as
the baseline, and (NOTE: role switch!) use samtp_tls_policy_maps
for sites that need weaker security.
So there is my longer-term perspective: today, use policy maps to
harden security for specific sites. In the future, use use policy
maps to weaken security for specific sites.
Decoupling smtp_tls_dane_insecure_mx_policy from smtp_tls_security_level
will delay the Postfix 3.10.0 stable release by another day, but it
would be worth it.
Wietse
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
