Robert Moskowitz: > On 01/14/2013 03:59 AM, Wietse Venema wrote: > > Robert Moskowitz: > >> It does raise a question if there is an uncomment option? For example > >> submission is commented in the master.cf and a very frequent uncomment > >> target. > > I don't understand how that would work. > Actually, I don't either!
See http://www.postfix.org/postconf.5.html#master_service_disable for an approach that avoids these issues. This feature uses DNS-like notation to select a service, i.e. "service.type" or just "type": master_service_disable = inet (disable all inbound network servers) master_service_disable = inet pickup.fifo (disable inbound mail) Now, this uncovers one minor problem in my plans. I adopted the same DNS-like notation for "postconf -M", for example: # postconf -M inet (show all inbound network services) # postconf -M inet pickup.fifo (show inbound mail services) But the RFCs in this thread seem to favor the reverse, MIB-style, notation: type.service and type.service.attribute. Fortunately things can be changed, whether in design (easy) or in deployment (more work). First, where would postconf use pathname notation? It is a natural approach if we want to update or query individual service attribute values. This is especially useful for scripting. With the DNS-like notation, that would look like: # postconf -M chroot.smtp.inet=n process_limit.smtp.inet=25 # postconf -M chroot.smtp.inet process_limit.smtp.inet chroot.smtp.inet = n process_limit.smtp.inet = 25 # postconf -Mh chroot.smtp.inet n With the MIB-style notation proposed by mouss, the equivalent commands would look like: # postconf -M inet.smtp.chroot=n inet.smtp.process_limit=25 # postconf -M inet.smtp.chroot inet.smtp.process_limit inet.smtp.chroot = n inet.smtp.process_limit = 25 # postconf -Mh inet.smtp.chroot n Both notations are equally capable (and the MIB notation perhaps more natural). More important is that the MIB-style notation appears to be more common for attribute manipulation. How do we reconcile the differences? It's easy enough for designs that haven't been implemented and it's the cost of business for users of a development release, but it requires a planned migration when it affects users of a stable release. If we are to use "type.service" in "postconf -M" commands, then historical features that use "service.type" will have to be migrated to that form, too. The affected features are master_service_disable (introduced with Postfix 2.6), and with "postconf -M" (introduced with Postfix 2.9). These will have to support both forms for the near future (use the preferred syntax first, and fall back to its reverse if the prefferred syntax does not work). I did not expect that Postfix would end up with little-endian versus big-endian issues, but there we are. Wietse
