On Thu, Oct 24, 2024 at 01:24:07PM +0300, Eugene R via Postfix-users wrote:
> On 24.10.2024 08:24, Viktor Dukhovni via Postfix-users wrote:
> > Yes, of course, as documented. TLS is off by default, this is
> > backwards-compatible behaviour, and Postfix aims to not "surprise"
> > operators with unexpected new behaviour after an upgrade. Default
> > settings are in part also the responsibility of vendor distributions
> > that determine how the Postfix software is built, and what settings
> > are used in initial deployments.
> >
> > Now perhaps at this point, we could (if Wietse concurs) change the
> > default security level to "may" when (almost always nowdays) TLS is
> > enabled at compile time. Gmail stats for TLS in/out are quite close
> > lately to 100% in both directions:
>
> But with "TLS on by default out of the box", who and how will be responsible
> for providing the valid certificates? I am not sure it can (and should) be
> handled automatically, as it requires an operator to make certain policy and
> technical decisions as well as to specify various data values. Even when
> using, e.g., a script from Dovecot to generate a self-signed certificate.
We're talking about the SMTP client, not the server. As for the server,
OS distros could easily arrange to generate a "snake-oil" (self-signed)
cert (IIRC Debian has one by default).
Meanwhile, on the server side we could set:
# Default to "may" when a cert file is configured.
#
smtpd_tls_security_level =
${smtpd_tls_chain_files ? {may} :
{${smtpd_tls_cert_file ? {may} :
{${smtpd_tls_eccert_file ? {may} :
{${smtpd_tls_dcert_file ? {may}}}}}}}}
Possibly with a top-level compatibility-level guard.
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
