This is a discussion on Re: FreeTDS support for table lookups within the mailing.postfix.users forums, part of the Mail Servers and Related category; Victor.Duchovni@MorganStanley.com: > On Sun, 9 May 2004, Wietse Venema wrote: > > > Victor.Duchovni@MorganStanley.com: &...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
Victor.Duchovni@MorganStanley.com:
> On Sun, 9 May 2004, Wietse Venema wrote: > > > Victor.Duchovni@MorganStanley.com: > > > - All of multi-parameter map types support both external ".cf" and > > > "mapsource_" prefix notation in main.cf. > > > > The "mapsource_" prefix notation is deprecated. It is confusing > > because the parameters don't show up in postconf(1) output, and > > it encourages storage of passwords in main.cf. > > OK, if you insist (an alternative is to enhance "postconf" to output > parameters that are defined in main.cf). The key thing I want to add is > ${parameter} substitution even when the map is being defined in external > files. If it were up to me, I would use ${variable} only for main.cf > parameters and use %[alphabet-soup] for key/result substitutions. Likely > that is too radical a change, so we will need to support both with > ${special-variable} taking precedence over ${parameter}. ${maindotcfname} expansion is useful; I no longer insist that lookup key fields ($domain, $user, etc.) be expressed in the same manner. > > > - Parameters that hold passwords are read from a file when the parameter > > > value starts with a "file:/" prefix. > > > > There are other main.cf parameters (myhostname) that also need file > > name support. This would avoid the need for Debian's /etc/hostname hack. > > > > Introducing file name syntax for non-map lookup needs to be thought > > out carefully to avoid conflicts (either in code or in the user's > > brain) with map lookup. > > Yes, I think this makes sense. main.cf parsing needs to be revised. The first revision is invisible: set defaults properly before doing $name expansion. This would make it possible to implement "postconf -e" (show expanded parameter values) which is currently not possible. The second revision is visible and introduces quoting (and thus syntax versioning). But, that's unlikely to happen in 2.2 since I would like to catch up with lost time in the release schedule. Spring is an inconvenient time for me to do a Postfix release. > I really do think that "postconf" and "postconf -n" (but clearly not "-d") > should show ad-hoc parameter values. postconf is a scary piece of code that needs revising too. Wietse |