Postfix TLSサポート

警告

PostfixでTLSサポートを有効にすることで、メールを暗号化したりクライアントやサーバの認証もできるようになるだけではありません。数千行にもおよぶ OpenSSLライブラリコードも有効にしてしまうのです。OpenSSL が Wietse 自身のコードと同じくらい注意深く書かれているとすると、1000行ごとに1つ、余分なバグをPostfixに取り入れていることになります。

Postfix TLSサポートができること

トランスポート層セキュリティ (Transport Layer Security/TLS、以前はSSLと呼ばれていました) は証明書ベースの認証と暗号化セッションを提供します。セッションの暗号化により、SMTPメールやSASL認証で伝送される情報が保護されます。

Postfixバージョン2.2は、RFC 3207に記述されているTLSサポートを組み込みました。古いバージョンのPostfixでのTLSサポートはアドオンパッチとして入手できます。以下の "Postfix < 2.2 TLSサポートの互換性" でこれらの実装の違いを議論しています。

このドキュメントがカバーしている話題:

大事なことを書き忘れたが、せっかちな人のために:

Postfix TLSサポートの動き

以下の図はPostfix TLSアーキテクチャの主な要素とその関係を表しています。数字が付いた名前の書かれた色つきの箱はPostfixデーモンプログラムを表しています。他の色つきの箱はストレージ要素を示しています。

ネットワーク->
smtpd(8)
 		 <---シード---

<-セッション->
tlsmgr(8)
 		 ---シード--->

<-セッション->
smtp(8)
 		 ->ネットワーク
/
/
|
|
\
\
smtpd(8)
セッション
キーキャッシュ		 PRNG
状態
ファイル		 smtp
セッション
キーキャッシュ

TLSサポート付きでPostfixをビルドする

TLSサポートを付けてPostfixをビルドするには、まず必要な定義の書かれた make(1) ファイルを生成する必要があります。これはPostfixトップレベルディレクトリで "make makefiles" コマンドに次に示す短い引数を付けて呼び出すことで生成されます。

注意: Gnu TLSを使わないでください。Postfixは 1) maillogファイルにエラーを 報告して、2) 適切な平文サービスを提供できず、Postfixデーモンプロセスは終了ステータスコード2で終了させられてしまいます。

他のカスタマイズ (Berkeley DBデータベースや MySQL、PostgreSQL、LDAP、SASLなど) を適用する必要があれば、それぞれのPostfix READMEドキュメントを参照し、それらの "make makefiles" の指示と上の指示を組み合わせてください:

% make tidy # 以前のビルドで残っているファイルがある場合
% make makefiles CCARGS="-DUSE_TLS \
    (他の -D または -I オプション)" \
    AUXLIBS="-lssl -lcrypto \
    (/usr/lib にある他のライブラリ用の -l オプション) \
    (他のライブラリ用の -L/path/name + -l オプション)"

構築プロセスを完了するには、Postfix INSTALL の指示を参照してください。PostfixはデフォルトでTLSサポートが無効になっているため、インストールしたらすぐにPostfixを使い始めることができます。

SMTPサーバ特有の設定

このセクションがカバーしている話題

サーバ証明書と秘密鍵の設定

TLSを使用するために、Postfix SMTPサーバは一般に証明書と秘密鍵を必要とします。どちらも "PEM" 形式でなければいけません。秘密鍵を暗号化してはいけません。つまり: 鍵はパスワードなしでアクセスできなければいけません。証明書と秘密鍵が両方とも同じファイルに入っているかもしれませんが、その場合証明書ファイルは "root" が所有し、他のユーザから読めないようにすべきです。鍵が別に保管されるのであれば、これは鍵ファイルにのみ適用され、証明書ファイルは"誰でも読み込み可能" であってもかまいません。

"信頼できる" CAによって署名された証明書がない、公開されたインターネットMXホストは自己署名もしくはプライベートCAによって署名された証明書を生成し、たいていのクライアントに提供する準備をしなければいけません。クライアントはサーバを認証できませんが、Postfix 2.3もしくは同様なソフトウェアを動かしているのでなければ、サーバ証明書を要求し続けるでしょう。

公開されたインターネットMXホストではないサーバでは、Postfix 2.3は証明書なしの設定をサポートしています。これは単に匿名TLS暗号を使うことになり、たいていのSMTPクライアントではサポートされていません。たいていはそのようなクライアントはTLSハンドシェイクに失敗した後で平文に落とそうとはしないため、サーバはTLSが有効なほとんどのクライアントからeメールを受け取れなくなるでしょう。誤って証明書なしで設定してしまうのを避けるため、 Postfix 2.3は管理者が明示的に "smtpd_tls_cert_file = none" を設定したときのみ証明書なしの動作を有効にします。これにより新しいPostfix設定が誤って証明書なしで動かないようにすることを保証します。

RSAおよびDSA証明書の両方がサポートされています。たいていは商用CAによって発行されたRSA証明書のみを持っていることでしょう。さらに、OpenSSLとともに提供されるツールはデフォルトでRSA証明書を発行します。同時に両方持つことができ、その場合には使われる暗号によってどちらの証明書が出されるかが決まります。NetscapeおよびOpenSSLクライアントでは特に暗号を選ばない限り、RSA証明書が優先されます。

リモートSMTPクライアントがPostfix SMTPサーバ証明書をチェックするには、 CA証明書 (証明書チェーンの場合はすべてのCA証明書) が入手可能でなければいけません。中間のCA証明書をサーバ証明書に加えるとよいでしょう: サーバ証明書を最初にして、それから中間CAのものとします。

例: "server.dom.ain" の証明書は "intermediate CA" により発行され、それ自身は "root CA" により発行された証明書を持っているとします。次のように server.pem ファイルを作成します:

% cat server_cert.pem intermediate_CA.pem > server.pem

ここで与えられるPostfix SMTPサーバ証明書はSSLサーバ証明書として使えなければなりません。つまり "openssl verify -purpose sslserver ..." テストを通らなければいけません。

ルートCAを信頼しているクライアントはルートCA証明書のローカルコピーを持っているため、ここにルートCA証明書を含めておく必要はありません。"server.pem" からそれを除いておくと、TLS交換のオーバーヘッドを減らせます。

これらのCAによって発行されたリモートSMTPクライアント証明書をPostfix SMTP サーバが受け付けるようにしたければ、ルート証明書を $smtpd_tls_CAfile に追記するか、$smtpd_tls_CApath ディレクトリにインストールします。ルートCAの信頼を設定すると、$smtpd_tls_ccert_verifydepth が注目するクライアントへの証明書チェーンにおけるCAの数よりも小さくなければ、ルートCAによって署名された中間CAを明示的に信頼する必要はありません。検証の深さを1とすると、信頼する CAによって直接署名された証明書のみを検証します。深さが2であれば、ルートCAもしくは直接の中間CA によって署名されたクライアントを検証できます (クライアントが中間CA証明書を提供するように正しく設定されている限り)。

RSA鍵と証明書の例:

/etc/postfix/main.cf:
    smtpd_tls_cert_file = /etc/postfix/server.pem
    smtpd_tls_key_file = $smtpd_tls_cert_file

DSAで対応するもの:

/etc/postfix/main.cf:
    smtpd_tls_dcert_file = /etc/postfix/server-dsa.pem
    smtpd_tls_dkey_file = $smtpd_tls_dcert_file

Postfix 2.3以降で、匿名暗号が使えるクライアントに排他的にサービスするサーバで、証明書なしのTLSを使うには:

/etc/postfix/main.cf:
    smtpd_tls_cert_file = none

リモートSMTPクライアント証明書を検証するには、Postfix SMTPサーバは発行証明機関の証明書を信頼する必要があります。これらの "PEM" 形式の証明書は単一ファイルの $smtpd_tls_CAfile として保管するか、CA ごとに1ファイルとして複数ファイルを $smtpd_tls_CApath ディレクトリに保存できます。ディレクトリを使うのであれば、以下のコマンドで "hash" リンクを作成するのを忘れないでください:

# $OPENSSL_HOME/bin/c_rehash /path/to/directory

$smtpd_tls_CAfile は 1つ以上の信頼したCAのCA証明書を含んでいます。このファイルはPostfixがオプションのchroot監獄に入る前に (root権限で) 開かれるため、chroot監獄からアクセスできる必要はありません。

信頼された他のCAは $smtpd_tls_CApath ディレクトリを通して指定できますが、その場合証明書は ($mail_owner 権限で) 必要なときにこのディレクトリのファイルから読み込まれます。そのため、$smtpd_tls_CApath ディレクトリはオプションのchroot監獄の内部でアクセスできる必要があります。

クライアント証明書を要求するようにPostfixを設定する場合、あなたが信頼しているCAによって署名された証明書を選べるように、$smtpd_tls_CAfile のあらゆるCA証明書がクライアントに送られます。$smtpd_tls_CAfile が指定されていないと、優先CAリストは送られず、クライアントはいずれかのCAによって署名された証明書を自由に選びます。多くのクライアントは優先CAリストに関係なく決まった証明書を送るので、クライアントCA証明書のほどんどもしくはすべてを $smtpd_tls_CApath にインストールすることで、TLSネゴシエーションのオーバーヘッドを減らすことができるでしょう。後者の場合、$smtpd_tls_CAfile を指定する必要はありません。

注意: 多くのTLS認証されたクライアントがアクセスするのにクライアント証明書が使えないのであれば、クライアント証明書を全く求めないのがよいでしょう。オーバーヘッドが増えるのに加えて、クライアント証明書を要求されると TLSハンドシェイクを完了できないクライアント (特に一部のqmail) もあるためです。

