In answer to my question, and so others don't have to trudge thru the source to find it...
The 'parameter name' may be and non-space, non-equals (i.e. =) string of characters. For those who may be curious... one can start with something like postconf.c leading to: cfg_parser_alloc() in ./src/global/cfg_parser.c which uses dict_load_file()->dict_load_fp() in ./src/util/dict.c which uses split_nameval() in ./src/util/split_nameval.c In split_nameval() we see that the 'parameter name', ie the key portion of a 'key' = 'value' pair and can be any sequence of ascii-non-space (as defined in isspace(3)). It would be nice if this was in the postconf(5) man page, first bullet stating: Each logical line is in the form "parameter = value". Whitespace around the "=" is ignored, as is whitespace at the end of a logical line. I would have submitted this as a feature request, but I failed to find where a person can report a bug or submit a feature request... Regards, ..Otto > -----Original Message----- > From: owner-postfix-us...@postfix.org > [mailto:owner-postfix-us...@postfix.org]on Behalf Of Otto Hirr > Sent: Tuesday, January 26, 2010 3:35 PM > To: postfix-users@postfix.org > Subject: main.cf - "paramter name" format > > > What is the valid format for a parameter name? > > It is not specified in postconf.5. > > Specifically is a - (dash) embedded in the name, > a valid parameter name? > > Where this is of interest is the interplay between > defining a service in master.cf (specifically using pipe(8)), > and then wanting to create the <transport>_destination_recipient_limit > in main.cf. > > As an example, 'old-cyrus' is a commented out example found > in master.cf, and it is a pipe(8). So can the parameter name > be "old-cyrus_destination_recipient_limit"? > > 'postfix check' seems not to complain. > But that does not make it valid per parsing methods... > Many "mini-languages" don't permit - (dash) in the names because > it is considered more like an "operator". > > Would be nice to have the postconf(5) spec parameter name format > requirements. > > Thanks for any input... > > Best regards, > > ..Otto > > >
