From: Wietse Venema (no email)
Date: Mon Nov 24 2003 - 11:12:39 EST
Bert Driehuis:
> On Mon, 24 Nov 2003 wrote:
>
> > > my_lenient_restrictions = reject_unauth_destination
> >
> > Not very useful. Try:
> >
> > my_lenient_restrictions = reject_unauth_destination, permit
>
> I know my ruleset needs a cleanup, but the whole set does work as I
> intend it to work. The question I tried to raise is: "shouldn't postconf
> be able to include the user restrictions in its output?"
It could, and after a rewrite of Postfix parameter management in
the future, it probably should. Right now, making postconf aware
of restriction classes would require a special case, just like the
special cases for the parameter names that are constructed from
master.cf service names.
Currently, there is no central table of all the parameters and
default settings. Each Postfix daemon or command knows only those
parameters that it needs, and therefore it has to ignore any main.cf
parameters that it does not need to be aware of. There is no way
that a program can complain about an unknown or mis-typed parameter
name.
The postconf command was added after the essential commands and
daemons were already implemented. Because there was no central
table of parameters available, the postconf table of parameters
was constructed at compile time from the parameter tables that are
coded into individual Postfix commands and daemons.
> I always expected postconf, when run without parameters, to produce an
> exact replica of all the operative bits in main.cf. With the
> introduction of user restriction classes, that was lost.
The main.cf name space is independent from the parameter namespace.
That can't be changed until all parameters are defined in a central
place. Even when parameters are centralized, it may be useful to
define your main main.cf names. It's a language on top of Postfix.
Wietse
|
|
|