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 -- [email protected]
To unsubscribe send an email to [email protected]
