[Dovecot] recipient_delimiter

Charles Marcus CMarcus at Media-Brokers.com
Fri May 28 23:26:53 EEST 2010


On 2010-05-28 2:18 PM, Phil Howard wrote:
> On Fri, May 28, 2010 at 14:06, Charles Marcus wrote:
>> On 2010-05-28 1:00 PM, Phil Howard wrote:
>>> Have you seen any config check tools?

>> Yes - it's called a brain. ;)

> I think you are missing the point.

Not...

> A config check tool would be sifting through the details of the
> main.cf file, and the postconf-n.out file, and reporting the
> difference between what one thinks they have configured and what
> Postfix understands the configuration to be.

??? Again, that's what your *brain* is for. There is no program capable
of reading one's mind, or ascertaining details of your environment
and/or system requirements.

>> Seriously - only you know your environment well enough to evaluate
>> any given config.

> I think you are missing the point.

Not...

> Since what Postfix uses as the configuration isn't guaranteed to be 
> what is coded ...

Sure it is...

> because config items do get changed by subsequent config items ... 

??? Not sure what you mean by that. If the same setting is defined
multiple times in main.cf, the last one wins. That is well documented.

> a tool that can compare things comes in valuable.

It depends, but yes, some brains are valuable.

> We all know that doing things in less time is a good thing (or else 
> there would be not complaint about wasting time).  But manually 
> sifting through two files, point by point, and cross checking 
> everything, every time, is as much, or more, of a time waster.

What 2 files? I thought we were talking about ,ain.cf/postconf -n output?

> And given that it would be done quite often, one is wasting a lot of
>  time if they carry out that process.  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),

That describes postconf to a 't'... :)

> 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".

Nope... it is enough to know that if a setting is defined twice, the
last one wins. If you define a setting, and postconf -n output doesn't
show what you expect, then the very first thing to do is grep main/cf
for that term to see if it in there more than once. The second thing to
do is make sure you're editing the right main.cf file.

>> 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.

It isn't *supposed* to complain - the *documented* behavior is that the
last value wins.

This in fact makes customizing settings easy (at least for me). I just
put all of my settings at the end of the file, so I know that those will
be the ones used regardless of what is specified above.

-- 

Best regards,

Charles


More information about the dovecot mailing list