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