例:

/etc/postfix/main.cf:
    smtpd_tls_CAfile = /etc/postfix/CAcert.pem
    smtpd_tls_CApath = /etc/postfix/certs

サーバ側TLS行動のロギング

Postfix SMTPサーバのTLS行動に関してさらなる情報を得るために、ログレベルを0から4まで増加させることができます。それぞれのログレベルは下位のログレベルで記録される情報も含みます。

0 TLS行動に関するログ記録を無効にします。
1 TLSハンドシェイクと証明書の情報をログに記録します。
2 TLSネゴシエーションの間のレベルをログに記録します。
3 TLSネゴシエーションプロセスの16進数およびASCIIダンプをログに記録します。
4 STARTTLS以降の通信の16進数およびASCIIダンプを完全にログに記録します。

問題があったときのみログレベル3を使ってください。ログレベル4は使わないことを強くおすすめします。

例:

/etc/postfix/main.cf:
    smtpd_tls_loglevel = 0

クライアントや発行者のCommonNameと同様に、使用されているプロトコルおよび暗号に関する情報を "Received:" メッセージヘッダに含めるには、smtpd_tls_received_header 変数を true にセットします。デフォルトは no で、それは情報が必ずしも正しくないためです。ヘッダは中間サーバによって変更できてしまうため、最終配送先で記録された情報のみが信頼できます。

例:

/etc/postfix/main.cf:
    smtpd_tls_received_header = yes

Postfix SMTPサーバでTLSを有効にする

デフォルトではPostfix SMTPサーバのTLSは無効になっており、見た目にはそのままの Postfixと違いはありません。明示的に "smtpd_tls_security_level = may" (Postfix 2.3以降) or "smtpd_use_tls = yes" (古いですがまだサポートされています) を使って有効にしてください。

例:

/etc/postfix/main.cf:
    # Postfix 2.3以降
    smtpd_tls_security_level = may
    # 古いが、まだサポートされています
    smtpd_use_tls = yes

これを設定すると、Postfix SMTPサーバはSMTPクライアントにSTARTTLSサポートを案内しますが、クライアントがTLS暗号化を使うことを要求するわけではありません。

注意: 権限のないユーザが "sendmail -bs" を呼び出した場合、サーバ秘密鍵にアクセスする権限がないため、STARTTLSは提供されません。これは意図された振る舞いです。

"smtpd_tls_security_level = encrypt" (Postfix 2.3以降) もしくは "smtpd_enforce_tls = yes" (古いですがまだサポートされています) を設定することでTLSの使用を「強制」することもでき、そうするとPostfix SMTPサーバはSTARTTLSを案内し、TLSで暗号化されていないメールは受け付けません。RFC 2487 に従うと、これは公に参照される Postfix SMTPサーバには適用しては「いけません」。このオプションはデフォルトで無効になっており、ほとんど使われることはないでしょう。

例:

/etc/postfix/main.cf:
    # Postfix 2.3以降
    smtpd_tls_security_level = encrypt
    # 古いが、まだサポートされています
    smtpd_enforce_tls = yes

TLSは時々、STARTTLSサポートをアナウンスしてクライアントがTLSサービスを要求するのではなく、サーバが常にTLSを使う、非標準 "ラッパー" モードで使われることがあります。一部のクライアント、はっきり言うと Outlook [Express] は "ラッパー" モードを優先します。これは OE (ポート25以外で動くWin32 < 5.0 およびWin32 >=5.0) と OE (ポートに関係なく5.01 Mac) に当てはまります。

main.cf からこのモードを使うのは全くお勧めしません。このサービスをサポートしたいのであれば、master.cf で特別なポートを有効にし、"-o smtpd_tls_wrappermode=yes" (注意: "=" の前後に空白を置きません) を smtpd(8) のコマンドラインオプションとして指定します。この機能のためにポート465 (smtps) がかつて選ばれていました。

例:

/etc/postfix/master.cf:
    smtps    inet  n       -       n       -       -       smtpd
      -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes

クライアント証明書の検証

リモートのSMTPクライアント証明書を受け取るには、Postfix SMTPサーバは明示的に証明書を要求しなければいけません (適切なCAから証明書を選ぶヒントとして $smtpd_tls_CAfile の内容もクライアントに送られます)。残念ながら、Netscapeクライアントはマッチするクライアント証明書が得られないと文句を言うか、ユーザクライアントに選択するための証明書のリストを提示するかのどちらかです。さらに、一部のMTA (特に一部のバージョンのqmail) はクライアント証明書が要求されるとTLS ネゴシエーションを完了できず、SMTPセッションを中断してしまいます。そのため、このオプションはデフォルトでは "off" になっています。しかし、例えば permit_tls_clientcerts 機能を使って証明書ベースの中継をさせたければ、証明書が必要となるでしょう。クライアント証明書を求めるサーバは、はじめに自分自身の証明書を提示しなければいけません。Postfix 2.3はクライアントへの匿名暗号をデフォルトで提供しますが、サーバがクライアント証明書を求めるように設定されていると、これらは自動的に停止されます。

例:

/etc/postfix/main.cf:
    smtpd_tls_ask_ccert = yes
    # Postfix 2.3以降
    smtpd_tls_security_level = may
    # 古いが、まだサポートされています
    smtpd_use_tls = yes

TLSを強制する場合、"smtpd_tls_req_ccert = yes" を設定することで、全てのTLS接続に対してリモートのSMTPクライアントに証明書を「要求する」と決めることもできます。この機能は "smtpd_tls_ask_ccert = yes" という意味も含みます。TLSを強制しない場合、"smtpd_tls_req_ccert = yes" は無視され、警告がログに記録されます。

例:

/etc/postfix/main.cf:
    smtpd_tls_req_ccert = yes
    # Postfix 2.3以降
    smtpd_tls_security_level = encrypt
    # 古いが、まだサポートされています
    smtpd_enforce_tls = yes

CAファイルに列挙されたCAによって直接発行された証明書の場合、クライアント証明書の検証の深さは1で十分です。デフォルト値 (5) はより長いチェーンでも十分な値です (ルートCAは実際に証明書を発行する特別なCAを発行して...)。

例:

/etc/postfix/main.cf:
    smtpd_tls_ccert_verifydepth = 5

AUTH over TLSのみをサポートする

AUTHデータを暗号化されていないチャネル越しに送ることはセキュリティリスクをもたらすことになります。TLSレイヤの暗号化が要求されると ("smtpd_tls_security_level = encrypt" もしくは古い "smtpd_enforce_tls = yes")、Postfix SMTPサーバはTLSレイヤがSTARTTLSで動き出してからのみAUTHを案内し、また受け付けます。TLSレイヤの暗号化がオプションの場合 ("smtpd_tls_security_level = may" もしくは古い "smtpd_enforce_tls = no") であっても、TLSが動作しているときのみAUTHを提供する方が便利です。非TLS クライアントとの互換性を維持するために、デフォルトでは暗号化なしでもAUTHを受け付けます。この振る舞いを変更するには、"smtpd_tls_auth_only = yes" を設定してください。

例:

/etc/postfix/main.cf:
    smtpd_tls_auth_only = no

サーバサイドTLSセッションキャッシュ

Postfix SMTPサーバおよびリモートのSMTPクライアントがセッションのネゴシエーションをおこなうと、いくらか計算時間とネットワークのバンド幅を消費します。デフォルトでは、このセッションを実際に使っている smtpd(8) プロセスでセッション情報はキャッシュされ、プロセスが終了するとセッション情報も失われます。セッション情報を複数の smtpd(8) プロセスで共有するために、永続性セッションキャッシュが使えます。数キロバイトのオブジェクトを保存できて連続操作をサポートしている、どんなデータベース形式でも指定することができます。DBMデータベースは小さなオブジェクトしか保存できないため、これには適しません。キャッシュは tlsmgr(8) プロセスによって管理されるため、並列アクセスでも問題ありません。TLSセッションキーを繰り返しやりとりするのは負荷が高いため、セッションをキャッシュすることを強く推奨します。

例:

/etc/postfix/main.cf:
    
smtpd_tls_session_cache_database = btree:/etc/postfix/smtpd_scache

キャッシュされたPostfix SMTPサーバセッション情報は一定の時間が経過すると失効します。Postfix/TLSはOpenSSLのデフォルトである300秒は使わず、もっと長い時間の3600秒 (=1時間) を使います。RFC 2246 は最大の24時間を推奨しています。

例:

/etc/postfix/main.cf:
    smtpd_tls_session_cache_timeout = 3600s

Postfix SMTP サーバがTLSセッションを外部キャッシュデータベースに保存しなければ、クライアントサイドのセッションキャッシングが役に立つことはないでしょう。そのような無駄を防ぐため、Postfix SMTPサーバはTLSセッションIDを発行しないように設定することができます。デフォルトでは、Postfix SMTPサーバは常にTLSセッションIDを発行します。これは一部のMUAとの既知の互換性問題を回避し、他のMTAとの互換性問題を予防します。

例:

    smtpd_tls_always_issue_session_ids = no

サーバアクセス制御

Postfix TLSサポートによってPostfix SMTPサーバアクセス制御に3つの機能が追加されました:

permit_tls_clientcerts

クライアント証明書が検証を通り、そのフィンガープリントがクライアント証明書のリストにリストアップされている場合に、リモートのSMTP クライアントがSMTP要求を出すことを許可します (以下の relay_clientcerts の議論を参照)。

permit_tls_all_clientcerts

クライアント証明書が検証を通った場合に、リモートクライアントがSMTP 要求を出すことを許可します。

check_ccert_access type:table

