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. 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. :-(
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
