Viktor Dukhovni via Postfix-users:
> On Sun, Jun 08, 2025 at 07:29:22PM +0200, Geert Hendrickx via Postfix-users 
> wrote:
> > On Mon, Jun 09, 2025 at 00:42:20 +1000, Viktor Dukhovni via Postfix-users 
> > wrote:
> > > On Sun, Jun 08, 2025 at 09:29:17AM -0400, Wietse Venema via Postfix-users 
> > > wrote:
> > > 
> > > > > Can the default be decided at build-time (#ifdef), instead of with
> > > > > run-time conditional configuration?
> > > > 
> > > > That would result in an incompatible change for systems that are
> > > > not explicitly configured to enable TLS.
> > > 
> > > Yes, users of "distro" Postfix packages would see an incompatible
> > > change, ...  Mind you, some distros might already have made a such
> > > change.
> > 
> > 
> > The "may" default can still be behind a compatibility_level guard, I
> > merely wanted to suggest an alternative for the proposed built_with_tls
> > flag, as such runtime check turned out not so simple to implement.
> 
> I think you're suggesting a compile-time choice along the lines of:
> 
> --- a/src/global/mail_params.h
> +++ b/src/global/mail_params.h
> @@ -1465,9 +1465,16 @@ extern bool var_smtp_tls_enforce_peername;
>  extern bool var_smtp_tls_wrappermode;
>  
>  #define VAR_SMTP_TLS_LEVEL   "smtp_tls_security_level"
> -#define DEF_SMTP_TLS_LEVEL   ""
>  #define VAR_LMTP_TLS_LEVEL   "lmtp_tls_security_level"
> -#define DEF_LMTP_TLS_LEVEL   ""
> +#ifdef USE_TLS
> +#define DEF_SMTP_TLS_LEVEL   "${{$compatibility_level} <level {3.11} ?" \
> +                             " {none} : {may}}"
> +#define DEF_LMTP_TLS_LEVEL   "${{$compatibility_level} <level {3.11} ?" \
> +                             " {none} : {may}}"
> +#else
> +#define DEF_SMTP_TLS_LEVEL   "none"
> +#define DEF_LMTP_TLS_LEVEL   "none"
> +#endif
>  extern char *var_smtp_tls_level;
>  
>  #define VAR_SMTP_TLS_SCERT_VD        "smtp_tls_scert_verifydepth"
> 
> But this then has the side-effect of disabling support for the
> deprecated use_tls, enforce_tls and enforce_peername parameters,
> so really should part of a larger cleanup to remove all support
> for the Postfix 2.2 legacy TLS parameters including tls_per_site.

To preserve this legacy functionality they can set compatibility_level=3.11
and at the same time explicit empty values for *_tls_security_level. 

The explicit empty *_tls_security_level value prevents the Postfix
3.11 defaults from taking effect.

These explicit settings should then be added to the "Obsolete
configuration" columns of the exanples in DEPRECATION_README.html.

Also....

A while ago we discussed a guarded change for the default
smtpd_tls_security_level value that automatically evaluates to "may"
if >=1 certificate file is specified. Yesterday's dreaft code looks
like this:

#define DEF_SMTPD_TLS_LEVEL     "${{$compatibility_level} >=level {3.11} ? {" \
                                 "${{$built_with_tls} == {yes} ? {" \
                                  "${smtpd_tls_chain_files ? {may} : {" \
                                   "${smtpd_tls_cert_file ? {may} : {" \
                                    "${smtpd_tls_eccert_file ? {may} : {" \
                                     "${smtpd_tls_dcert_file ? {may}}" \
                                    "}}" \
                                   "}}" \
                                  "}}" \
                                 "}}" \
                                "}}"

As suggested, we could drop the built_with_tls check and simplify
the complex expression a bit.

> Removing [Postfix 2.2 legacy settings] at some point before too
> long is not unreasonable, the main question is whether 3.11 is the
> right opportunity, or whether the deprecation in 3.9 of use_tls
> and enforce_tls (but oddly not enforce_peername, I think an
> oversight) needs to bake in another release cycle or two?

Two years seems safe.

I now have code/documenmtation to add *_tls_enforce_peername to
the deprcated warnings.

        Wietse
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

Reply via email to