クライアント証明書が検証を通った場合に、指定された access(5) テーブルのキーとしてそのフィンガープリントを使います。

permit_tls_all_clientcerts 機能は注意して使わなければいけません。というのは、アクセス権限が多くなりすぎるかもしれないためです。ある特別なCAがクライアント証明書を発行し、このCAが信頼されたCAとしてリストアップされている場合にのみ、この機能を使ってください。他のCAが信頼されていると、有効なクライアント証明書の所有者はみんな認証されてしまいます。permit_tls_all_clientcerts 機能は特別に作られたEメールリレーサーバには実用的かもしれません。

しかし、証明書が使われなくなったとき (例えば従業員の退職など) には permit_tls_all_clientcerts がいかなる制御も許可しないため、permit_tls_clientcerts 機能にとどまって $relay_clientcerts を通してすべての証明書をリストアップするのがお勧めです。

例:

/etc/postfix/main.cf:
    smtpd_recipient_restrictions = 
        ... 
        permit_tls_clientcerts 
        reject_unauth_destination
        ...

Postfixのリスト操作ルーチンは空白やその他一部の文字を特別扱いするため、証明書名の使用は実用的ではありません。そこで代わりに偽造が困難で検索に使いやすい、証明書のフィンガープリントを使います。Postfix検索テーブルは (キー、値) の組の形式です。Postfix検索テーブルは (キー, 値) ペアの形です。キーだけが必要なので、値は自由に選ぶことができます。例えばユーザ名やホスト名など。

例:

/etc/postfix/main.cf:
    relay_clientcerts = hash:/etc/postfix/relay_clientcerts

/etc/postfix/relay_clientcerts:
    D7:04:2F:A7:0B:8C:A5:21:FA:31:77:E1:41:8A:EE:80 lutzpc.at.home

サーバサイド暗号制御

以下の記述はPostfix 2.3用です; Postfix < 2.3では smtpd_tls_cipherlist パラメータに、明示的なOpenSSL暗号リストとして受け入れる暗号を指定します。古い設定はTLS暗号化が強制されていない場合でも適用されます。この制御を公開されたMXホストで使用するのは全くお勧めできません。

TLS暗号化を強制すると、Postfix SMTPサーバはデフォルトでSSLv3もしくはTLSv1のみを使います。SSLv2はTLS暗号化がオプションの時にのみ使われます。これは smtpd_tls_mandatory_protocols 設定パラメータによって制御されます。

Postfix SMTPサーバは smtpd_tls_mandatory_ciphers 設定パラメータで指定される5つの異なる暗号セキュリティレベルをサポートしており、これによりTLS暗号化の強制に使う暗号グレードを決定します。デフォルト値は "medium" で、これは基本的に128ビット以上の暗号です。日和見なTLS暗号では、最低限受け入れられる暗号グレードは常に "export" です。

デフォルトでは匿名暗号は許可されていますが、クライアント証明書が要求されると自動的に無効にされます。クライアントに常にサーバ証明書を検証させるのであれば、"smtpd_tls_mandatory_exclude_ciphers = aNULL" を設定することで匿名暗号を除外したくなるかもしれません。誰もクライアントにサーバ証明書を強制することはできないので、一般に匿名暗号を除外する必要はありません。

インターネットに公開されていないMXホストではないサーバでは、サーバ証明書を使わずに匿名暗号だけを用いる設定をPostfix 2.3はサポートします。これは明示的に "smtpd_tls_cert_file = none" を設定し、smtpd_tls_dcert_file を設定しないことで有効になります。

例: (高いグレードの暗号を使うTLSを要求するMSA)

/etc/postfix/main.cf:
    smtpd_tls_cert_file = /etc/postfix/cert.pem
    smtpd_tls_key_file = /etc/postfix/key.pem
    smtpd_tls_mandatory_ciphers = high
    smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5
    # Postfix 2.3以降
    smtpd_tls_security_level = encrypt
    # 古いが、まだサポートされています
    smtpd_enforce_tls = yes

EDH で暗号を利用したければ、DH パラメータが必要です。1024bitおよび 512bit用のビルトインDHパラメータを使う代わりに、"独自の" パラメータを生成するのがよいでしょう。そうしないと、潜在的な攻撃者がみんなが使っているパラメータに対してブルートフォース攻撃を始めることに価値が出てしまいます。そのため、OpenSSLによってデフォルトで選ばれているパラメータは、他のTLSパッケージで配布されるものとはすでに異なっています。

自分自身の DH パラメータのセットを生成するには次のコマンドを使います:

% openssl gendh -out /etc/postfix/dh_1024.pem -2 -rand /var/run/egd-pool 1024
% openssl gendh -out /etc/postfix/dh_512.pem -2 -rand /var/run/egd-pool 512

例:

/etc/postfix/main.cf:
    smtpd_tls_dh1024_param_file = /etc/postfix/dh_1024.pem
    smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem

その他のサーバ制御

smtpd_starttls_timeout パラメータはTLSのハンドシェイク手順の開始から終了までの間にPostfix SMTP サーバが読み書きできる時間を制限します。

例:

/etc/postfix/main.cf:
    smtpd_starttls_timeout = 300s

SMTPクライアント特有の設定

このセクションがカバーしている話題

LMTP配送エージェントでのTLSサポート

Postfix 2.3では、smtp(8) および lmtp(8) 配送エージェントは1つの兼用プログラムに集約されています。結果的に、lmtp(8) 配送エージェントはより広く使われている smtp(8) の貧弱ないとこではなくなりました。Postfix 2.3では特に、それぞれのパラメータ名の "smtp_" プレフィックスを"lmtp_" に置き換えるだけで、以下に書かれているすべてのTLS機能がSMTPとLMTPに同じように適用されます。

LMTP配送エージェントはUNIXドメインソケットで待ち受けているLMTPサーバと通信することもできます。サーバ証明書の検証が有効になっていてサーバがUNIXドメインソケットで待ち受けていると、TLS検証の nexthop および hostname を設定するのに $myhostname パラメータが使われます。UNIXドメインソケット越しのLMTPトラフィックの日和見暗号化は意味がないことに注意してください。最低1つのサーバもしくはクライアントが相互に認証する必要がある場面においてのみTLSは有用です。クライアントとサーバの両者が対応しているのであれば、"null" 暗号グレードがこの場面では適切かもしれません。"null" 暗号は暗号化なしの認証を提供します。

クライアントサイドの証明書と秘密鍵の設定

もし1つ以上のサーバに対してクライアントTLS証明書を示さなければいけないのでなければ、クライアント証明書の設定はしないでください。クライアント証明書はたいていは必要なく、それがない環境でうまく動いている設定に問題を起こすかもしれません。推奨する設定は、デフォルトで設定されているようにすることです:

    smtp_tls_cert_file =
    smtp_tls_dcert_file =
    smtp_tls_key_file =
    smtp_tls_dkey_file =

デフォルト設定を使うのにもっともよい方法は、もし main.cf に上のパラメータがあれば、それをコメントアウトすることです。

TLS起動ネゴシエーションの間に、Postfix SMTPクライアントは証明書をリモートのSMTPサーバに渡すことができます。ここでNetscapeクライアントはより賢く、モートのSMTPサーバから示されたCA証明書にマッチするクライアント証明書だけの中からユーザに選択させます。Postfix SMTPクライアントはOpenSSL パッケージの "SSL_connect()" 関数を使うためそのような動作は不可能であり、ただ一つの証明書を選ぶ必要があります。そのため、ここで明示的に指定されない限り、今のところデフォルトでは証明書や鍵を_使いません_。

RSAおよびDSA証明書の両方がサポートされています。同時に両方持つことができ、その場合には使われる暗号によってどちらの証明書が出されるかが決まります。

Postfix SMTPクライアントはPostfix SMTPサーバと同じ鍵/証明書ペアを使うことができます。証明書を出す場合には、"PEM" フォーマットである必要があります。秘密鍵を暗号化してはいけません。つまり: パスワードなしでアクセスできなければいけません。両方の部品 (証明書と秘密鍵) は同じファイルに入れることもできます。

リモートSMTPサーバがPostfix SMTPクライアント証明書を検証するために、 CA証明書 (証明書チェーンの場合はすべてのCA証明書) が入手可能でなければいけません。これらの証明書をサーバ証明書に加えるとよいでしょう。その場合はクライアント証明書を最初にして、それから発行CAのものとします。

例: "client.example.com" の証明書がそれ自身 "ルートCA" である "intermediate CA" によって発行されました。次のように client.pem ファイルを作ります:

% cat client_cert.pem intermediate_CA.pem > client.pem

ここで与えられるPostfix SMTPクライアント証明書はSSLクライアント証明書として使えなければなりません。つまり "openssl verify -purpose sslclient ..." テストを通らなければいけません。

ルートCAを信頼しているサーバはルートCA証明書のローカルコピーを持っているため、ここにルートCA証明書を含めておく必要はありません。"client.pem" からそれを除いておくと、TLS交換のオーバーヘッドを減らせます。

これらのCAによって発行されたリモートSMTPサーバ証明書をPostfix SMTP クライアントが受け付けるようにしたければ、ルート証明書を $smtp_tls_CAfile に追記するか、$smtp_tls_CApath ディレクトリにインストールします。ルートCAの信頼を設定すると、$smtp_tls_scert_verifydepth が注目するサーバへの証明書チェーンにおけるCAの数よりも小さくなければ、ルートCAによって署名された中間CAを明示的に信頼する必要はありません。検証の深さを1とすると、信頼する CAによって直接署名された証明書のみを検証します。深さが2であれば、ルートCAもしくは直接の中間CA によって署名されたサーバを検証できます (サーバが中間CA証明書を提供するように正しく設定されている限り)。

