このモードを使うのは全くお勧めしません。コマンドラインオプションとして指定します。内容もクライアントに送られます)。残念ながら、Netscapeクライアントはマッチするクライアント証明書が得られないと文句を言うか、ユーザクライアントに選択するための証明書のリストを提示するかのどちらかです。ネゴシエーションを完了できず、SMTPセッションを中断してしまいます。機能を使って証明書ベースの中継をさせたければ、証明書が必要となるでしょう。クライアント証明書を求めるサーバは、はじめに自分自身の証明書を提示しなければいけません。2.3はクライアントへの匿名暗号をデフォルトで提供しますが、サーバがクライアント証明書を求めるように設定されていると、これらは自動的に停止されます。設定することで、全てのTLS接続に対してリモートのSMTPクライアントに証明書を「要求する」と決めることもできます。無視され、警告がログに記録されます。yesCAファイルに列挙されたCAによって直接発行された証明書の場合、クライアント証明書の検証の深さは1で十分です。(ルートCAは実際に証明書を発行する特別なCAを発行して...)。TLSのみをサポートするAUTHデータを暗号化されていないチャネル越しに送ることはセキュリティリスクをもたらすことになります。SMTPサーバはTLSレイヤがSTARTTLSで動き出してからのみAUTHを案内し、また受け付けます。あっても、TLSが動作しているときのみAUTHを提供する方が便利です。クライアントとの互換性を維持するために、デフォルトでは暗号化なしでもAUTHを受け付けます。SMTPサーバおよびリモートのSMTPクライアントがセッションのネゴシエーションをおこなうと、いくらか計算時間とネットワークのバンド幅を消費します。プロセスでセッション情報はキャッシュされ、プロセスが終了するとセッション情報も失われます。プロセスで共有するために、永続性セッションキャッシュが使えます。数キロバイトのオブジェクトを保存できて連続操作をサポートしている、どんなデータベース形式でも指定することができます。DBMデータベースは小さなオブジェクトしか保存できないため、これには適しません。プロセスによって管理されるため、並列アクセスでも問題ありません。TLSセッションキーを繰り返しやりとりするのは負荷が高いため、セッションをキャッシュすることを強く推奨します。SMTPサーバセッション情報は一定の時間が経過すると失効します。最大の24時間を推奨しています。サーバがTLSセッションを外部キャッシュデータベースに保存しなければ、クライアントサイドのセッションキャッシングが役に立つことはないでしょう。SMTPサーバはTLSセッションIDを発行しないように設定することができます。SMTPサーバは常にTLSセッションIDを発行します。これは一部のMUAとの既知の互換性問題を回避し、他のMTAとの互換性問題を予防します。要求を出すことを許可します。テーブルのキーとしてそのフィンガープリントを使います。機能は注意して使わなければいけません。いうのは、アクセス権限が多くなりすぎるかもしれないためです。ある特別なCAがクライアント証明書を発行し、このCAが信頼されたCAとしてリストアップされている場合にのみ、この機能を使ってください。他のCAが信頼されていると、有効なクライアント証明書の所有者はみんな認証されてしまいます。機能は特別に作られたEメールリレーサーバには実用的かもしれません。通してすべての証明書をリストアップするのがお勧めです。...Postfixのリスト操作ルーチンは空白やその他一部の文字を特別扱いするため、証明書名の使用は実用的ではありません。そこで代わりに偽造が困難で検索に使いやすい、証明書のフィンガープリントを使います。