Although I'm still not really sure how this would work either. Currently the settings in login group you defined first (imap by default) are used as defaults for the second login group (pop3). That's kind of messy I think..
Maybe I should completely drop the login group and rather make protocol groups. Something like:
(etc)
Perhaps some of the confusion is that it looks like you are using groups as a way both to encapsulate a group of settings and as a way to override inheritence of global settings. While those things are similar it's hard to generalize them by way of nested statements.
On the other hand I could be all wet :-)
(Somebody mentioned BIND9, but it looks more like you have been reading innfeed conf files. Bind9 configs are completely block oriented- innfeed confs have the peculiar line-oriented commands with block encapsulations).
At any rate perhaps a different way to accomplish parameter grouping would be to define templates and invoke those templates within scoped declarations, e.g.:
template standard { login_process_size = 16 login_process_count = 3 first_valid_uid = 100 last_valid_gid = 0 }
template wide-open { like standard first_valid_uid = 0 }
server a { like standard // nested reference to another template imap_listen a.b.c.d ... }
server b { like wide-open imap_listen e.f.g.h }
I could imagine implementing a "template" as a set of context-free tag/value pairs. When invoked (e.g. via "like") the parser would simply note the reference to the template, and eventually parse the tag/value pairs when the scope is closed, applying those that had not already been specifically set.
This may not be what you were thinking about, in which case, you can ignore it...
-mm-