RSA鍵と証明書の例:

/etc/postfix/main.cf:
    smtp_tls_cert_file = /etc/postfix/client.pem
    smtp_tls_key_file = $smtp_tls_cert_file

DSAで対応するもの:

/etc/postfix/main.cf:
    
smtp_tls_dcert_file = /etc/postfix/client-dsa.pem
    smtp_tls_dkey_file = $smtpd_tls_cert_file

リモートSMTPサーバ証明書を検証するには、Postfix SMTPクライアントは発行証明機関の証明書を信頼する必要があります。これらの "pem" 形式の証明書は単一ファイルの $smtp_tls_CAfile として保管するか、CA ごとに1ファイルとして複数ファイルを $smtp_tls_CApath ディレクトリに保存できます。ディレクトリを使うのであれば、以下のコマンドで "hash" リンクを作成するのを忘れないでください:

# $OPENSSL_HOME/bin/c_rehash /path/to/directory

$smtp_tls_CAfile は1つ以上の信頼したCAのCA証明書を含んでいます。このファイルはPostfixがオプションのchroot監獄に入る前に (root権限で) 開かれるため、chroot監獄からアクセスできる必要はありません。

信頼された他のCAは $smtp_tls_CApath ディレクトリを通して指定できますが、その場合証明書は ($mail_owner 権限で) 情報が必要なときにこのディレクトリのファイルから読み込まれます。そのため、$smtp_tls_CApath ディレクトリはオプションのchroot監獄の内部でアクセスできる必要があります。

$smtp_tls_CAfile と $smtpd_tls_CApath との選択は空間と時間のトレードオフです。信頼されたCAがたくさんある場合、すべてをあらかじめメモリに読み込むコストは証明書が必要となったときのアクセス時間が減っても報われないかもしれません。

例:

/etc/postfix/main.cf:
    smtp_tls_CAfile = /etc/postfix/CAcert.pem
    smtp_tls_CApath = /etc/postfix/certs

クライアントサイドTLS行動のロギング

Postfix SMTPクライアントのTLS行動に関してさらなる情報を得るために、ログレベルを0から4まで増加させることができます。それぞれのログレベルは下位のログレベルで記録される情報も含みます。

0 TLS行動に関するログ記録を無効にします。
1 TLSハンドシェイクと証明書の情報をログに記録します。
2 TLSネゴシエーションの間のレベルをログに記録します。
3 TLSネゴシエーションプロセスの16進数およびASCIIダンプをログに記録します。
4 STARTTLS以降の通信の16進数およびASCIIダンプを完全にログに記録します。

例:

/etc/postfix/main.cf:
    smtp_tls_loglevel = 0

クライアントサイドTLSセッションキャッシュ

リモートのSMTPサーバおよびPostfix SMTPクライアントがセッションのネゴシエーションをおこなうと、いくらか計算時間とネットワークのバンド幅を消費します。デフォルトでは、このセッションを実際に使っている smtp(8) プロセスでセッション情報はキャッシュされ、プロセスが終了するとセッション情報も失われます。セッション情報を複数の smtp(8) プロセスで共有するために、永続性セッションキャッシュが使えます。数キロバイトのオブジェクトを保存できて連続操作をサポートしている、どんなデータベース形式でも指定することができます。DBMデータベースは小さなオブジェクトしか保存できないため、これには適しません。キャッシュは tlsmgr(8) プロセスによって管理されるため、並列アクセスでも問題ありません。TLSセッションキーを繰り返しやりとりするのは負荷が高いため、セッションをキャッシュすることを強く推奨します。Postfix SMTP サーバは将来、1つのクライアントが単位時間あたりに交換できるセッションの数を制限することになるでしょう。

例:

/etc/postfix/main.cf:
    smtp_tls_session_cache_database = btree:/etc/postfix/smtp_scache

キャッシュされたPostfix SMTPクライアントセッション情報は一定の時間が経過すると失効します。Postfix/TLSはOpenSSLのデフォルトである300秒は使わず、もっと長い時間の3600秒 (=1時間) を使います。RFC 2246 は最大の24時間を推奨しています。

例:

/etc/postfix/main.cf:
    smtp_tls_session_cache_timeout = 3600s

クライアントTLS制限

TLS通信チャネルのセキュリティ属性はアプリケーションに特有のものです。TLSプロトコルはクライアントとサーバの間の機密性、耐タンパー性、相互に認証されたチャネルを提供しますが、これらすべてのセキュリティ機能がすべての通信で使えるわけではありません。

例えば、ブラウザとWebサーバ間での相互TLS認証は可能ですが、webサーバが公共サービスですべての潜在的ユーザの身元を検証するのは、実用的でなかったり不便でさえあったりします。実際には、ほとんどのHTTP処理は非対称です: ブラウザはHTTPSサーバの身元を検証しますが、ユーザは匿名のままです。セキュリティポリシーの多くはクライアント次第です。クライアントがサーバの名前を検証しないと決めても、サーバはそれを気にしません。興味深いブラウザセキュリティの話題はたくさんありますが、ここでこだわるべきではありません。むしろわれわれの目的はSMTPと連動するTLSの機能を理解することです。

特にSMTPで見られる重要なことは、公のMXホストはHTTPSサーバよりもずっとSMTPクライアントに翻弄されるということです。SMTPクライアントでのTLSサポートはまだルールというよりも例外なので、クライアントがTLSを使うことで十分に注意を払うよう強制できないだけではなく、TLSを強制することさえもできません。実際問題として、TLSが有効になったクライアントだけにMXホストへのアクセスを制限することはできません。そのようなポリシーは広い世界でemailで通信できるという 能力を大幅に減らしてしまうでしょう。

特定の送信組織からのメールにTLSを強制しようとしたくなるかもしれませんが、これも行き詰ってしまいます。問題のひとつに、"MAIL FROM:" SMTPコマンドを見るまでは (自己申告で) 誰がメールを送っているかわからず、その時点で既にまだTLSが使われていなければ、秘匿すべきかもしれない送信者アドレス (や、SMTP PIPELININGを使っていると1人以上の受信者) が平文でもれてしまうというものです。他にも、送信者から受信者へのメールが転送されるかもしれず、その転送する組織と最終配送先とは何のセキュリティ調整も行われていないかもしれないという問題もあります。バウンスにも保護が必要です。これらはIPアドレスや接続クライアントのHELO名でのみ識別できますが、送信側組織で外行きemailサーバが可能性のあるIPアドレスやHELO名を追跡し続けるというのは困難です。

結果として、公開されたMXホストへのメール配送に関するTLSセキュリティはほぼ完全にクライアントの責任です。HTTPSとは逆に、サーバは主としてTLSセキュリティを受動的に有効にするだけで、残りはクライアントに任されます。サーバが信頼するクライアントからの外行きメールだけを扱う専用のMSAの場合はサーバはクライアントセキュリティポリシーを指図するより大きな機会を得ますが、以下ではクライアントセキュリティポリシーに焦点を当てます。

SMTPクライアントには、より複雑な点があります。HTTPSとは違って与えられたドメインにメールを配送する際に、SMTPセッションの目的ホストとして直接ドメイン名を使うことはほとんどありません。より一般的にいうと、ドメインのSMTPサーバホスト名を得るのにMX検索を使います - これらはたいてい認証されていません。現状では、クライアントがセキュアではない方法で得たMXホスト名を検証すると、DNS中間者攻撃を受ける可能性があります。

クライアントが受信者ドメイン名を検証しようとすると、複数のドメインを持つSMTPサーバは証明書にそのeメールドメイン名すべてをリストアップする必要があり、新しいドメインが追加されるたびに新しい証明書を作る必要があります。少なくともいくつかのCAでは、サーバ証明書が持てる名前の数がかなり低く (ある有名なCAでは20) 制限されています。このアプローチは現状には合わず、また拡張もできません。

残念ながら、TLS セキュアチャネル (完全に認証され、中間者攻撃に免疫がある) では送信側および受信側サイトをどこにでも配置することはできなくなるという制限がかけられます。それぞれの配送先ドメインに対して手動でこの種の設定をおこなう必要があり、また多くの場合、セキュアにされた共通の配送先にホスティングされる追加ドメインに対して、デフォルトではないTLSポリシーテーブルエントリを実装する必要があります。Postfix 2.3ではかなり簡単にセキュアチャネルが設定できるようになりましたが、それらは標準にはならないでしょう。特定のセキュリティ調整をおこなわない一般的などメインでは、このセキュリティレベルはあまり合いません。

一般には強い認証は可能ではなく、検証可能な証明書は時間と費用がかかるため、TLSを実装している多くのサーバが自己署名証明書やプライベートCAを使っています。このことは公共のインターネットでの検証されたTLSの適用をさらに制限してしまいます。

歴史的な注意: これらの問題や関連する多くの機能に関するドキュメントはPostfix 2.3で新しく書かれたものですが、この問題はPostfix 1.0以前にLutz Jeanickeが最初の非公式パッチを設計した時からよく理解されています。彼の最初の投稿 http://www.imc.org/ietf-apps-tls/mail-archive/msg00304.html や最初の応答 http://www.imc.org/ietf-apps-tls/mail-archive/msg00305.html を参照してください。問題はSMTPやTLSに特徴的なものではなく、同じような問題はHTTPSやKerberosのエイリアスを使ったセキュアな接続にもあります。SMTPは単に (MXレコードを通した) 間接的なネーミングをより頻繁に使うだけです。

クライアントTLSセキュリティレベル

以下に列挙したTLSセキュリティレベルは次のセクションで詳細に記述されています。

