On Fri, Sep 24, 2021 at 11:54:29AM -0400, Viktor Dukhovni
<postfix-us...@dukhovni.org> wrote:
> On Sat, Sep 25, 2021 at 01:08:29AM +1000, raf wrote:
>
> > Also, the following look like they are defined in
> > mail_params.h but they aren't in postconf.proto
> > (20210815 snapshot). This might be wrong. It's just a
> > quick hacky audit. Some of them might not be real
> > parameters.
>
> There is no lmtpd(8) in any released version Postfix, so we can ignore
> those. Of the remaining parameters:
>
> > lmtp_tls_wrappermode (added a few days ago)
> > tlsproxy_client_level (already mentioned - should probably be
> > tlsproxy_client_tls_security_level)
> > tlsproxy_client_policy (should probably be
> > tlsproxy_client_tls_policy_maps)
> > mailbox_defer_errors
> > maildir_defer_errors
> > postscreen_dnsbl_enable
> > postscreen_greet_enable
> > proxy_read_access_list
> > proxy_write_access_list
> > tlsproxy_tls_received_header
> > transport_null_address_lookup_key
>
> The only ones that occur in the code are the first three (after
> my reordering of the list):
>
> src/smtp/lmtp_params.c: VAR_LMTP_TLS_WRAPPER, DEF_LMTP_TLS_WRAPPER,
> &var_smtp_tls_wrappermode,
> src/tlsproxy/tlsproxy.c: VAR_TLSP_CLNT_LEVEL, DEF_TLSP_CLNT_LEVEL,
> &var_tlsp_clnt_level, 0, 0,
> src/tlsproxy/tlsproxy.c: VAR_TLSP_CLNT_POLICY, DEF_TLSP_CLNT_POLICY,
> &var_tlsp_clnt_policy, 0, 0,
>
> The rest appear to be vestigial, and can likely be simply dropped from
> mail_params.h.
>
> The "tlsproxy_client_policy" parameter is only used to determine whether
> it is empty or not, in order to determine whether to enable the client
> TLS engine.
>
> clnt_use_tls = (var_tlsp_clnt_use_tls || var_tlsp_clnt_enforce_tls);
>
> /*
> * Initialize the TLS data before entering the chroot jail.
> */
> if (clnt_use_tls || var_tlsp_clnt_per_site[0] || var_tlsp_clnt_policy[0])
> {
>
> It should generally be left at its default value:
>
> $ postconf -d tlsproxy_client_policy
> tlsproxy_client_policy = $smtp_tls_policy_maps
>
> It could probably have been just a boolean to indicate that tlsproxy(8)
> should be prepared for client connections:
>
> tlsproxy_client_policy = ${smtp_tls_policy_maps?yes:no}
>
> When multiple proxied smtp/lmtp transports are defined in master.cf,
> some may have policy tables, while the main.cf policy table may not
> be set.
It is documented as though the maps are used (but since it's documented under
a different name, maybe it is safe to change it to a boolean without the usual
heroic backwards compatibility safeguards):
tlsproxy_client_policy_maps (default: $smtp_tls_policy_maps)
Optional lookup tables with the Postfix tlsproxy(8) client TLS security
policy by next-hop destination. See smtp_tls_policy_maps for further
details.
This feature is available in Postfix 3.4 and later.
> It is perhaps time to drop support for some of the Postfix <= 2.2
> TLS parameters. Which can simplify the pile of booleans to just
> a single security level and then perhaps simply:
>
> tlsproxy_client_enable =
> ${smtp_tls_policy_maps ? {yes} :
> ${{$smtp_tls_security_level} != {none} ? {yes} : {no} } }
There are tlsproxy TLS parameters modelled on obsolete <= 2.2 ones
that were introduced as recently as Postfix 3.4:
tlsproxy_client_enforce_tls
tlsproxy_client_use_tls
tlsproxy_client_per_site
tlsproxy_use_tls
tlsproxy_enforce_tls
But I wouldn't know if that should affect any decision.
> --
> VIktor.
cheers,
raf
