Viktor Dukhovni via Postfix-users:
> On Sun, Jun 22, 2025 at 01:02:44PM -0400, Wietse Venema via Postfix-users
> wrote:
>
> > > What I am talking about is the comment about the meaning "when SASL is
> > > enabled", as possibly applying to SASL being enabled somewhere else
> > > in Postfix, rather than the smtpd(8) service that is processing the
> > > restriction. This is the sort of fundamental misunderstanding of
> > > the system architecture that also leads some users to send smtp(8)
> > > parameter overrides in an smtpd(8) listener and expect these to
> > > affect later delivery of the incoming message.
> >
> > We could teach postfconf(1) to extract this information from source
> > code and warn about "unsued" -o overrides.
> >
> > Algorithm:
> >
> > 1 - Mark as 'used' all parameters that are imported by libglobal
> > (mainly, in mail_params.c) and by libtls (mainly, in tls_misc.c).
> >
> > 2 - For program X, mark as 'used' all parameters that are explicitly
> > imported in program X, then flag -o overrides in master.cf with
> > parameters that are not marked as 'used' for program X, for
> > libglobal, and for libtls.
> >
> > This requires adding provenance info whetner a parameter is
> > imported by a libraty or by a specifuc program.
> >
> > Some of the parameters imported by libglobal and libtls will not
> > be used by every program, and some programs do not use libtls, but
> > the above would still detect many client parameter overrides on a
> > server commandline.
>
> This is only part of the more general confusion, but it is one of its
> most common forms, so could help some users to avoid confusion, if not
> too expensive to implement.
The complexity is comparable to what is already implemented. The
only new part is that the new algorithm also needs to know under
which source directory a parameter is imported (library or specific
program). The overrides in master.cf are already tracked on a
per-service basis.
> Would not however prevent misinterpreting "SASL enabled" to mean
> "somewhere else in Postfix" rather than in the actual service using
> a given feature that depends on SASL. :-(
That problem could be addressed by not having a monolithic name
space for all configuration parameters, but little namespaces
for common and per-program settings.
Wietse
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