なし
TLSを使わない。
may
日和見TLS。
encrypt
TLS暗号化の強制。
verify
サーバ証明書の検証を強制。
secure
セキュアチャネルTLS。

SMTP/LMTPクライアントでTLSを無効にする

"none" TLSセキュリティレベルでは、TLS暗号化は無効になります。これがデフォルトのセキュリティレベルです。Postfix 2.3以降では、"smtp_tls_security_level = none" を設定することで明示的に設定可能です。

Postfix 2.2以前、もしくは smtp_tls_security_level が (後方互換である) デフォルトの空値に設定されている場合、適切な設定は "smtp_use_tls = no" および "smtp_enforce_tls = no" です。どちらの方法でも、TLSはサーバがサポートしていても使われません。LMTPに対しては、対応する "LMTP_" パラメータを使ってください。

配送先ごとの設定はこのデフォルト設定を上書きします。その場合、明示的にTLSの設定がされた配送先に対してのみ、TLSは選択的に使われます。

配送先のサブセットに対してTLSを無効にし、その他を有効にしたままにすることもできます。Postfix 2.3+ TLSポリシーテーブルでは、"none" セキュリティレベルを指定します。古い、サイトごとのテーブルでは、"NONE" キーワードを指定します。

日和見TLS

"may" TLSセキュリティレベルでは、TLS暗号化は日和見主義になります。サーバがSTARTTLS ESMTP機能をサポートしていると、SMTPトランザクションは暗号化されます。そうでなければ、メッセージは平文で送られます。Postfix 2.3以降では、日和見TLSは "smtp_tls_security_level = may" をセットすることで設定可能です。

平文での送信が受け入れられるため、デフォルトのTLSセキュリティよりも強いものを要求するのは互換性を下げるだけです。このため、Postfix 2.3以降では "may" セキュリティレベルの時には smtp_tls_mandatory_ciphers および smtp_tls_mandatory_protocols パラメータを無視します: すべてのプロトコルが許可され、"export" グレード以上の暗号が使われます。

Postfix 2.2以前、もしくは smtp_tls_security_level がデフォルト (後方互換) の空値にセットされている場合は、 "smtp_use_tls = yes" および "smtp_enforce_tls = no" が適切な設定です。LMTPでは対応する "lmtp_" パラメータを使います。

日和見TLSでは、サーバ証明書が信用できなかったり間違った名前を持っていてもメール配送を続けます。Postfix 2.3からは、日和見TLSセッションに対するTLSハンドシェイクが失敗しても、メール配送を諦めるのではなく、TLSを無効にして処理を再試行します。暗号化しない接続を試すことで、サーバTLSの実装が非互換なサイトへのメール配送が可能となります。

日和見暗号化はUNIXドメインソケットを使ったLMTPでは使われません。通信チャネルはTLSがなくても秘匿化されており、TLSの意味があるとしたら認証だけです。UNIXドメインソケットを使ったLMTPに対して日和見TLSを設定しないでください。encrypt セキュリティレベル以上でのみ、UNIXドメインソケットを使ったLMTP配送にTLSを設定してください。LMTPセッションの日和見暗号化を設定しようとしても、無視されて警告がメールログに記録されます。

選択した配送先にのみ日和見TLSを有効にすることもできます。Postfix 2.3+のTLSポリシーテーブルで、"may" セキュリティレベルを指定します。古い、サイトごとのテーブルでは、"MAY" キーワードを指定します。

これがTLSで保護されたSMTPセッションで最も一般的なセキュリティレベルです。これより強いセキュリティレベルは一般的には使えず、必要ならばたいていは配送先ごとで設定します。上のTLS制限のセクションを参照してください。

例:

/etc/postfix/main.cf:
    smtp_tls_security_level = may

Postfix 2.2の文法:

/etc/postfix/main.cf:
    smtp_use_tls = yes
    smtp_enforce_tls = no

TLS暗号化の強制

"encrypt" TLSセキュリティレベルでは、メッセージは暗号化TLSセッションを使わないと送れません。サーバが STARTTLS ESMTP 機能をサポートしていないと、 SMTPトランザクションは中断されます。適切なサーバが見つからないと、メッセージは遅延されます。Postfix 2.3以降では、TLS暗号化の強制は "smtp_tls_security_level = encrypt" をセットすることで設定できます。TLS暗号化は常に使われますが、サーバ証明書が信頼できなかったり間違った名前を持っていてもメール配送は続けられます。

このセキュリティレベル以上では、smtp_tls_mandatory_protocols および smtp_tls_mandatory_ciphers 設定パラメータが十分な安全性を持つSSLプロトコルバージョンのリストや最低限の暗号強度を決定します。プロトコルや暗号の要求が合わないと、メールの処理は中断されます。これらのパラメータのドキュメントには互換性やセキュリティガイドラインの有益な情報が含まれます。

Postfix 2.2以前、もしくは smtp_tls_security_level がデフォルト (後方互換) の空値にセットされている場合は、 "smtp_enforce_tls = yes" および "smtp_tls_enforce_peername = no" が適切な設定です。LMTPでは対応する "lmtp_" パラメータを使います。

受動的な盗聴攻撃をできなくすることは可能ですが、TLS暗号化の強制は公共のインターネットにメールを配送するためのデフォルトのセキュリティレベルとしては使えません。とんどのMXホストはTLSを全くサポートしておらず、壊れたTLSをサポートしているものもあります。インターネットにメールを配送するホストでは、デフォルトのセキュリティレベルとしてTLS暗号化の強制を設定すべきではありません。

特定の配送先にのみTLS暗号化の強制を有効にすることもできます。Postfix 2.3+ のTLSポリシーテーブルでは、"encrypt" セキュリティレベルを指定します。古い、サイトごとのテーブルでは、"MUST_NOPEERMATCH" キーワードを指定します。Postfix 2.3でも古い方法は使えますが、全くお勧めしません: Postfix 2.3+ のユーザは新しいTLSポリシー設定を使うべきです。

例:

以下の例では、example.com およびそのサブドメインへのトラフィックで、対応するMXホストを通るものは常にTLSを使います。プロトコルバージョンは "SSLv3" もしくは "TLSv1" です (smtp_tls_mandatory_protocols のデフォルト設定では "SSLv2" を除外しています)。デフォルトでは high または middle 強度 (つまり128ビット以上) の暗号が全ての "encrypt" セキュリティレベルセッションで使われます。

/etc/postfix/main.cf:
    smtp_tls_policy_maps = hash:/etc/postfix/tls_policy

/etc/postfix/tls_policy:
    example.com       encrypt
    .example.com      encrypt

Postfix 2.2の文法 (regexp テーブルを使わずにサブドメインを指定できません)。Postfix 2.3+では、古い、サイトごとのテーブルを使わないでください。

/etc/postfix/main.cf:
    smtp_tls_per_site = hash:/etc/postfix/tls_per_site

/etc/postfix/tls_per_site:
    example.com       MUST_NOPEERMATCH

次の例では、セキュアなメッセージ投函が MSA "[example.net]:587" を通るように設定しています。このMSAは受け入れ可能な証明書を持っていないため、TLS セッションは認証なしで暗号化されます。このMSAは "TLSv1" と "high" グレードの暗号が使えることがわかっており、これらはポリシーテーブルで選択されています。

注意: ポリシーテーブルの検索キーは受信者ドメインや transport(5) テーブル、relayhost パラメータから特定される next-hop を四角カッコで括ったものとオプションのポートです。一貫性が保たれるように注意してください: nexthop 指定としては機能的に等価なものであったとしても、":smtp" や ":25" がついているもの、ポートサフィックスがついていないものはそれぞれポリシーテーブルの検索キーが異なってしまいます。対して多くともこれらのうち1つの形式を使ってください。以下では、ポリシーテーブルは複数のキーを持っていますが、ここでは transport テーブルのエントリは一貫した指定はなされていません。

/etc/postfix/main.cf:
    smtp_tls_policy_maps = hash:/etc/postfix/tls_policy

/etc/services:
    submission      587/tcp         msa             # mail message submission

/etc/postfix/tls_policy:
    [example.net]:587 encrypt protocols=TLSv1 ciphers=high
    [example.net]:msa encrypt protocols=TLSv1 ciphers=high
    [example.net]:submission encrypt protocols=TLSv1 ciphers=high

Postfix 2.2の文法:

注意: 生のホスト名 (例えば "example.net") でのポリシー検索は避けてください。代わりに、サイトごとの テーブル検索キーとして配送先 (例えば "[example.net]:587") を指定してください (ポートサフィックスがない受信者ドメインや MX が有効になった transport nexthop は生のホスト名に似ていますが、それらは適した配送先です)。Postfix 2.3+では、古い、サイトごとのテーブルを使わないでください; 代わりに新しいポリシーテーブルを使ってください。

/etc/postfix/main.cf:
    smtp_tls_per_site = hash:/etc/postfix/tls_per_site

/etc/postfix/tls_per_site:
    [example.net]:587   MUST_NOPEERMATCH

サーバ証明書の検証を強制する

"verify" セキュリティレベルでは、サーバ証明書が有効 (期限切れになったり無効になっておらず、信頼された認証局によって認証されたもの) であり、サーバ証明書名が既知のパターンにマッチする場合、メッセージはTLS暗号化セッションを使ってのみ送られます。サーバ証明書の検証を強制するには、"smtp_tls_security_level = verify" をセットすることで設定できます。smtp_tls_verify_cert_match パラメータはデフォルトの "hostname" 証明書名マッチングの戦略を上書きできます。マッチング戦略を微調整するのは、たいていはセキュアチャネルの配送先にのみ適しています。

