That's helpful. Thanks.
> -----Original Message-----
> From: [email protected] [mailto:owner-postfix-
> [email protected]] On Behalf Of Viktor Dukhovni
> Sent: Wednesday, September 10, 2014 10:11 AM
> To: [email protected]
> Subject: Re: Restricting relay of attachments
>
> On Wed, Sep 10, 2014 at 09:55:16AM -0700, Michael Fox wrote:
>
> > Hmmm. O.K. Thanks to both of you. It will take me some time to think
> this
> > through.
> >
> > The level of indirection between main.cf and master.cf sure adds
> > flexibility. But, as someone who doesn't work in postfix every day or
> even
> > every week, it also leaves my head spinning. ;-)
>
> The easiest way to understand this is that main.cf is just a lookup
> table that preempts built-in defaults and is loaded at the start
> of each Postfix daemon process. This lookup table is in turn
> preempted by "-o" command-line switches.
>
> However, both on the command-line and in main.cf itself, parameters
> can be recursively defined in terms of other parameters or just
> ad-hoc made up "macros".
>
> Since the master.cf file is does not support white-space in argument
> values, and is not a good place for maintaining complex parameter
> settings, the best practice approach to master.cf overrides is to
> define them indirectly in terms of sensibly named "macros" that
> are actually defined in main.cf.
>
> main.cf:
> some_override =
> ... too complex to specify directly in master.cf ...
>
> master.cf
> service type ... daemon-program
> -o some_parameter=$some_override
> ...
>
> Even if the override value is very simple, it may be better to use
> indirection via main.cf, so that someone reading just main.cf can
> infer that there are likely master.cf overrides and it may be wise
> to look there also.
>
> --
> Viktor.
