In order to support multiple postfix instances, postfix uses multiple systemd
unit files.  The overall postfix unit is for overall operations on all
instances and individual unit files are available for each instance named
postfix@${INSTANCE_NAME}.  The primary instance is named "-", so it can be
directly addressed with systemctl using the name postfix@- (e.g.
systemctl status postfix@-).  Wild cards work and so systemctl status postfix*
will show the status of all active postfix units.

In order to configure multiple postfix instances, follow the upstream
directions (MULTI_INSTANCE_README) up to the point of starting the new
instance.  Instead do the following (if running systemd - multi-instance with
sysv init is untested by the maintainers in Debian 9, code name stretch):

# systemctl daemon-reload
# systemctl enable postfix@${INSTANCE_NAME}.service
# systemctl start postfix@${INSTANCE_NAME}.service

Once that is done, the new instance will be started and its status will show
up with as part of systemctl status postfix*.


There are some significant differences between the Debian Postfix packages,
and the source from upstream:

1.  The Debian install is chrooted by default.
2.  Debian init system (systemd or sysv init) commands (e.g. systemctl or
    service) should be used in lieu of direct calls to the postfix binary as
    described in the upstream documentation is order to problem integrate with
    Debian features such as using the system CA certificate bundle and proper
    chroot configuration with system libraries and services.
3.  For policy reasons:
  a. SASL configuration goes in /etc/postfix/sasl
  b. myhostname=/path/to/file is supported (and used) in main.cf
4.  IPV6 support is enabled: postfix listens on ipv6/ipv4 by default,
    (see: inet_protocols)
5.  TLS/SASL support is enabled.
6.  rmail comes from sendmail, not from postfix.
7.  The upstream main.cf is delivered as /usr/share/postfix/main.cf.dist,
    rather than cluttering /etc/postfix/main.cf with comments.

Known caveats:
1.  The dynamically loadable modules are not found in the chroot.
    Therefore, proxy maps may require you to copy the appropriate shared
    object into the chroot if you chroot the proxy service in master.cf.
2.  Some map types (and SASL support) require some extra configuration
    (beyond what upstream indicates) to run inside the chroot.  The simplest
    solution for the maps is to use the proxy service, which is not chrooted.
    SASL is a bit more complex, and is on the TODO list...
3.  Note that the chrooted daemons open /dev/log before chrooting, so if your
    syslog daemon is restarted, the daemons will be unable to reconnect to the
    syslog socket, and hence being unable to log.  The postfix package provides
    a config snipped for the rsyslog daemon in /etc/rsyslog.d/postfix.conf to
    also open a socket in /var/log/postfix/dev.  For other syslog daemons, you
    will also have to restart postfix after restarting the syslog daemon, or
    configure it to open an additional socket.
  a. For sysklogd (the default in Debian versions prior to Lenny), add
     SYSLOG="-a /var/spool/postfix/dev/log" to /etc/default/syslog.
  b. For inetutils-syslogd, add SYSLOGD_OPTS="-a /var/spool/postfix/dev/log" to
     /etc/default/inetutils-syslogd.
4.  Map types from the dynamically loadable modules are supported for the
    alias database, but it is up to the system administrator to ensure the
    required package is installed before changing the postfix configuration.
    After changing the map type, newaliases must be run by hand.