Postfix 2.2以前、もしくは smtp_tls_security_level がデフォルト (後方互換) の空値にセットされている場合は、 "smtp_enforce_tls = yes" および "smtp_tls_enforce_peername = yes" が適切な設定です。LMTPでは対応する "lmtp_" パラメータを使います。

サーバ証明書チェーンが信頼されていると (smtp_tls_CAfile および smtp_tls_CApath を参照)、SubjectAlternativeName 拡張のDNS名がサーバ名を検証するのに使われます。DNS名が指定されていないと、証明書の CommonName がチェックされます。サーバ証明書を検証せずに暗号化を強制したいのであれば、上を参照してください。

"中間者 (man-in-the-middle)" 攻撃や他の攻撃を減らす可能性はありますが、証明書の信頼チェーンやサブジェクト名検証の強制はデフォルトのインターネットメール配送ポリシーとしては有効になっていません。ほとんどのMXホストはTLSを全くサポートしておらず、TLSが有効になったMTAのかなりの割合が自己署名証明書を使っているか、プライベート認証局によって署名された証明書を使っています。インターネットにメールを配信するマシンでは、デフォルトのポリシーとしてサーバ証明書検証を強制するように設定すべきではありません。

RFC 2487 をサポートし、かつ、検証可能なサーバ証明書を提供するサーバのみに接続することがわかっているのであれば、デフォルトのセキュリティレベルとしてサーバ証明書検証を強制するのが適切かもしれません。必要なSTARTTLSをサポートしている中央メールハブに全てのメールを送るクライアントというのがその例です。そのような場合、代わりにセキュアチャネル設定を使うこともよくあります。

特定の配送先にのみサーバ証明書検証の強制を有効にすることもできます。Postfix 2.3+のTLSポリシーテーブルでは、"verify" セキュリティレベルを指定します。古い、サイトごとのテーブルでは、"MUST" キーワードを指定します。Postfix 2.3でも古い方法は使えますが、全くお勧めしません: Postfix 2.3+ のユーザは新しいTLSポリシー設定を使うべきです。

例:

この例では、クライアントは example.com ドメインへの全てのトラフィックを暗号化します。peerホスト名が検証されますが、検証はDNS応答の偽装に対して脆弱です。example.com の受信者へのメール送信は "high" グレードの暗号を使います。

/etc/postfix/main.cf:
    indexed = ${default_database_type}:${config_directory}/
    smtp_tls_CAfile = ${config_directory}/CAfile.pem
    smtp_tls_policy_maps = ${indexed}tls_policy

/etc/postfix/tls_policy:
    example.com       verify ciphers=high

Postfix 2.2の文法:

/etc/postfix/main.cf:
    indexed = ${default_database_type}:${config_directory}/
    smtp_tls_CAfile = ${config_directory}/CAfile.pem
    smtp_tls_per_site = ${indexed}tls_per_site

/etc/postfix/tls_per_site:
    example.com         MUST

セキュアサーバ証明書の検証

secure TLSセキュリティレベルでは、DNS偽装に耐性を持つサーバ証明書の検証が成功したセキュリティチャネルTLS セッションを使ってのみ、メッセージは送られます。適切なサーバが見つからないと、メッセージは遅延されます。Postfix 2.3以降では、セキュアチャネルは "smtp_tls_security_level = secure" をセットすることで設定できます。smtp_tls_secure_cert_match パラメータはデフォルトの "nexthop, dot-nexthop" 証明書マッチング戦略を上書きできます。

Postfix 2.2以前、もしくは smtp_tls_security_level がデフォルト (後方互換) の 空値にセットされている場合は、 "smtp_enforce_tls = yes" および "smtp_tls_enforce_peername = yes" 加えて、偽装されたDNSデータに対してpeer証明書検証を強化するように設定するのが適切な設定です。LMTPに対しては、対応する "LMTP_" パラメータを使ってください。

サーバ証明書チェーンが信頼されていると (smtp_tls_CAfile および smtp_tls_CApath を参照)、SubjectAlternativeName 拡張のDNS名がサーバ名を検証するのに使われます。DNS名が指定されていないと、証明書の CommonName がチェックされます。サーバ証明書を検証せずに暗号化を強制したいのであれば、上を参照してください。

"中間者 (man-in-the-middle)" 攻撃や他の攻撃を減らす可能性はありますが、証明書の信頼チェーンやサブジェクト名検証の強制はデフォルトのインターネットメール配送ポリシーとしては有効になっていません。ほとんどのMXホストはTLSを全くサポートしておらず、TLSが有効になったMTAのかなりの割合が自己署名証明書を使っているか、プライベート認証局によって署名された証明書を使っています。インターネットにメールを配信するマシンでは、デフォルトのポリシーとしてサーバ証明書検証を強制するように設定すべきではありません。

RFC 2487 をサポートし、かつ、検証可能なサーバ証明書を提供するサーバのみに接続することがわかっているのであれば、デフォルトのセキュリティレベルとしてサーバ証明書検証を強制するのが適切かもしれません。必要なSTARTTLSをサポートしている中央メールハブに全てのメールを送るクライアントというのがその例です。

特定の配送先にのみセキュアサーバ証明書検証を有効にすることもできます。Postfix 2.3+のTLSポリシーテーブルでは、"secure" セキュリティレベルを指定します。古い、サイトごとのでは、"MUST" キーワードを指定して、DNS偽装に対して証明書の検証を強化します。Postfix 2.3でも古い方法は使えますが、全くお勧めしません: Postfix 2.3+ のユーザは新しいTLSポリシー設定を使うべきです。

例:

transport(5) テーブルを上書きしないセキュアチャネル:

クライアントはすべてのトラフィックを暗号化し、DNS応答の偽装から確実に配送先名を保護します。MX検索は example.com のSMTPサーバを探すのに使われますが、サーバ証明書の名前を確認する際には使われません。それよりも、example.com のMXホストが example.com という対象の名前もしくはそのサブドメイン名の、信頼された証明書を持っていることが要求されます。smtp_tls_secure_cert_match パラメータについてのドキュメントを参照してください。

関連するドメイン example.co.uk および example.co.jp はプライマリドメインである example.com ドメインと同じMXホストに同居しており、これらへのトラフィックはサーバ証明書内の example.com ドメインを検証することでセキュアになります。これにより、サーバ管理者はCAにすべてのセカンダリドメインをリストアップした証明書に署名させなくてもすむようになります。これの問題は、セカンダリドメインにセキュアチャネルを張ろうとするクライアントはTLSポリシーテーブルのエントリを明示する必要があるということです。

関連ドメインを扱うのに2つの方法があることに注意してください。1つ目はそれぞれのドメインに対してデフォルトのルーティングを使い、期待される証明書の対象名を上書きするためにポリシーテーブルのエントリを加える方法です。2つ目は transport テーブルのnext-hopを上書きし、共通のnexthopに対する1つのポリシーテーブルエントリを使う方法です。ここでは、ドメインの所有者が変更しても問題ないことから、1つ目の方法を選択します。2つ目の方法では間違った配送先に対して安全にメールを配送してしまいますが、最初の方法だと認証が失敗してメールはローカルのキューにとどまります。ほとんどの場合は1つ目の方法のほうがより適切です。

/etc/postfix/main.cf:
    smtp_tls_CAfile = /etc/postfix/CAfile.pem
    smtp_tls_policy_maps = hash:/etc/postfix/tls_policy

/etc/postfix/transport:

/etc/postfix/tls_policy:
    example.com     secure
    example.co.uk   secure match=example.com:.example.com
    example.co.jp   secure match=example.com:.example.com

transport(5) テーブルを上書きするセキュアチャネル:

この場合、example.com や関連するドメインへのトラフィックは1つの論理的ゲートウェイに送られます (単一点障害を避けるため、その名前は1つ以上のロードバランサアドレスや、複数の物理的ホストを1つにしたアドレスに解決されるかもしれません)。ゲートウェイのIPアドレスで到達可能な物理的ホスト全ての証明書に、その論理ゲートウェイ名がリストアップされています。このセキュアチャネルの設定は、古い、サイトごとのテーブルの MUST ポリシーを強化したものを使っても実装できます。上で述べたように、この方法は関連ドメインの持ち主が変わるとメールが間違って配送される可能性があります。

/etc/postfix/main.cf:
    smtp_tls_CAfile = /etc/postfix/CAfile.pem
    transport_maps = hash:/etc/postfix/transport
    smtp_tls_policy_maps = hash:/etc/postfix/tls_policy

/etc/postfix/transport:
    example.com     smtp:[tls.example.com]
    example.co.uk   smtp:[tls.example.com]
    example.co.jp   smtp:[tls.example.com]

/etc/postfix/tls_policy:
    [tls.example.com] secure match=tls.example.com

Postfix 2.2.9+の文法:

注意: 生のホスト名 (例えば "tls.example.com") でポリシーを検索するのは避けてください。代わりに、サイトごとのテーブル検索キーとして配送先 (例えば "[tls.example.com]") を使ってください (ポートサフィックスのない受信者ドメインやMXが有効となった transport nexthopは生のホスト名に見えるかも知れませんが、それらは配送先として適したものです)。Postfix 2.3+では、古い、サイトごとのテーブルを使わないでください; 代わりに新しいポリシーテーブルを使ってください。

/etc/postfix/main.cf:
    smtp_cname_overrides_servername = no
    smtp_tls_CAfile = /etc/postfix/CAfile.pem
    transport_maps = hash:/etc/postfix/transport
    smtp_tls_per_site = hash:/etc/postfix/tls_per_site

