チラ裏モード。ざっくり把握したら本家のドキュメントを読んで下さい。
Postfix 2.6 以降が対象。最近のディストロなら概ねクリアしているはず。
でも日本語リソースが少し不足気味かもしれない (よく見る和訳は 2.3まで)。
インスタンス
Postfixにはインスタンスという概念があり、何も指定しなければシングルインスタンスモードで動作する。
ざっくり言えば1つのインスタンスにmain.cfとmaster.cfが設定できるイメージ。
正確にはconfig_directory, data_directory, queue_directory等も分かれる。
内部で共有しているTCP接続のキャッシュ等も全部分かれて管理される。
シングルインスタンスモード
main.cfに multi_instance_enable = yes がなければ必須こちらになる。普通は設定されていない。
コンパイル時に埋め込まれるconfig_directory等を使う。事実上 /etc/postfix/main.cf とかを読むわけ。
マルチインスタンスモード
multi_instance_directories の指定をすると、デフォルトの構成を元にしたデフォルトインスタンスに加えて別の構成のインスタンスを持てる。
/etc/postfix/ がある状態で、/etc/postfix-second/, /etc/postfix-third/ みたいに別のフォルダをこしらえることが出来る。
2つ目以上のインスタンスのディレクトリは、手動で作るのではなく postmulti コマンドを介して作成する。
postmulti がマルチインスタンスモードの有効化、インスタンス管理を一手に引き受ける
なお、ローカル環境からのメールはデフォルトインスタンスが食う想定。 sendmail とか。そういう意味で、厳密にはデフォルトインスタンスと立場上完全に同格のインスタンスを生成するのではない。各コマンドは共有され、通常はデフォルトインスタンスのmain.cfとかが参照されるので、適宜 -C オプションで参照する設定ファイルを変更する。
デフォルトインスタンスがあって、そのmain.cf等を読み込んだ際に「あ、マルチインスタンスモードなのです！」とPostfixが認識して、以降の追加のインスタンスを読み込むというイメージ。
使い所
「論理的に見て2つのインスタンスである」という場合に使用すると良いと思う。
参考までにデーモンやキュー等を筆者がまとめてみた図があるのでここにも示しておく (参考)。
マルチインスタンス構成では一連のプロセスも別となり、上図のプロセス、キューも全て別管理になる。全てを別立てで管理するほうがメリットがあればマルチインスタンスで、そこまでする必要がなければシングルインスタンスでがんばれば良い。
例えばnetstatで特定のポートを専有しているプロセス番号から、どちらのインスタンスがそのポートを使っているかを判断できる。例えば127.0.0.1:25をどちらがリッスンしているかが分かる。インターネットに接している複数のIPそれぞれに対して異なるバックエンドを用意したいかもしれないし、localhostに用途に応じて2つサブミッションポートを持つかもしれない (両方共筆者が実際に出会ったユースケース)。
master.cfにおいて特定のPostfix内のコンポーネントについて1〜2つオプションを追加するだけで容易に問題が解決するのなら、強いてマルチインスタンスにする必要はない。
master.cfを壮大にいじくり回して -o オプションを乱舞させるような事態になるなら考えた方が良い。一組のmain.cf, master.cfでそれぞれのポートに対してオプションを指定して異なる挙動を達成しようとすると、Postfixのどこかのプロセスでメールが「混ざる」症状に頭を悩ませることになる。上図の通り、smtpd(8)のオプションを少し捻った程度では「混ざる」症状は回避できない。当たり前だが、シングルインスタンス構成ではまず、キューが分離できない。
なお、マルチインスタンス構成をシングルインスタンス構成に戻すハードルは結構低い。マルチインスタンス化毎に作成される特定のディレクトリ3つ程度を削除して、/etc/postfix/main.cfに追加されたマルチインスタンス化オプションを消すだけ。
気軽に試してみてまずそうなら切り戻す、という態度でも行ける気がする。実際に試して動くことを確認してしまうと、おもったよりもマルチインスタンス化する敷居は低くなる気がした。
参考
以下を読めば使い方は分かる。
ただ、上の概要的な話がドキュメントの後半に出てくるので、まずチラ裏風の説明があると良いと思いこの記事が出来た。