postfixのデフォルトがchroot以外のプロセスに変更されたのはなぜですか？
最近のpostfixバージョンでは compatibility_level = 2 で、postfixデーモンのデフォルトがchrootからnon-chrootに変更されました。このページには、変更された内容と、chrootの使用を継続または停止するためにできることが記載されていますが、理由はありません。
なぜ彼らはデフォルト値を変更したのですか？ chrootなしで実行することに利点はありますか？
PostfixソースコードをダウンロードしてHISTORYファイルを調べると、この変更が2014年10月1日に行われたことがわかります（Snapshot 20141001）：:
Master.cfの新しいデフォルト
chroot（n）、append_dot_mydomain（いいえ）およびsmtputf8_enable（はい）。
対応するgit commit は、現時点でソースコードとドキュメントに加えられたすべての変更を示しています。残念ながら、このデフォルト設定を変更する理由の説明はほとんどありません。
すでに述べたように、 Postfix Backwards-Compatibility Safety Net は次のように述べています。
新しいデフォルトでは、Postfixキューディレクトリの下にシステムファイルをコピーする必要がなくなります。
そして Postfix Basic Configuration
マシンに異常なセキュリティ要件がある場合は、chroot環境内でPostfixデーモンプロセスを実行することをお勧めします。
一部のインターネット検索では、この変更の背後にある理論的根拠に対するいくつかの手がかりが見つかりました。
chrootの使用に関する2008年の議論 で、Wietseは言った
デフォルトでPostfixをchrootするのは不適切だと思います。 Chrootは専用ファイアウォールで意味があります。汎用デスクトップはWebブラウザーを実行し、Postfixよりもはるかに大きな攻撃対象領域を持っています。
後で 2011
Chrootのサポートは、アクセスポリシーが非常に制限されているサイトに適しています。
また、Postfix2.6のSASL_READMEで以下を読みました。
SASLサポートでchrootされたソフトウェアを実行することは、興味深い演習です。トラブルの価値はありません。
このファイルのテキストは最近のリリースで変更されていますが、これは、chrootjailでメールサーバーを実行することによって問題が発生したことを示しています。 postfix-usersメーリングリスト のアーカイブをスキャンすると、これが一部のユーザーに問題を引き起こしていたことがわかります。
私は個人的にchrootjailでPostfixを実行し、saslauthdを使用していませんが、UNIXソケットを介してchrootされたPostfixデーモンと通信できるようにmilterを構成するためにいくつかの追加手順を実行する必要がありました。