/etc/postfix/transport:
    example.com     smtp:[tls.example.com]
    example.co.uk   smtp:[tls.example.com]
    example.co.jp   smtp:[tls.example.com]

/etc/postfix/tls_per_site:
    [tls.example.com]       MUST

TLSポリシーテーブル

Postfix 2.3は、より柔軟な新しいTLSポリシーテーブルを導入しました。以前のリリースについては、古い、Postfix 2.2のサイトごとのテーブルについての記述を読んでください。

一部少数のサーバはSTARTTLSを提供しますが、常にネゴシエーションに失敗します。Postfix 2.3では、暗号化が強制されない限り、すぐにTLSを無効にして配送を再試行します。問題の配送先に対して明示的にTLSを無効にする必要はなくなりました。配送先のソフトウェアや設定が修正されると、すぐに暗号化が使えるようになります。

新しいポリシーテーブルは smtp_tls_policy_maps パラメータを使って指定します。これはnext-hop配送先ごとのPostfix SMTPクライアントTLSセキュリティポリシーを持つオプションの検索テーブルをリストアップします。$smtp_tls_policy_maps が空でなければ、古い smtp_tls_per_site パラメータは無視されます (両方のパラメータの値が入っていると警告がログに記録されます)。

受信者ドメインもしくは transport テーブル、$local_transport、$virtual_transport、$relay_transport、$default_transport で指定されたnext-hop配送先全体で、TLSポリシーテーブルはインデックス化されます。これには四角カッコで括られたものや非デフォルト配送先サーバポートサフィックスを含みます。LMTP ソケット形式プレフィックス (inet: や unix:) は検索キーには含みません。

next-hopドメイン、もしくはUNIXドメインソケットを使ったLMTPでの $myhostname だけが証明書検証の nexthop 名として使われます。ポートおよび四角カッコは検索キーとして使われますが、サーバ名検証には使われません。

検索キーが四角カッコや :port サフィックスのないドメイン名 (通常は受信者ドメイン) で、完全なドメインがテーブルでは見つからない場合は、transport(5) テーブルの場合と同様に "." で始まる親ドメインが再帰的にマッチします。これにより、ある受信者ドメインとそのサブドメイン全てに対するセキュリティポリシーを指定できるようになります。

検索結果はセキュリティレベルですが、関連する main.cf 設定を上書きする、空白やカンマで区切られた name=value 属性もオプションで続けることができます。TLSセキュリティレベルは上で記述しています。以下、対応するテーブルの文法を記述します:

なし
TLSを使わない。このレベルでは追加属性はサポートされません。
may
日和見TLS。このレベルでは追加属性はサポートされません。
encrypt
TLS暗号化の強制。リモートSMTPサーバがSTARTTLSを提供し、TLSハンドシェイクが成功した場合にのみ、メールが配送されます。このレベル以上では、"ciphers" 属性が main.cf smtp_tls_mandatory_ciphers パラメータを、"protocols" キーワードが main.cf smtp_tls_mandatory_protocols パラメータをそれぞれオプションで上書きします。
verify
サーバ証明書の検証を強制。TLSハンドシェイクが成功し、サーバ証明書が検証され (期限切れや無効になっておらず、信頼された認証局によって署名されている)、サーバ証明書名がオプションの "match" 属性 (オプションの "match" 属性が指定されていない場合は main.cf smtp_tls_verify_cert_match パラメータ) にマッチしている場合にのみ、メールが配送されます。
secure
セキュアチャネルTLS。TLSハンドシェイクが成功し、サーバ証明書が検証され (期限切れや無効になっておらず、信頼された認証局によって署名されている)、サーバ証明書名がオプションの "match" 属性 (オプションの "match" 属性が指定されていない場合は main.cf smtp_tls_secure_cert_match パラメータ) にマッチしている場合にのみ、メールが配送されます。

注意:

例:

/etc/postfix/main.cf:
    smtp_tls_policy_maps = hash:/etc/postfix/tls_policy

/etc/postfix/tls_policy:
    example.edu             none
    example.mil             may
    example.gov             encrypt protocols=SSLv3:TLSv1 ciphers=high
    example.com             verify     
            match=hostname:dot-nexthop protocols=SSLv3:TLSv1 ciphers=high
    example.net             secure
    .example.net            secure match=.example.net:example.net
    [mail.example.org]:587  secure match=nexthop

注意: "hostname" 戦略が smtp_tls_secure_cert_match の非デフォルト設定やポリシーテーブルの "match" 属性に書かれていると、DNS偽装に対する "secure" レベルの脆弱性となってしまう可能性があります。secure-channel に対する "hostname" 戦略を DNSセキュリティが保障されていない環境で使わないでください。

古い、サイトごとのTLSポリシーのサポート

このセクションは、古い、サイトごとのTLSポリシーメカニズムについて記述しています。Postfix 2.3ポリシーテーブルメカニズムとは違い、これはポリシー検索のキーとして信頼できないサーバホスト名を使い、またサーバ証明書に現れることができる名前について制御できません。このため、古いメカニズムはMXやCNAMEレコード情報の誤ったDNSホスト名に対して、たいていは脆弱です。これらの攻撃を減らすのはかなり困難です。新しいポリシーテーブルはセキュアチャネル設定を容易にし、セッションの暗号化を強制することで暗号やプロトコルの選択をより制御しやすくなります。

生のホスト名でポリシー検索するのは避けてください。代わりに、完全な配送先nexthop ([] でくくり、できれば ":port" サフィックスをつけて) をサイトごとのテーブル検索キーとして使ってください (ポートサフィックスのない受信者ドメインやMXが有効になった transport nexthopは生のホスト名のように見えますが、これらは配送先として適しています)。Postfix 2.3+では、ここに書かれた古い方法の利用は全くお勧めしません: 代わりに新しいポリシーテーブルを使ってください。

Postfix 2.3からは、基礎となるTLSの強制レベルは古い、サイトごとのテーブルと新しいポリシーテーブルで共通です。main.cf smtp_tls_mandatory_ciphers および smtp_tls_mandatory_protocols パラメータは、どのテーブルが使われるかにかかわらず、必要な暗号化に対してTLS暗号化およびプロトコルを制御します。smtp_tls_verify_cert_match パラメータは新しいポリシーの "verify" レベルと同じような方法で、古い "MUST" キーワードに対してマッチング戦略を決定します。

Postfix < 2.3では、古い smtp_tls_cipherlist パラメータも日和見TLSセッションに適用されるため、注意して使うか全く使わないようにすべきです。リモートSMTPサーバと互換性のない暗号リスト制限をセットすると、そのサーバに到達できなくなり、TLSハンドシェイクは毎回試行されて毎回失敗することになります。

smtp_tls_policy_maps が空 (デフォルト) で smtp_tls_per_site 空でないと、サイトごとのテーブルで以下の情報にマッチするポリシーを検索します:

リモートSMTPサーバホスト名
これはPostfix SMTPクライアントが接続しようとするサーバの、単なるDNS名です; この名前はMX検索やCNAME検索など、他のDNS検索から得られるものかもしれません。ホスト名検索キーの利用はお勧めできません; 常に next-hop 配送先を代わりに使ってください。
next-hop配送先
これは単に受信者アドレスのドメイン部分ですが、transport(5) テーブルや relayhost パラメータ設定、relay_transport 設定の情報で上書きされるかもしれません。それが受信者ドメインではない場合、next-hop 配送先は Postfix特有の形式、"[name]" や [name]:port"、"name"、"name:port" を持つことができます。サイトごとのポリシー検索 (さらにSASLパスワード検索) に対しては、これが推奨される検索キーです。

ホスト名検索とnext-hop検索の両方が成功した場合、ホストポリシーは自動的には next-hopポリシーを上書きしません。以下に示すような、より特定された、もしくはより安全なサイトごとのポリシーが代わりに優先されます。

smtp_tls_per_site テーブルは単純な "name whitespace value" 形式を使います。左側にはホスト名または next-hop配送先を指定します; ワイルドカードは使えません。右側部分には以下のキーワードのいずれか1つを指定します:

NONE
TLSを使わない。これは代替ホストやnext-hop 検索キーからの、"MAY" という指定が弱い検索結果、およびグローバルな smtp_use_tls もしくは smtp_enforce_tls、smtp_tls_enforce_peername 設定を上書きします。
MAY
日和見TLS。これは代替ホストや next-hop検索キーからの、より強く特定された結果 ("NONE" を含む) およびより特定されたグローバルの "smtp_enforce_tls = yes" もしくは "smtp_tls_enforce_peername = yes" よりも低い優先度を持ちます。
MUST_NOPEERMATCH
TLS暗号化の強制。これは代替ホストやnext-hop検索キーからの、安全性が弱い "NONE" や特定度の弱い "MAY" といった検索結果、およびグローバルな smtp_use_tls や smtp_enforce_tls 、smtp_tls_enforce_peername 設定を上書きします。
MUST
サーバ証明書の検証を強制。これは代替ホストや next-hop検索キーからの、安全性が弱い "NONE" や "MUST_NOPEERMATCH"、および特定度の弱い "MAY" といった検索結果、グローバルな smtp_use_tls や smtp_enforce_tls、smtp_tls_enforce_peername 設定を上書きします。

グローバル (main.cf) TLSポリシーとサイトごとのTLSポリシーの間の優先度は以下のようにまとめられます:

古い、サイトごとのTLSポリシーでDNSの抜け穴を閉じる

SMTPに対するTLSセキュリティの一般的な議論は、上の TLS制限 を参照してください。以下に続くのはPostfix 2.2.9およびそれ以降のPostfix 2.2パッチレベルにのみ適用されます。この方法をPostfix 2.3+で使わないでください; 代わりにセキュアなサーバ証明書検証以下の記述を参照してください。

