Hello Roel, A solution presents itself in using the configid field, which defaults to zero. If dbmail-pop3d and dbmail-imapd are started with no arguments, configuration items with a configid=0 is used, but server-specific configurations are possible, by specifying a config ID on the command line.
Each machine could post its dbmail.conf to the database with its configid, by adding a configid field to dbmail.conf. No configid present, the default is zero. Of course, this begs the question, asked here before, of why not just use dbmail.conf (rather than a database) to control the actions of the dbmail programs? That way, you COULD compile a generic dbmail that understands "all" databases types it's been modified for, and select it at run time, rather than compile time. RR> indeed this problem needs to be addressed; let's think it over before RR> implementing an ad-hoc solution right away :) RR> Are there more server-specific options like the bind-ip? Probably yes. RR> We still like the idea of a centralized configuration scheme; maybe we RR> could just amend the config table with an extra field 'HOSTNAME' for RR> server-specific options. If this field is NULL, the value will be RR> regarded as the value to be used when no matching 'HOSTNAME' is found RR> for a particular option. -- Jeff Brenton President, Engineered Software Products, Inc http://espi.com Questionable web page: http://dididahdahdidit.com Liberalism grants you the freedom to advocate any idea*. * Please see http://www.dididahdahdidit.com/except.php for a current list of exceptions
