キーだけが必要なので、値は自由に選ぶことができます。ユーザ名やホスト名など。パラメータに、明示的なOpenSSL暗号リストとして受け入れる暗号を指定します。古い設定はTLS暗号化が強制されていない場合でも適用されます。この制御を公開されたMXホストで使用するのは全くお勧めできません。SMTPサーバはデフォルトでSSLv3もしくはTLSv1のみを使います。SSLv2はTLS暗号化がオプションの時にのみ使われます。設定パラメータによって制御されます。設定パラメータで指定される5つの異なる暗号セキュリティレベルをサポートしており、これによりTLS暗号化の強制に使う暗号グレードを決定します。これは基本的に128ビット以上の暗号です。デフォルトでは匿名暗号は許可されていますが、クライアント証明書が要求されると自動的に無効にされます。設定することで匿名暗号を除外したくなるかもしれません。誰もクライアントにサーバ証明書を強制することはできないので、一般に匿名暗号を除外する必要はありません。2.3はサポートします。設定しないことで有効になります。パラメータが必要です。パラメータを生成するのがよいでしょう。しないと、潜在的な攻撃者がみんなが使っているパラメータに対してブルートフォース攻撃を始めることに価値が出てしまいます。そのため、OpenSSLによってデフォルトで選ばれているパラメータは、他のTLSパッケージで配布されるものとはすでに異なっています。サーバが読み書きできる時間を制限します。配送エージェントは1つの兼用プログラムに集約されています。貧弱ないとこではなくなりました。置き換えるだけで、以下に書かれているすべてのTLS機能がSMTPとLMTPに同じように適用されます。LMTP配送エージェントはUNIXドメインソケットで待ち受けているLMTPサーバと通信することもできます。パラメータが使われます。UNIXドメインソケット越しのLMTPトラフィックの日和見暗号化は意味がないことに注意してください。最低1つのサーバもしくはクライアントが相互に認証する必要がある場面においてのみTLSは有用です。暗号グレードがこの場面では適切かもしれません。暗号は暗号化なしの認証を提供します。クライアントサイドの証明書と秘密鍵の設定もし1つ以上のサーバに対してクライアントTLS証明書を示さなければいけないのでなければ、クライアント証明書の設定はしないでください。クライアント証明書はたいていは必要なく、それがない環境でうまく動いている設定に問題を起こすかもしれません。上のパラメータがあれば、それをコメントアウトすることです。SMTPクライアントは証明書をリモートのSMTPサーバに渡すことができます。ここでNetscapeクライアントはより賢く、モートのSMTPサーバから示されたCA証明書にマッチするクライアント証明書だけの中からユーザに選択させます。関数を使うためそのような動作は不可能であり、ただ一つの証明書を選ぶ必要があります。そのため、ここで明示的に指定されない限り、今のところデフォルトでは証明書や鍵を_使いません_。RSAおよびDSA証明書の両方がサポートされています。同時に両方持つことができ、その場合には使われる暗号によってどちらの証明書が出されるかが決まります。SMTPサーバと同じ鍵/証明書ペアを使うことができます。フォーマットである必要があります。秘密鍵を暗号化してはいけません。パスワードなしでアクセスできなければいけません。同じファイルに入れることもできます。入手可能でなければいけません。これらの証明書をサーバ証明書に加えるとよいでしょう。その場合はクライアント証明書を最初にして、それから発行CAのものとします。よって発行されました。SMTPクライアント証明書はSSLクライアント証明書として使えなければなりません。テストを通らなければいけません。ルートCAを信頼しているサーバはルートCA証明書のローカルコピーを持っているため、ここにルートCA証明書を含めておく必要はありません。それを除いておくと、TLS交換のオーバーヘッドを減らせます。ディレクトリにインストールします。注目するサーバへの証明書チェーンにおけるCAの数よりも小さくなければ、ルートCAによって署名された中間CAを明示的に信頼する必要はありません。CAによって直接署名された証明書のみを検証します。(サーバが中間CA証明書を提供するように正しく設定されている限り)。SMTPクライアントは発行証明機関の証明書を信頼する必要があります。ディレクトリに保存できます。1つ以上の信頼したCAのCA証明書を含んでいます。開かれるため、chroot監獄からアクセスできる必要はありません。情報が必要なときにこのディレクトリのファイルから読み込まれます。ディレクトリはオプションのchroot監獄の内部でアクセスできる必要があります。選択は空間と時間のトレードオフです。信頼されたCAがたくさんある場合、すべてをあらかじめメモリに読み込むコストは証明書が必要となったときのアクセス時間が減っても報われないかもしれません。SMTPクライアントのTLS行動に関してさらなる情報を得るために、ログレベルを0から4まで増加させることができます。それぞれのログレベルは下位のログレベルで記録される情報も含みます。TLS行動に関するログ記録を無効にします。TLSハンドシェイクと証明書の情報をログに記録します。TLSネゴシエーションの間のレベルをログに記録します。TLSネゴシエーションプロセスの16進数およびASCIIダンプをログに記録します。STARTTLS以降の通信の16進数およびASCIIダンプを完全にログに記録します。SMTPクライアントがセッションのネゴシエーションをおこなうと、いくらか計算時間とネットワークのバンド幅を消費します。プロセスでセッション情報はキャッシュされ、プロセスが終了するとセッション情報も失われます。プロセスで共有するために、永続性セッションキャッシュが使えます。数キロバイトのオブジェクトを保存できて連続操作をサポートしている、どんなデータベース形式でも指定することができます。DBMデータベースは小さなオブジェクトしか保存できないため、これには適しません。プロセスによって管理されるため、並列アクセスでも問題ありません。TLSセッションキーを繰り返しやりとりするのは負荷が高いため、セッションをキャッシュすることを強く推奨します。サーバは将来、1つのクライアントが単位時間あたりに交換できるセッションの数を制限することになるでしょう。SMTPクライアントセッション情報は一定の時間が経過すると失効します。最大の24時間を推奨しています。3600sクライアントTLS制限TLS通信チャネルのセキュリティ属性はアプリケーションに特有のものです。TLSプロトコルはクライアントとサーバの間の機密性、耐タンパー性、相互に認証されたチャネルを提供しますが、これらすべてのセキュリティ機能がすべての通信で使えるわけではありません。ブラウザとWebサーバ間での相互TLS認証は可能ですが、webサーバが公共サービスですべての潜在的ユーザの身元を検証するのは、実用的でなかったり不便でさえあったりします。ブラウザはHTTPSサーバの身元を検証しますが、ユーザは匿名のままです。セキュリティポリシーの多くはクライアント次第です。クライアントがサーバの名前を検証しないと決めても、サーバはそれを気にしません。興味深いブラウザセキュリティの話題はたくさんありますが、ここでこだわるべきではありません。われわれの目的はSMTPと連動するTLSの機能を理解することです。SMTPで見られる重要なことは、公のMXホストはHTTPSサーバよりもずっとSMTPクライアントに翻弄されるということです。SMTPクライアントでのTLSサポートはまだルールというよりも例外なので、クライアントがTLSを使うことで十分に注意を払うよう強制できないだけではなく、TLSを強制することさえもできません。実際問題として、TLSが有効になったクライアントだけにMXホストへのアクセスを制限することはできません。能力を大幅に減らしてしまうでしょう。特定の送信組織からのメールにTLSを強制しようとしたくなるかもしれませんが、これも行き詰ってしまいます。平文でもれてしまうというものです。他にも、送信者から受信者へのメールが転送されるかもしれず、その転送する組織と最終配送先とは何のセキュリティ調整も行われていないかもしれないという問題もあります。バウンスにも保護が必要です。これらはIPアドレスや接続クライアントのHELO名でのみ識別できますが、送信側組織で外行きemailサーバが可能性のあるIPアドレスやHELO名を追跡し続けるというのは困難です。結果として、公開されたMXホストへのメール配送に関するTLSセキュリティはほぼ完全にクライアントの責任です。HTTPSとは逆に、サーバは主としてTLSセキュリティを受動的に有効にするだけで、残りはクライアントに任されます。サーバが信頼するクライアントからの外行きメールだけを扱う専用のMSAの場合はサーバはクライアントセキュリティポリシーを指図するより大きな機会を得ますが、以下ではクライアントセキュリティポリシーに焦点を当てます。SMTPクライアントには、より複雑な点があります。HTTPSとは違って与えられたドメインにメールを配送する際に、SMTPセッションの目的ホストとして直接ドメイン名を使うことはほとんどありません。これらはたいてい認証されていません。現状では、クライアントがセキュアではない方法で得たMXホスト名を検証すると、DNS中間者攻撃を受ける可能性があります。クライアントが受信者ドメイン名を検証しようとすると、複数のドメインを持つSMTPサーバは証明書にそのeメールドメイン名すべてをリストアップする必要があり、新しいドメインが追加されるたびに新しい証明書を作る必要があります。このアプローチは現状には合わず、また拡張もできません。送信側および受信側サイトをどこにでも配置することはできなくなるという制限がかけられます。それぞれの配送先ドメインに対して手動でこの種の設定をおこなう必要があり、また多くの場合、セキュアにされた共通の配送先にホスティングされる追加ドメインに対して、デフォルトではないTLSポリシーテーブルエントリを実装する必要があります。2.3ではかなり簡単にセキュアチャネルが設定できるようになりましたが、それらは標準にはならないでしょう。特定のセキュリティ調整をおこなわない一般的などメインでは、このセキュリティレベルはあまり合いません。一般には強い認証は可能ではなく、検証可能な証明書は時間と費用がかかるため、TLSを実装している多くのサーバが自己署名証明書やプライベートCAを使っています。このことは公共のインターネットでの検証されたTLSの適用をさらに制限してしまいます。Jeanickeが最初の非公式パッチを設計した時からよく理解されています。問題はSMTPやTLSに特徴的なものではなく、同じような問題はHTTPSやKerberosのエイリアスを使ったセキュアな接続にもあります。間接的なネーミングをより頻繁に使うだけです。クライアントTLSセキュリティレベル以下に列挙したTLSセキュリティレベルは次のセクションで詳細に記述されています。なしTLSを使わない。encryptTLS暗号化の強制。verifyサーバ証明書の検証を強制。secureセキュアチャネルTLS。TLSセキュリティレベルでは、TLS暗号化は無効になります。これがデフォルトのセキュリティレベルです。設定することで明示的に設定可能です。どちらの方法でも、TLSはサーバがサポートしていても使われません。パラメータを使ってください。配送先ごとの設定はこのデフォルト設定を上書きします。その場合、明示的にTLSの設定がされた配送先に対してのみ、TLSは選択的に使われます。配送先のサブセットに対してTLSを無効にし、その他を有効にしたままにすることもできます。セキュリティレベルを指定します。キーワードを指定します。TLSセキュリティレベルでは、TLS暗号化は日和見主義になります。ESMTP機能をサポートしていると、SMTPトランザクションは暗号化されます。なければ、メッセージは平文で送られます。セットすることで設定可能です。平文での送信が受け入れられるため、デフォルトのTLSセキュリティよりも強いものを要求するのは互換性を下げるだけです。グレード以上の暗号が使われます。パラメータを使います。日和見TLSでは、サーバ証明書が信用できなかったり間違った名前を持っていてもメール配送を続けます。2.3からは、日和見TLSセッションに対するTLSハンドシェイクが失敗しても、メール配送を諦めるのではなく、TLSを無効にして処理を再試行します。暗号化しない接続を試すことで、サーバTLSの実装が非互換なサイトへのメール配送が可能となります。日和見暗号化はUNIXドメインソケットを使ったLMTPでは使われません。通信チャネルはTLSがなくても秘匿化されており、TLSの意味があるとしたら認証だけです。UNIXドメインソケットを使ったLMTPに対して日和見TLSを設定しないでください。セキュリティレベル以上でのみ、UNIXドメインソケットを使ったLMTP配送にTLSを設定してください。LMTPセッションの日和見暗号化を設定しようとしても、無視されて警告がメールログに記録されます。選択した配送先にのみ日和見TLSを有効にすることもできます。セキュリティレベルを指定します。キーワードを指定します。これがTLSで保護されたSMTPセッションで最も一般的なセキュリティレベルです。これより強いセキュリティレベルは一般的には使えず、必要ならばたいていは配送先ごとで設定します。上のTLS制限のセクションを参照してください。TLSセキュリティレベルでは、メッセージは暗号化TLSセッションを使わないと送れません。SMTPトランザクションは中断されます。適切なサーバが見つからないと、メッセージは遅延されます。セットすることで設定できます。TLS暗号化は常に使われますが、サーバ証明書が信頼できなかったり間違った名前を持っていてもメール配送は続けられます。設定パラメータが十分な安全性を持つSSLプロトコルバージョンのリストや最低限の暗号強度を決定します。プロトコルや暗号の要求が合わないと、メールの処理は中断されます。これらのパラメータのドキュメントには互換性やセキュリティガイドラインの有益な情報が含まれます。パラメータを使います。受動的な盗聴攻撃をできなくすることは可能ですが、TLS暗号化の強制は公共のインターネットにメールを配送するためのデフォルトのセキュリティレベルとしては使えません。とんどのMXホストはTLSを全くサポートしておらず、壊れたTLSをサポートしているものもあります。インターネットにメールを配送するホストでは、デフォルトのセキュリティレベルとしてTLS暗号化の強制を設定すべきではありません。特定の配送先にのみTLS暗号化の強制を有効にすることもできます。セキュリティレベルを指定します。キーワードを指定します。ユーザは新しいTLSポリシー設定を使うべきです。そのサブドメインへのトラフィックで、対応するMXホストを通るものは常にTLSを使います。セキュリティレベルセッションで使われます。テーブルを使わずにサブドメインを指定できません)。2.3+では、古い、サイトごとのテーブルを使わないでください。通るように設定しています。セッションは認証なしで暗号化されます。グレードの暗号が使えることがわかっており、これらはポリシーテーブルで選択されています。四角カッコで括ったものとオプションのポートです。ついているもの、ポートサフィックスがついていないものはそれぞれポリシーテーブルの検索キーが異なってしまいます。対して多くともこれらのうち1つの形式を使ってください。テーブルのエントリは一貫した指定はなされていません。ポリシー検索は避けてください。生のホスト名に似ていますが、それらは適した配送先です)。代わりに新しいポリシーテーブルを使ってください。あり、サーバ証明書名が既知のパターンにマッチする場合、メッセージはTLS暗号化セッションを使ってのみ送られます。セットすることで設定できます。証明書名マッチングの戦略を上書きできます。マッチング戦略を微調整するのは、たいていはセキュアチャネルの配送先にのみ適しています。パラメータを使います。拡張のDNS名がサーバ名を検証するのに使われます。サーバ証明書を検証せずに暗号化を強制したいのであれば、上を参照してください。攻撃や他の攻撃を減らす可能性はありますが、証明書の信頼チェーンやサブジェクト名検証の強制はデフォルトのインターネットメール配送ポリシーとしては有効になっていません。ほとんどのMXホストはTLSを全くサポートしておらず、TLSが有効になったMTAのかなりの割合が自己署名証明書を使っているか、プライベート認証局によって署名された証明書を使っています。インターネットにメールを配信するマシンでは、デフォルトのポリシーとしてサーバ証明書検証を強制するように設定すべきではありません。サポートし、かつ、検証可能なサーバ証明書を提供するサーバのみに接続することがわかっているのであれば、デフォルトのセキュリティレベルとしてサーバ証明書検証を強制するのが適切かもしれません。必要なSTARTTLSをサポートしている中央メールハブに全てのメールを送るクライアントというのがその例です。そのような場合、代わりにセキュアチャネル設定を使うこともよくあります。特定の配送先にのみサーバ証明書検証の強制を有効にすることもできます。セキュリティレベルを指定します。キーワードを指定します。ユーザは新しいTLSポリシー設定を使うべきです。ドメインへの全てのトラフィックを暗号化します。peerホスト名が検証されますが、検証はDNS応答の偽装に対して脆弱です。グレードの暗号を使います。セッションを使ってのみ、メッセージは送られます。適切なサーバが見つからないと、メッセージは遅延されます。セットすることで設定できます。証明書マッチング戦略を上書きできます。加えて、偽装されたDNSデータに対してpeer証明書検証を強化するように設定するのが適切な設定です。パラメータを使ってください。拡張のDNS名がサーバ名を検証するのに使われます。サーバ証明書を検証せずに暗号化を強制したいのであれば、上を参照してください。攻撃や他の攻撃を減らす可能性はありますが、証明書の信頼チェーンやサブジェクト名検証の強制はデフォルトのインターネットメール配送ポリシーとしては有効になっていません。ほとんどのMXホストはTLSを全くサポートしておらず、TLSが有効になったMTAのかなりの割合が自己署名証明書を使っているか、プライベート認証局によって署名された証明書を使っています。インターネットにメールを配信するマシンでは、デフォルトのポリシーとしてサーバ証明書検証を強制するように設定すべきではありません。サポートし、かつ、検証可能なサーバ証明書を提供するサーバのみに接続することがわかっているのであれば、デフォルトのセキュリティレベルとしてサーバ証明書検証を強制するのが適切かもしれません。必要なSTARTTLSをサポートしている中央メールハブに全てのメールを送るクライアントというのがその例です。特定の配送先にのみセキュアサーバ証明書検証を有効にすることもできます。セキュリティレベルを指定します。キーワードを指定して、DNS偽装に対して証明書の検証を強化します。ユーザは新しいTLSポリシー設定を使うべきです。テーブルを上書きしないセキュアチャネル:クライアントはすべてのトラフィックを暗号化し、DNS応答の偽装から確実に配送先名を保護します。SMTPサーバを探すのに使われますが、サーバ証明書の名前を確認する際には使われません。いう対象の名前もしくはそのサブドメイン名の、信頼された証明書を持っていることが要求されます。パラメータについてのドキュメントを参照してください。ドメインを検証することでセキュアになります。これにより、サーバ管理者はCAにすべてのセカンダリドメインをリストアップした証明書に署名させなくてもすむようになります。これの問題は、セカンダリドメインにセキュアチャネルを張ろうとするクライアントはTLSポリシーテーブルのエントリを明示する必要があるということです。関連ドメインを扱うのに2つの方法があることに注意してください。1つ目はそれぞれのドメインに対してデフォルトのルーティングを使い、期待される証明書の対象名を上書きするためにポリシーテーブルのエントリを加える方法です。テーブルのnext-hopを上書きし、共通のnexthopに対する1つのポリシーテーブルエントリを使う方法です。ここでは、ドメインの所有者が変更しても問題ないことから、1つ目の方法を選択します。2つ目の方法では間違った配送先に対して安全にメールを配送してしまいますが、最初の方法だと認証が失敗してメールはローカルのキューにとどまります。ほとんどの場合は1つ目の方法のほうがより適切です。(単一点障害を避けるため、その名前は1つ以上のロードバランサアドレスや、複数の物理的ホストを1つにしたアドレスに解決されるかもしれません)。ゲートウェイのIPアドレスで到達可能な物理的ホスト全ての証明書に、その論理ゲートウェイ名がリストアップされています。ポリシーを強化したものを使っても実装できます。上で述べたように、この方法は関連ドメインの持ち主が変わるとメールが間違って配送される可能性があります。ポリシーを検索するのは避けてください。nexthopは生のホスト名に見えるかも知れませんが、それらは配送先として適したものです)。代わりに新しいポリシーテーブルを使ってください。2.3は、より柔軟な新しいTLSポリシーテーブルを導入しました。2.2のサイトごとのテーブルについての記述を読んでください。一部少数のサーバはSTARTTLSを提供しますが、常にネゴシエーションに失敗します。2.3では、暗号化が強制されない限り、すぐにTLSを無効にして配送を再試行します。問題の配送先に対して明示的にTLSを無効にする必要はなくなりました。配送先のソフトウェアや設定が修正されると、すぐに暗号化が使えるようになります。パラメータを使って指定します。SMTPクライアントTLSセキュリティポリシーを持つオプションの検索テーブルをリストアップします。(両方のパラメータの値が入っていると警告がログに記録されます)。指定されたnext-hop配送先全体で、TLSポリシーテーブルはインデックス化されます。これには四角カッコで括られたものや非デフォルト配送先サーバポートサフィックスを含みます。検索キーには含みません。ポートおよび四角カッコは検索キーとして使われますが、サーバ名検証には使われません。始まる親ドメインが再帰的にマッチします。これにより、ある受信者ドメインとそのサブドメイン全てに対するセキュリティポリシーを指定できるようになります。属性もオプションで続けることができます。TLSセキュリティレベルは上で記述しています。以下、対応するテーブルの文法を記述します:なしTLSを使わない。このレベルでは追加属性はサポートされません。このレベルでは追加属性はサポートされません。encryptTLS暗号化の強制。リモートSMTPサーバがSTARTTLSを提供し、TLSハンドシェイクが成功した場合にのみ、メールが配送されます。パラメータをそれぞれオプションで上書きします。verifyサーバ証明書の検証を強制。マッチしている場合にのみ、メールが配送されます。secureセキュアチャネルTLS。マッチしている場合にのみ、メールが配送されます。属性は特に役立ちます。テーブルをマニュアルルーティングで上書きしてもおこなえますが、ドメインが新しいゲートウェイホストに割り当てられた場合、その方法では間違ったホストにメールが配送されてしまいます。新しいMXホストの検証に失敗すると、メールは遅延されます。ポリシーテーブルのエントリが複数のマッチングパターンや複数のマッチング戦略、複数のプロトコルを指定する場合、これらはコロンで区切らなければいけません。レベルの脆弱性となってしまう可能性があります。DNSセキュリティが保障されていない環境で使わないでください。古い、サイトごとのTLSポリシーのサポートこのセクションは、古い、サイトごとのTLSポリシーメカニズムについて記述しています。2.3ポリシーテーブルメカニズムとは違い、これはポリシー検索のキーとして信頼できないサーバホスト名を使い、またサーバ証明書に現れることができる名前について制御できません。このため、古いメカニズムはMXやCNAMEレコード情報の誤ったDNSホスト名に対して、たいていは脆弱です。これらの攻撃を減らすのはかなり困難です。新しいポリシーテーブルはセキュアチャネル設定を容易にし、セッションの暗号化を強制することで暗号やプロトコルの選択をより制御しやすくなります。生のホスト名でポリシー検索するのは避けてください。nexthopは生のホスト名のように見えますが、これらは配送先として適しています)。代わりに新しいポリシーテーブルを使ってください。2.3からは、基礎となるTLSの強制レベルは古い、サイトごとのテーブルと新しいポリシーテーブルで共通です。パラメータは、どのテーブルが使われるかにかかわらず、必要な暗号化に対してTLS暗号化およびプロトコルを制御します。キーワードに対してマッチング戦略を決定します。パラメータも日和見TLSセッションに適用されるため、注意して使うか全く使わないようにすべきです。リモートSMTPサーバと互換性のない暗号リスト制限をセットすると、そのサーバに到達できなくなり、TLSハンドシェイクは毎回試行されて毎回失敗することになります。この名前はMX検索やCNAME検索など、他のDNS検索から得られるものかもしれません。配送先を代わりに使ってください。設定の情報で上書きされるかもしれません。対しては、これが推奨される検索キーです。next-hopポリシーを上書きしません。以下に示すような、より特定された、もしくはより安全なサイトごとのポリシーが代わりに優先されます。ワイルドカードは使えません。右側部分には以下のキーワードのいずれか1つを指定します:NONETLSを使わない。