安全なDNS検索メカニズムが使えない限り、MX応答やCNAME応答でのホスト名が間違っていると、TLSポリシー検索やサーバ証明書の検証で使うホスト名が変わってしまいます。サーバホスト名とサーバ証明書が完全にマッチしていたとしても、Postfixが正しいサーバに接続されたかどうかは保証できません。この抜け穴を避けるため、以下の全てのステップに従ってください:

  1. 下に示すように、専用のメッセージ配送transport (例えば "securetls") を使います。

  2. MX検索を止めます。慎重を期すべきドメインに対してローカル transport(5) テーブルに明示的に securetls:[mailhost] もしくは securetls:[mailhost]:port 配送先というエントリを指定します (DNSとは異なりこのテーブルのセキュリティを保証できます)。これによりDNS MXレコードで間違ったホスト名情報があっても、TLSポリシー検索やサーバ証明書の検証で使われる、Postfixが持つホスト名が変わってしまうことがなくなります。"securetls" transport はピア名検証つきTLSを強制し、smtp_tls_per_site ポリシーの強制に干渉しうるSMTP接続キャッシュを無効にするように設定されます。

  3. CNAMEによるホスト名の上書きを禁止します。main.cfで "smtp_cname_overrides_servername = no" を指定します。これによりDNS CNAMEレコードで間違った情報があっても、Postfixが TLSポリシー検索やサーバ証明書の検証で使うホスト名が変わってしまうことがなくなります。この機能を使うには、Postfix 2.2.9以降が必要です。Postfix 2.3からのデフォルト値は "no" です。

例:

非デフォルトの "securetls" transport に明示的に master.cf プロセス制限を課することで、$default_process_limit を増やしても、その制限を増やす必要はありません。*全ての* transportの合計プロセス数の制限は1024以下の値 (たいていは select() ファイルディスクリプタ制限) にとどめるべきです; そうしないと、transport は定常的に負荷が高く、混雑した状態で遅くなるかもしれません。大規模なサイトではデフォルトプロセス制限を500以上にすることもよくあります。

また、セキュアチャネル配送先に対するサイトごとのテーブルエントリの必要をなくすため、"securetls" transport TLSセキュリティレベルのデフォルトも MUST にします。

/etc/postfix/main.cf:
    transport_maps = hash:/etc/postfix/transport

/etc/postfix/transport:
    example.com         securetls:[tls.example.com]

/etc/postfix/master.cf:
    securetls unix  -       -       n       -       100     smtp
        -o smtp_enforce_tls=yes
        -o smtp_tls_enforce_peername=yes

TLSをサポートしているサーバを見つける

TLSを使う使わないに関わらず "サイト単位" ベースとすることに決めたため、 "STARTTLS" を提供するサイトのリストを持つのに適しています。このオプションで自分自身で集めることができます。

smtp_tls_note_starttls_offer 機能が有効になっていてサーバが STARTTLS を提供しており、そのサーバに対してすでにTLSが有効になっているのでなければ、 Postfix SMTPクライアントは以下のような行をログに残します:

postfix/smtp[pid]: Host offered STARTTLS: [hostname.example.com]

例:

/etc/postfix/main.cf:
    smtp_tls_note_starttls_offer = yes

サーバ証明書検証の深さ

リモートSMTPサーバ証明書を検証する際、smtp_tls_CAfile または smtp_tls_CApath で指定されたCAによって直接発行された証明書の場合、検証の深さは1で十分です。デフォルト値 (5) はより長いチェーンでも十分な値です (ルートCAが実際に証明書を発行する特別なCA証明書を発行するような場合)。

例:

/etc/postfix/main.cf:
    smtp_tls_scert_verifydepth = 5

クライアント側の暗号制御

Postfix SMTPクライアントは smtp_tls_mandatory_ciphers 設定パラメータで指定される5つの異なる暗号セキュリティレベルをサポートしています。この設定は、TLS暗号化の強制で使われる、受け入れられる最低限のSMTPクライアントTLS暗号化グレードを制御します。デフォルト値の "medium" は、TLSを強制したいほとんどの配送先に適しており、今日の暗号解読方法では解読は無理です。配送先ベースで暗号を設定する方法に関する情報は smtp_tls_policy_maps を参照してください。

デフォルトでは匿名暗号は許可されていますが、サーバ証明書が検証されると自動的に無効にされます。"encrypt" セキュリティレベルでも匿名暗号を無効にしたければ、"smtp_tls_mandatory_exclude_ciphers = aNULL" をセットします; 日和見TLSでも匿名暗号を無効にするには、"smtp_tls_exclude_ciphers = aNULL" をセットします。通常はこれらの方法を選ぶ必要はありません。匿名暗号化はバンド幅やTLSセッションキャッシュ空間を節約します。証明書を無視しても、それらを要求するところはほとんどありません。

例:

/etc/postfix/main.cf:
    smtp_tls_mandatory_ciphers = medium
    smtp_tls_mandatory_exclude_ciphers = RC4, MD5
    smtp_tls_exclude_ciphers = aNULL

その他のクライアント制御

smtp_starttls_timeoutパラメータはTLSのハンドシェイク手順の開始から終了までの間にPostfix SMTP クライアントが読み書きできる時間を制限します。問題が起こると、Postfix SMTP クライアントはメール交換機リストにある次のネットワークアドレスを試し、代わりのサーバが使えなければ配送は遅延されます。

例:

/etc/postfix/main.cf:
    smtp_starttls_timeout = 300s

TLSマネージャ特有の設定

TLSのような暗号ソフトウェアのセキュリティは、キーやその他の情報に対して予期できない数値を生成する能力に致命的に依存します。その目的のために、tlsmgr(8) プロセスは擬似乱数生成器 (Pseudo Random Number Generator, PRNG) プールを管理します。これは smtp(8) および smtpd(8) プロセスの初期化の際に問い合わせを受けます。デフォルトでは、これらのデーモンは 32バイト、つまり256ビットを要求します。これは128ビット (もしくは168ビット) のセッションキーを生成するのに十分すぎます。

例:

/etc/postfix/main.cf:
    tls_daemon_random_bytes = 32

メモリ内PRNGプールを管理するため、tlsmgr(8) は起動時と動いている間に外部ソースからエントロピーを読み込みます。EGDや /dev/urandom のようなよいエントロピーソースを指定してください; non-blocking ソースだけを使うように気を付けてください (OpenBSDで tlsmgr(8) が /dev/urandom のタイムアウトに文句を言う場合には、/dev/arandom を使ってください)。エントロピーソースが通常のファイルではない場合、ソース名の前にソース形式を付けなければいけません: デバイススペシャルファイルには "dev:" を、 EGD互換ソケットインターフェースを持つソースには "egd:" を付けます。

例 (main.cf で一つだけ指定します):

/etc/postfix/main.cf:
    tls_random_source = dev:/dev/urandom
    tls_random_source = egd:/var/run/egd-pool

デフォルトでは、tlsmgr(8) はシードを指定するイベントのたびに外部ソースから32バイトを読み込みます。これ (256ビット) は 128ビットの共通鍵を生成するのに十分すぎる量です。EGDおよびデバイスエントロピーソースでは、tlsmgr(8) は一度に読み込むデータ量を 255バイトに制限します。通常のファイルをエントロピーソースとして指定した場合は、より多くのデータを読み込むことができます。

例:

/etc/postfix/main.cf:
    tls_random_bytes = 32

メモリ内PRNGプールを更新するために、tlsmgr(8) は擬似乱数による時間が経過したら再び外部エントロピーソースに問い合わせます。その時間はPRNGを使って計算され、 0から最大で tls_random_reseed_period で指定される時間の間の時間です。デフォルトの最大時間間隔は1時間です。

例:

/etc/postfix/main.cf:
    tls_random_reseed_period = 3600s

tlsmgr(8) プロセスは次回起動時にPRNG状態を回復できるようにするため、一定時間経過時とプロセス終了時にPRNG状態を永続性交換ファイルに保存します。このファイルが存在しない場合には作成されます。デフォルトの場所はPostfix設定ディレクトリの下ですが、Postfixによって改変された情報を置くにはふさわしくありません。代わりにファイルの場所を /var パーティション (しかしchroot監獄の中以外) に置くのがよいでしょう。

例:

/etc/postfix/main.cf:
    tls_random_exchange_name = /etc/postfix/prng_exch
    tls_random_prng_update_period = 3600s

即席で始める

以下のステップですぐに始められるでしょう。自分自身のPostfix公開鍵証明書に署名するため、TLS暗号化は使えますがTLS認証はできません。テストや信頼関係を結んでいないサイトとのEメールの交換にはこれで十分です。実際に認証するには、 Postfixがリモートホストの公開鍵証明書を検証できるように、Postfix公開鍵証明書を公認の認証局によって署名してもらい、Postfixが認証局の公開鍵証明書を持つように設定する必要があります。

以下の例では、ユーザの入力は太字フォントで示しており、また "#" プロンプトはスーパーユーザのシェルを示しています。

問題の報告

問題は <postfix-users@postfix.org> を使って報告することが望まれます。情報を投稿するには http://www.postfix.org/lists.html を参照してください。問題を報告する際には、詳細に報告を書いてください。可能であれば、パッチも歓迎します。

Postfix < 2.2 TLSサポートの互換性

Postfix version 2.2 TLSサポートはLutz JanickeによるPostfix/TLS パッチを基にしていますが、細かい点でいくつか異なります。

smtp_tls_per_site 制限は Postfix 2.2サポートサイクルの最後で削除されました。

クレジット