On 9/20/15, Wietse Venema <wie...@porcupine.org> wrote:
> John Massai:
>> I have a Postfix instance that listens on one of many
>> interfaces/addresses available on a machine.
>>
>> There is one special smptd service in master.cf that I'd like to have
>> listen on several addresses (but not all, so I can't use "all").
>>
>> I have found that I can define the service once for every address and
>> it works great, but am not having luck trying to combine them into one
>> by specifying inet_interfaces (possibly because it conflicts with the
>> service definition itself?
>
> master.cf specifies information for the master daemon (fields 1-8)
> and for daemon processes (the daemon command-line arguments).  The
> master daemon passes daemon command line arguments to the daemon
> process; it is up to the daemon processes, not the master, to
> evaluate their command-line arguments.
>
> This clear separation of concerns is basic to the Postfix architecture.
> It means that some things cannot be done easily (such as groping
> user files from the SMTP daemon process). That is a feature.
>
> In your case, I suggest that you use make(1) to securely generate
> master.cf from a simpler template.
>
> Makefile:
>     master.cf: master.cf.proto
>           generate-new-master-cf master.cf.proto >master.cf.tmp \
>               && mv master.cf.tmp master.cf
>
> master.cf.proto:
>     DEFAULT:smtp inet  n       -       n       -       -       smtpd
>     pickup    unix  n       -       -       60      1       pickup
>     cleanup   unix  n       -       -       -       0       cleanup
>     qmgr      unix  n       -       -       300     1       qmgr
>     ...
>
> Where generate-new-master-cf expands each entry with DEFAULT into as
> many master.cf entries as needed.

Thanks for the suggestion and detailed explanation.

> I am reluctant to add support for {ip1,ip2,ip3...}:smtp in master.cf.
> The service name (here: {ip1,ip2,ip3...}:smtp) is also used to
> generate service-dependent parameter names. With many IP addresses,
> as in your use case, this could become unwieldy.

I agree, although that would offer a solution in this case. Perhaps
some sort of alias syntax could be added as well.

Reply via email to