[Dovecot] recipient_delimiter

[Phil Howard]

On Fri, May 28, 2010 at 15:28, Jerry <dovecot.user at 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.