On Wed, Jan 14, 2015 at 07:33:17PM -0500, Wietse Venema wrote:
> This proof-of-concept version minimizes scar tissue, by patching
> into the existing code path. Things that I might want to change:
>
> - Move the new smtp_start_tls() call + flags twiddling ito a new
> function smtp_smtps() that is at the same level as smtp_helo().
Yes.
> - Add an smtp_tls_wrapper_mode parameter, instead of the hard-coded
> port 465 heuristic.
Yes.
> The main take-away from this exercise is that SMTPS support does
> not require any invasive changes to existing code.
Correct.
> Also, there is no need for smtp_tls_security_level=encrypt since the
> client will not send plaintext anyway. Any smtp_tls_security_level
> that is not "none" will suffice.
Not quite sure what the TLS library will do if handed a request to
do TLS when the security level happens to be "none". In particular,
various TLS-related bits for the session may not be set, and crashes
are possible. We need a check that the current destination's policy
is not TLS_LEV_NONE.
This can happen if there is a policy table, and either the global
default is "none" or the destination's policy is perversely "none".
If there is a new parameter, we'll need a new transport in master.cf:
master.cf:
smtps unix ... smtp
-o smtp_tls_wrapper_mode=yes
-o smtp_tls_policy_maps=$smtps_tls_policy_maps
-o smtp_tls_security_level=$smtps_tls_security_level
-o smtp_tls_CAfile=$smtps_tls_CAfile
And related settings in main.cf:
main.cf:
# PKIX verification and no policy overrides, with just the
# CAs requires to verify the supported relay sites:
#
smtps_tls_security_level = secure
smtps_tls_policy_maps =
smtps_tls_CAfile = ${config_directory}/smtps_CAs.pem
Perverse configurations with wrapper mode and a security level of
"none" are configuration errors.
--
Viktor.
