On Fri, May 28, 2010 at 15:28, Jerry dovecot.user@seibercom.net wrote:
Exactly what type of system are you trying to support? I fail to understand why you are constantly changing the base Postfix configuration. I add/delete users on a virtually daily basis, however, once my basic Postifx configuration was setup, I have had no reason to mess with it. If you are modifying it on a daily basis, you are probably doing something wrong.
One that is just getting started. I expect to get to a point where I don't need to modify it. Not there, yet. We needed to get going on this sooner than originally planned, so not everything is in place, yet. For example, spam and virus trapping are still to do (next [*]). And tweaks are still possible for things like file locations as automation processes are added (later). I bet you have those thing already in place and thus don't need to change it.
[*] Still trying to figure out how to make SpamAssassin put what it thinks is spam into an incoming spam box, rather than the usual INBOX (also seeking to find what name of such a box most people use). And that's in addition to another mailbox which users will move spam to, that comes into their INBOX, to be extracted at the server for training.
This tool would have to understand how Postfix interprets the config file (maybe just sufficient to know that conflicting config items don't produce errors or warnings in postfix or postconf), and just produce the warnings ... "hey dude, you specified foo = 1 and later foo = 2 ... can't have it both ways, so you better go check on that".
Correct, you can only have the last one (Postfix). I am not sure about Dovecot. Then again, I don't enter rules haphazardly.
Dovecot has sections and can do multiple sections. This is the Dovecot mailing list so you can ask about it here.
Again, the output of "postconf -n" is what Postfix sees and understands. If you think you have duplicate values in the file, try 'grep' to locate them. It doesn't make any difference though since the last one wins no matter what.
NOTE: One known exception is:
dovecot_destination_recipient_limit = 1
This does not display with "postconf -n". Wietse once explained why; however, I don't remember why any more. By the way, if you are doing virtual delivery with Postfix/Dovecot, you should probably have that in the "main.cf" file. As always, YMMV.
I'm assuming because it is a dynamically named setting for a transport.
Use the tools, Luke... postconf -n and dovecot (or doveconf for 2.0) -n will complain for syntax errors, but it is up to you to evaluate the output.
But it doesn't complain for conflict errors. And that was the class of error that happened.
What conflict error? It would not happen in Postfix's "main.cf" file.
Two like settings, where one would not be used, regardless of which (whether it's a first setting wins or a last setting wins system), is a conflict in my book. I'd have made the system flag it as an error (except maybe if both settings would have the exact same effect) and maybe not even start up.
If postconf -n carried comments along, then it could be used as a config linter ... let it's output replace the original and that will be the one to edit for the next change.