SMTP チャネルを設定する

インストールの種類によっては、Messaging Server のインストール時に数種の SMTP チャネルが提供されます (次の表を参照)。このようなチャネルは TCP/IP の上位プロトコルとして SMTP を実装します。マルチスレッド TCP SMTP チャネルには、ディスパッチャ制御下のマルチスレッド SMTP サーバーが含まれます。送信された SMTP メールは、必要に応じてジョブコントローラの制御下で動作し、チャネルプログラム tcp_smtp_client によって処理されます。

この節で説明するチャネルキーワードを追加または削除することで、これらのチャネルの定義を変更したり、新規チャネルを作成したりできます。また、オプションファイルは TCP/IP チャネルのさまざまな特徴を制御するために使用されます。このようなオプションファイルは、MTA 設定ディレクトリ (msg_svr_base/config) に保存し、x_option という名前を付けなければなりません。この x はチャネルの名前です。詳細は、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「Option File」を参照してください。

この節には、次の項があります。

• 「SMTP チャネルオプションを設定する」

• 「SMTP コマンドとプロトコルのサポート」

• 「TCP/IP 接続と DNS 検索のサポート」

• 「SMTP 認証、SASL、TLS」

• 「TCP/IP 接続と DNS 検索のサポート」

• 「TCP/IP 接続と DNS 検索のサポート」

• 「Microsoft Exchange ゲートウェイチャネルを指定する」

• 「Transport Layer Security」

SMTP チャネルオプションを設定する

TCP/IP チャネルオプションファイルは、TCP/IPチャネルのさまざまな特性を制御します。チャネルオプションファイルは MTA 設定ディレクトリに保存し、x_option という名前を付けてください。x はチャネル名です。たとえば、/msg_svr_base/config/tcp_local_option のようになります。

オプションファイルは、1 つまたは複数のキーワードとその関連値によって構成されています。たとえば、サーバーのメーリングリストの展開を無効にするには、オプションファイルに DISABLE_EXPAND キーワードを追加し、値を 1 に設定します。

その他のオプションファイルキーワードを使用すると、次のような制御を行うことができます。

• メッセージ当たりの宛先数を制限する (ALLOW_RECIPIENTS_PER_TRANSACTION)

• 接続当たりのメッセージ数を制限する (ALLOW_TRANSACTIONS_PER_SESSION)

• MTA ログファイルに記録される情報のタイプを微調整する (LOG_CONNECTION、LOG_TRANPORTINFO)

• クライアントチャネルプログラムが許可できる同時送信接続の最大数を指定する (MAX_CLIENT_THREADS)

すべてのチャネルオプションキーワードと構文の詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』を参照してください。

SMTP コマンドとプロトコルのサポート

SMTP チャネルで EHLO、ETRN、EXPN、VRFY などの SMTP コマンドをサポートするかどうかを指定することができます。また、チャネルが DNS ドメイン確認をサポートするかどうかや、どの文字を改行記号として受け入れるかなどを指定することも可能です。この項では、次の内容について説明します。

• 「チャネルプロトコル選択と改行記号」

• 「EHLO コマンドのサポート」

• 「ETRN コマンドのサポート」

• 「VRFY コマンドのサポート」

• 「DNS ドメイン確認」

• 「文字セットのラベルと 8 ビットデータ」

• 「プロトコルストリーミング」

表 12–21 に、この節で説明するキーワードの要約を示します。

チャネルプロトコル選択と改行記号

キーワード: smtp、nosmtp、smtp_crlf、smtp_cr、smtp_crorlf、 smtp_lf

smtp および nosmtp キーワードは、チャネルが SMTP プロトコルをサポートするかどうかを指定するものです。smtp (またはその変形) は、すべての SMTP チャネルに対して必須のキーワードです。

smtp_crlf、smtp_cr、smtp_crorlf、および smtp_lf キーワードは、MTA が改行記号として受け入れる文字シーケンスの種類を指定するために、SMTP チャネルに対して使用されます。smtp_crlf キーワードを使用すると、キャリッジリターン (CR) + ラインフィーダ (LF) のシーケンスのみが改行記号として認識されます。smtp_lf または smtp キーワードでは、CR なしの LF のみを使用できます。また、smtp_cr キーワードでは、LF なしの CR のみを使用できます。これらのオプションは、着信データにしか適用されません。

SMTP では 改行記号として CRLF が要求されるため、MTA は常に CRLF シーケンスを生成します。各種の smtp キーワードは、MTA がその他の非標準的な改行記号を受け入れるかどうかを指定するだけのものです。たとえば、MTA が規定どおりの SMTP メッセージだけを受け入れ、非標準的な改行記号を含むメッセージを拒否するように指定するには、smtp_crlf を使います。

EHLO コマンドのサポート

キーワード: ehlo、noehlo、checkehlo

SMTP プロトコルは、その他のコマンドの使用のネゴシエーションを行うことができるよう拡張されています (RFC 1869)。これを利用するには、RFC 821 規定の HELO コマンドの代わりに、新しい EHLO コマンドを使用します。EHLO コマンドを受け取った拡張 SMTP サーバーはサポートする拡張内容のリストを返します。拡張をサポートしないサーバーにこのコマンドを発行した場合は、不明なコマンドエラーのメッセージが返され、エラーメッセージを受け取ったクライアントは折り返し HELO コマンドを送ります。

このフォールバックは、サーバーが拡張されているかどうかにかかわらず機能します。ただし、サーバーが RFC 821 に準拠した SMTP を実装していない場合は、問題が発生する可能性があります。特に、認識できないコマンドを受け取ると接続を遮断してしまうサーバーもあります。

EHLO コマンドを受け取ったサーバーが接続を遮断した場合、SMTP クライアントは HELO コマンドを発行して再接続を試みます。ただし、EHLO を受け取ったリモートサーバーが接続を遮断するだけでなく、その他の問題を併発する場合は、クライアントが再接続できないこともあります。

ehlo、noehlo、および checkehlo チャネルキーワードは、このような状況に対処するためのキーワードです。ehlo キーワードは、1 回目の接続試行に EHLO コマンドを使用するよう MTA に指示を出します。noehlo キーワードは EHLO コマンドの使用をすべて無効にします。checkehlo キーワードでは、リモート SMTP サーバーから返された応答見出しに「ESMTP」文字列があるかどうかが確認されます。この文字列がある場合は EHLO、ない場合は HELO が使用されます。デフォルトでは、最初の接続試行に対する応答の見出しに「fire away」文字列が含まれている場合は HELO を使用し、それ以外の場合は EHLO を使用するように設定されています。このデフォルト設定は ehlo キーワードと checkehlo キーワードの中間的な効果を得るものであり、この設定を指定するためのキーワードは存在しないことに注意してください。

ETRN コマンドのサポート

キーワード: allowetrn、blocketrn、disableetrn、domainetrn、silentetrn、sendetrn、nosendetrn、novrfy

RFC 1985 で規定されている ETRN コマンドは SMTP サービスの拡張を可能にするものです。このコマンドによって SMTP サーバーがクライアントとの通信に基づいてメッセージキューの処理を開始し、指定のホストにメッセージを配信できるようになります。

SMTP クライアントは ETRN を使用して、自分宛のメッセージキューの処理を開始するようリモート SMTP サーバーに要求できます。つまり、ETRN は、自分のシステムに入ってくるメッセージのためにリモート SMTP システムをポーリングする方法を提供します。これは、一過性の接続しか持たないシステム間 (たとえば、ダイアルアップ以外の方法ではインターネットに接続できないサイト用に二次的な MX ホストとして設定されているサイトなど) に対して有用です。このコマンドを有効にすることで、ダイアルアップ接続を行うリモートサーバーもメール配信の要求を送ることができるようになります。

SMTP クライアントは、SMTP ETRN コマンド行でメッセージの送信先となるシステム名 (通常、その SMTP クライアントシステムの名前) を指定します。リモート SMTP サーバーが ETRN コマンドをサポートする場合、サーバーは指定のシステムに別途接続し、そのシステム宛のメッセージの配信を開始するためのプロセスがトリガされます。

ETRN コマンドへの応答

allowetrn、blocketrn、domainetrn、および silentetrn キーワードは、SMTP クライアントが ETRN コマンドを発行して MTA キュー内のメッセージを配信するよう要求した際に、MTA がどのように対応するかを指定するキーワードです。

デフォルト設定では allowetrn キーワードが有効になっているため、MTA はすべての ETRN コマンドを処理します。MTA が ETRN コマンドを拒否するように指定するには、チャネル定義に blocketrn キーワードを使用します。

MTA がすべての ETRN コマンドに従い、かつドメインによって確認されたチャネル名をエコーしないように指定するには、silentetrn キーワードを使用します。ETRN コマンドがドメインを指定している場合にのみ MTA がそのコマンドを処理するように指定するには、domainetrn キーワードを使用します。また、このキーワードを使用すると、MTA は、ドメインと一致し、MTA が実行しようとするチャネル名をエコーしません。

disableetrn では、ETRN コマンドに対するサポートが完全に無効となります。SMTP サーバーで、ETRN はサポートされているコマンドとして通知されません。

ETRN コマンドを送信する

sendetrn および nosendetrn チャネルキーワードは、MTA が SMTP 接続開始時に ETRN コマンドを送るかどうかを指定するためのものです。デフォルト設定では nosendetrn が有効になっているため、MTA は ETRN コマンドを送りません。リモート SMTP サーバーが ETRN コマンドをサポートする場合にのみ MTA が ETRN を発行するように指定するには、sendetrn キーワードを使用します。sendetrnn キーワードのあとには、メッセージの配信先となるシステムの名前を記述する必要があります。

VRFY コマンドのサポート

キーワード: domainvrfy、localvrfy、vrfyallow、vrfydefault、vrfyhide

VRFY コマンドは、SMTP クライアントが特定のユーザー名に宛てられたメールが存在するかどうかを確認するよう SMTP サーバーに要求するためのコマンドです。VRFY コマンドは、RFC 821 で定義されています。

サーバーは、ユーザーがローカルであるかどうか、メールが転送されるかどうかなどの情報を返します。250 という応答はユーザー名がローカルであることを意味し、251 はローカルではないがメッセージの転送は可能であることを意味します。サーバーの応答には、メールボックス名が含まれます。

VRFY コマンドを送信する

通常の環境では、SMTP ダイアログの一部として VRFY コマンドを発行する必要はありません。SMTP RCPT TO コマンドに VRFY コマンドと同じ効果があり、必要に応じて適切なエラーを返すためです。ただし、サーバーの中には RCPT TO コマンドを受け取った場合にはコマンドが指定するアドレスをいったん受理してからバウンスし、VRFY コマンドを受け取った場合はより広範なチェックを実行するものもあります。

デフォルト設定では novrfy キーワードが有効になっているため、MTA は VRFY コマンドを発行しません。

MTA が SMTP VRFY コマンドを発行するように指定するには、チャネル定義に domainvrfy または localvrfy キーワードを挿入します。domainvrfy キーワードを使用すると、完全なアドレス (user@host) を引数とする VRFY コマンドが発行されます。localvrfy キーワードを使用すると、アドレスのローカル部分 (user) だけを引数とする VRFY コマンドが発行されます。

VRFY コマンドに応答する

vrfyallow、vrfydefault、および vrfyhide キーワードは、送信側の SMTP クライアントから SMTP VRFY コマンドを出したときの SMTP サーバーの応答を制御します。

MTA が詳細な情報を含む応答を返すように指定するには、vrfyallow キーワードを使用します。HIDE_VERIFY=1 チャネルオプションが指定されていないかぎり、MTA が詳細な情報を含む応答を返すよう指定するには、vrfydefault キーワードを使用します。MTA があいまいな応答を返すよう指定するには、vrfyhide キーワードを使用します。これらのキーワードを使用すると、VRFY コマンドに対する応答をチャネルごとに制御できます。一方、HIDE_VERIFY オプションは、1 つの SMTP サーバーを介して処理されるすべての着信 TCP/IP チャネルに適用されます。

EXPN サポート

キーワード: expnallow、expndisable、expndefault

expnallow は、DISABLE_EXPAND SMTP チャネルオプションによって SMTP サーバーレベルで EXPN が無効にされている場合でも、EXPN を許可します。expndisable は、EXPN を無条件で無効にします。expndefault は、SMTP サーバーの設定で EXPN が許可されていればを許可します (デフォルト)。リストごとに展開を無効にすることができますが、サーバーレベルで無効にされている場合は、リストごとの設定は意味を持ちません。

DNS ドメイン確認

キーワード: mailfromdnsverify、nomailfromdnsverify

mailfromdnsverify を着信 TCP/IP チャネルに対して設定すると、MTA は SMTP MAIL FROM コマンドで指定されているドメインのエントリが DNS に存在するかどうかを確認し、エントリが存在しない場合にはメッセージを拒否します。デフォルト設定では、nomailfromdnsverify が有効になっているため、この確認は行われません。ただし、返信アドレスに対して DNS 確認を行うと、許可されるべきメッセージも拒否されてしまう可能性があることに注意してください (たとえば、正規のサイトでもそのドメイン名がまだ登録されていない場合や、DNS が適切に動作していない場合など)。これは、RFC 1123 の「Requirements for Internet Hosts (インターネットホストの必要条件)」で規定されている電子メール受信の心得に反する行為です。ただし、存在しないドメインから不特定多数宛のメール (UBE) が送られる場合は、この確認を行なった方がよい場合もあります。

COM および ORG トップレベルドメインの DNS ワイルドカードエントリの導入によって mailfromdnsverify が有用でなくなったため、mailfromdnsverify コードは変更されました。DNS が 1 つまたは複数の A レコードを返すと、これらの値と新しい MTA オプション BLOCKED_MAIL_FROM_IPS によって指定されたドメインリテラルとが比較されます。一致する値が見つかると、ドメインは無効とみなされます。正しい動作を復元するための、現在の正しい設定は次のとおりです。

BLOCKED_MAIL_FROM_IPS=[64.94.110.11]

このオプションの値はデフォルトでは空の文字列です。

文字セットのラベルと 8 ビットデータ

キーワード: charset7、charset8、charsetesc、sevenbit、eightbit、 eightnegotiate、eightstrict

文字セットのラベル

MIME 仕様は、プレーンテキストのメッセージで使用される文字セットにラベルを付ける仕組みを提供します。特に、Content-type: ヘッダー行の一部として charset= パラメータを指定することができます。MIME には、US-ASCII (デフォルト)、ISO-8859-1、ISO-8859-2 のようなさまざまな文字セット名が定義されており、その後さらに定義されたものも多数あります。

既存のシステムやユーザーエージェントの中には、これらの文字セットラベルを生成する仕組みを提供しないものもあり、その結果、プレーンテキストメッセージの中には適切にラベル付けされていないものもあります。charset7、charset8、および charsetesc チャネルキーワードは、文字セットのラベルが欠如しているメッセージヘッダーに文字セット名を挿入するメカニズムをチャネルごとに提供するキーワードです。これらのキーワードを使用する場合は、単一の文字セット名を引数として指定する必要があります。文字セット名が正しいかどうかの確認は行われません。文字セットの変換は、MTA テーブルディレクトリ内の文字セット定義ファイル charsets.txt で定義されている文字セットに対してのみ可能であることに注意してください。できるだけこのファイルで定義されている名前を使用することをお勧めします。

メッセージに含まれるのが 7 ビットデータのみの場合は charset7 を、8 ビットデータが含まれる場合は charset8 を使用します。charsetesc は、メッセージに 7 ビットデータおよびエスケープ文字が含まれる場合に使用します。適切なキーワードが指定されていない場合は、Content-type: ヘッダー行には文字セット名が挿入されません。

charset8 キーワードでは、メッセージヘッダーの 8 ビット文字の MIME エンコーディングも制御されます (メッセージヘッダーでは、8 ビットのデータは常に不正)。MTA では通常、メッセージヘッダーにあるすべての不正な 8 ビットデータが MIME でエンコードされ、charset8 の値が指定されていない場合は「UNKNOWN」文字セットとしてラベル付けされます。

これらの文字セット指定が既存のラベルより優先されることはありません。メッセージにすでに文字セットラベルが含まれている場合やメッセージがテキストでない場合、これらのキーワードは効果をもたらしません。通常、MTA のローカルチャネルは次のようにラベル付けされます。

l ... charset7 US-ASCII charset8 ISO-8859-1 ...
hostname

Content-type ヘッダーがメッセージにない場合は、このヘッダーが追加されます。また、MIME-version: ヘッダー行がない場合は、そのヘッダー行が追加されます。

charsetesc キーワードは、特に日本語や韓国語の文字セットを使用し、エスケープ文字を含むラベルのないメッセージを受信するチャネルに便利です。

8 ビットデータ

127 (10 進) 以上の序数値を持つ文字の使用は制限される場合があります。特に、SMTP サーバーの中には、高ビットを切り捨てるために 8ビット領域の文字を含むメッセージの文字化けの原因となるものもあります。

Messaging Server は、そのようなメッセージを自動的にエンコードし、8 ビットデータがメッセージに直接表示されないようにする機能を備えています。特定のチャネルのキューに入れられるすべてのメッセージにエンコードを適用するには、sevenbit キーワードを使用します。そのような制限がない場合は、eightbit を使用します。

リモート SMTP サーバーが 8 ビットをサポートすると明示していないかぎり、SMTP プロトコルは 8 ビットを許可しません。ただし、拡張 SMTP など、転送形式によっては、8 ビットの文字を転送できるかどうかを判断するためのネゴシエーションの形式をサポートするものもあります。ネゴシエートが失敗した場合に備えて、eightnegotiate キーワードを使用し、チャネルがメッセージをエンコードするように指定しておくことを強くお勧めします。デフォルト設定ではすべてのチャネルに対してこのキーワードが有効になっているため、ネゴシエーションをサポートしないチャネルは 8 ビットデータの転送が可能であるという仮定のもとに動作します。

Messaging Server が、ヘッダーに不正な 8 ビットデータを含むメッセージをすべて拒否するように設定するには、eightstrict キーワードを使用します。

プロトコルストリーミング

キーワード: streaming

メールプロトコルによっては、ストリーミングをサポートするものもあります。ストリーミングがサポートされている場合は、MTA が一度に複数の要求を発行し、それぞれに対する応答をバッチで受け取ることができます。streaming キーワードは、チャネルに関連付けられたプロトコルのストリーミングの程度を制御するキーワードです。このキーワードには整数値のパラメータが必要です。パラメータの解釈は、プロトコルによって異なります。

通常の環境では、ストリーミングサポートが可能な範囲は SMTP パイプライン拡張でネゴシエートされます。このキーワードは、通常の環境で使用されることがありません。

ストリーミング値の範囲は 0 から 3 までです。値が 0 の場合はストリーミングが指定されず、値が 1 の場合は RCPT TO コマンドグループがストリーミングされ、2 の場合は MAIL FROM/RCPT TO が、3 の場合は HELO/MAIL FROM/RCPT TO または RSET/MAIL FROM/RCPT TO がストリーミングされます。デフォルトは 0 です。

TCP/IP 接続と DNS 検索のサポート

サーバーによる TCP/IP 接続およびアドレス検索の処理方法を指定することができます。この項では、次の内容について説明します。

• 「TCP/IP ポート番号とインタフェースアドレス」

• 「チャネル接続情報のキャッシング」

• 「リバース DNS 検索」

• 「IDENT 検索」

• 「TCP/IP MX レコードのサポート」

• 「ネームサーバー検索」

• 「最後のホスト」

• 「着信メール用代替チャネル (切り替えチャネル)」

• 「ターゲットホストの選択」

表 12–22 に、この項で説明されている TCP/IP 接続および DNS 検索に関連するキーワードの一覧を示します。

TCP/IP ポート番号とインタフェースアドレス

キーワード: port、interfaceaddress

通常、SMTP 実装 TCP/IP チャネルは、ポート 25 に接続してメッセージを送信します。SMTP 実装 TCP/IP チャネルがその他のポートを使用するように指定するには、port キーワードを使用します。このキーワードは、PORT ディスパッチャオプション (SMTP 接続を受け入れるために MTA が待機するポートを制御するオプション) を補足するものです。

interfaceaddress キーワードは、TCP/IP チャネルが送信時にソースアドレスとしてバインドするアドレスを制御します。つまり、複数のインタフェースアドレスが存在するシステム上で、MTA が SMTP メッセージを送信する際にどのアドレスをソース IP アドレスとして使用するかを制御するキーワードです。このキーワードは、INTERFACE_ADDRESS ディスパッチャオプション (接続およびメッセージを受け入れるために TCP/IP チャネルが待機するインタフェースアドレスを制御するオプション) を補足するものです。

チャネル接続情報のキャッシング

キーワード: cacheeverything、nocache、cachefailures、cachesuccesses

SMTP プロトコルを使用するチャネルは、過去の接続試行の履歴を含むキャッシュを管理しています。このキャッシュは、アクセスできないホストに繰り返し接続しようとして時間を浪費し、ほかのメッセージの配信が遅延されることを回避するために使用されます。このキャッシュは送信 SMTP チャネルが動作中の間のみ維持され、動作が終了するたびに削除されます。

通常、キャッシュには、成功した接続試行と失敗した接続試行の両方に関する情報が記録されます。(成功した試行は、その後失敗する試行を相殺するために記録される。すなわち、一度接続に成功したホストがその後失敗しても、はじめて試行する接続や以前失敗した接続ほど次の接続試行が遅れることはない。)

ただし、MTA が使用するキャッシング方法がすべての状況に適しているというわけではありません。そこで、チャネルキーワードを使用して MTA キャッシュを調整します。

cacheeverything キーワードは、すべての形式のキャッシングを有効にします。デフォルト設定ではこのキーワードが使用されます。nocache キーワードは、すべてのキャッシングを無効にします。

cachefailures キーワードは、失敗した接続のキャッシングだけを有効にします。このキーワードを使用すると、次の試行は cacheeverything を使用した場合より多くの制約を受けることになります。cachesuccesses は成功した接続だけをキャッシュします。このキーワードは、SMTP チャネルに対する nocache キーワードと同等のものです。

リバース DNS 検索

キーワード: forwardchecknone、forwardchecktag、 forwardcheckdelete

forwardchecknone、forwardchecktag、および forwardcheckdelete チャネルキーワードは、リバース DNS 検索の影響を修正します。これらのキーワードは、MTA が DNS リバース検索によって検出された IP 名の正引き検索を実行するかどうか、および実行する場合には正引き検索の結果がオリジナルの接続の IP 番号と一致しなかった場合にどのように対処するかを制御します。

デフォルト設定では forwardchecknone キーワードが有効になっているため、正引き検索は実行されません。forwardchecktag キーワードは、リバース検索が行われるたびに正引き検索を実行し、検出された番号がオリジナルの接続の番号と一致しない場合は IP 名にアスタリスク (*) を付けるように指定します。forwardcheckdelete キーワードは、リバース検索が行われるたびに正引き検索を実行し、リバース検索で返された名前の正引き検索がオリジナルの接続の IP アドレスに一致しなかった場合はリバース検索で返された名前を無視 (削除) するように、MTA に指示します。この場合、MTA はオリジナルの IP アドレスを使用します。

複数の IP アドレスに 「一般的な」IP 名が使用されているサイトの場合、正引きの結果がオリジナルの IP アドレスと一致しないのは比較的頻繁に見られる現象です。

IDENT 検索

キーワード: identnone、identnonelimited、identtnonnumeric、identnonesymbolic、identtcp、identtcpnumeric、identtcpsymbolic、 identtcplimited

IDENT キーワードは、MTA が IDENT プロトコルを使用して接続や検索を処理する方法を制御します。IDENT プロトコルは、RFC 1413 で規定されています。

identtcp、identtcpsymbolic、および identtcpnumeric キーワードは、MTA が接続や検索に IDENT プロトコルを使用するように指定するものです。IDENT プロトコルから入手した情報 (通常、SMTP 接続を使用しているユーザーの ID) は、次のようにメッセージの Received: ヘッダー行に挿入されます。

• identtcp は着信した IP 番号に呼応するホスト名 (DNS リバース検索で検出された名前) および IP 番号そのものを挿入します。

• identtcpsymbolic は着信した IP 番号に呼応するホスト名 (DNS リバース検索で検出された名前) を挿入します。IP 番号そのものは Received: ヘッダーに挿入されません。

• identtcpnumeric は着信した IP 番号を挿入します。リバース DNS 検索は実行されません。

identtcp、identtcpsymbolic、または identtcpnumeric による IDENT 検索が役に立つのは、リモートシステムで IDENT サーバーが稼働している場合です。

IDENT クエリの試行でパフォーマンスヒットが発生する場合があります。そうすると、ルーターは認識できないポートへの接続試行を次第に「ブラックホール化」するようになります。IDENT 検索でこのような状況が発生した場合は、接続がタイムアウトするまで MTA には応答が返されません (通常、このタイムアウトは TCP/IP スタックが制御するもので、1、2 分ほどかかる)。

別のパフォーマンスの問題が、identtcp、indenttcplimited、あるいは identtcpsymbolic を identtcpnumeric と比較するときにも発生します。identtcp、identtcplimited、または identtcpsymbolic によって DNS リバース検索が実行された場合、よりユーザーフレンドリーなホスト名を返すにはより長い時間が必要になります。

identnone キーワードは IDENT 検索を無効にしますが、IP からホスト名への変換は行われます。メッセージの Received: ヘッダーには IP 番号とホスト名の両方が含まれます。

identnonesymbolic キーワードは IDENT 検索を無効にしますが、IP からホスト名への変換は行われます。メッセージの Received: ヘッダーにはホスト名だけが含まれます。

identnonenumeric キーワードは IDENT 検索を無効にし、DNS リバース検索の IP 番号からホスト名への変換を禁止します。また、Received: ヘッダーにユーザーフレンドリーではない情報を使用するため、パフォーマンスの向上につながる可能性もあります。これがデフォルトです。

IDENT 検索、リバース DNS 検索、Received: ヘッダーに表示する情報などに関し、identtcplimited キーワードは identtcp と、identnonelimited キーワードは identnone とそれぞれ同様の効果をもたらします。ただし、異なる点として、identtcplimited および identnonelimited の場合は、switchchannel キーワードの影響で、DNS リバース検索によってホスト名が検出されたかどうかにかかわらず常に IP リテラルアドレスがチャネルスイッチのベースとして使用されます。

TCP/IP MX レコードのサポート

キーワード: mx、nomx、defaultmx、randommx、nonrandommx

TCP/IP ネットワークには、MX (メールの転送) レコードの使用をサポートするものとしないものがあります。MTA システムの接続先であるネットワークから提供される MX レコードだけを使用するように設定できる TCP/IP チャネルプログラムもあります。mx、nomx、defaultmx、randommx、nonrandommx キーワードは MX レコードのサポートを制御します。

randommx キーワードは、MX 検索を実行し、同等の優先順位を持つ MX レコード値を順不同で処理するように指定するものです。nonrandommx キーワードは、MX 検索を実行し、同等の優先順位を持つ MX レコード値を受信したとおりの順番で処理するように指定するものです。

現在のところ、mx キーワードは nonrandommx キーワードと同じものですが、将来のリリースでは randommx と同じになるように変更される可能性もあります。nomx キーワードは MX 検索を無効にします。defaultmx キーワードは、ネットワークが MX レコードをサポートする場合に mx を使用するように指定します。MX 検索をサポートするチャネルではすべて defaultmx キーワードがデフォルトとして設定されています。

ネームサーバー検索

キーワード: nameservers、defaultnameservers

ネームサーバー検索が実行される際、TCP/IP スタックが選択したネームサーバーの代わりに nameservers チャネルキーワードを使ってネームサーバーのリストを指定することができます。nameservers キーワードには、空白文字で区切られたネームサーバーの IP アドレスのリストが必要です。次の例を参照してください。

nameservers 1.2.3.1 1.2.3.2

デフォルト設定では defaultnameservers が有効になっているため、TCP/IP スタックの選択によるネームサーバーが使用されます。

UNIX でネームサーバー検索を禁止するには、nsswitch.conf ファイルを編集します。NT の場合は、TCP/IP 設定を変更します。

最後のホスト

キーワード: lastresort

lastresort キーワードは、ほかのホストへの接続試行がすべて失敗した場合に最終的な接続先となるホストを指定します。このキーワードは、事実上の最終手段的 MX レコードとして動作します。このキーワードは、SMTP チャネルに対してのみ効果があります。

このキーワードでは、「最終手段的システム」の名前を指定する単一のパラメータが必要です。例:

tcp_local single_sys smtp mx lastresort mailhub.siroe.com
TCP-DAEMON

着信メール用代替チャネル (切り替えチャネル)

キーワード: switchchannel、allowswitchchannel、 noswitchchannel。「SMTP 認証、SASL、TLS」の saslswitchchannel および 「Transport Layer Security」 の tlsswitchchannel も参照してください。

次の各キーワードは、着信メール用代替チャネルの選択を制御するものです。switchchannel、allowswitchchannel、noswitchchannel。

MTA がリモートシステムから 着信接続を受け付ける場合、MTA はその接続に関連付けるチャネルを選ぶ必要があります。通常、使用するチャネルは転送形式に基づいて決定されます。たとえば、TCP/IP を介する着信 SMTP 接続は、自動的に tcp_local チャネルに関連付けられます。

ただし、異なる性質を持つ複数の送信チャネルが複数のシステムに対して同時に使用される場合は、この限りではありません。この場合、着信と送信がそれぞれ異なるチャネルで行われるため、対応するチャネルの性質がリモートシステムに関連付けられません。

この問題は、switchchannel キーワードを使用することにより解決できます。サーバーが最初に使用するチャネルに switchchannel を指定すると、送信元ホストの IP アドレスがチャネルテーブルに照合され、一致した場合はソースチャネルがそれに合わせて切り替えられます。一致するものがない場合、または最初のデフォルト着信チャネルに一致するものが検出された場合は、MTA が リバース DNS 検索によって検出したホスト名に一致するエントリを見つけようと試みる場合もあります。ソースチャネルは switchchannel または allowswitchchannel にマークされているチャネルに切り替えられます (デフォルト)。noswitchchannel キーワードは、チャネルの切り替えを行わないように指定するためのものです。

デフォルトでは、サーバーが関連付けられているチャネル以外のチャネルに switchchannel を使用しても効果はありません。現在のところ、switchchannel を使用できるのは SMTP チャネルに対してのみですが、いずれにしても SMTP チャネル以外に switchchannel を使用すべきではありません。

ターゲットホストの選択

キーワード: daemon、single、single_sys

daemon キーワードの解釈と使用は、適用するチャネルの種類によって異なります。

daemon キーワードは、SMTP チャネル上でターゲットホストの選択を制御するために使用します。

通常、ホストへの接続に使用されているチャネルは、メッセージのエンベロープアドレスに表示されます。daemon キーワードは、エンベロープアドレスにどのチャネルが表示されているかにかかわらず、チャネルがファイアウォールやメールハブシステムなど特定のリモートシステムに接続するように設定します。実際のリモートシステム名は、次の例に示すように daemon キーワードの直後に表示されます。

tcp_firewall smtp mx daemon firewall.acme.com
TCP-DAEMON

daemon キーワードの後ろの引数が完全なドメイン名ではない場合、引数は無視され、チャネルは正規ホストに接続します。正規ホストは、チャネルに関連付けられている完全修飾ホスト名です。これは、3 行からなるチャネルブロックの 2 行目に指定できます。

tcp_firewall smtp mx daemon router
firewall.acme.com
TCP-DAEMON

正規ホストを 2 行からなるチャネルブロックの TCP-DAEMON のあとに指定して、送信接続がそれぞれの接続を特定のホストとして識別するようにもできます。

tcp_firewall smtp mx daemon router
TCP-DAEMON firewall.acme.com

ファイアウォールやゲートウェイシステムを正規ホスト名として指定する場合、次の例に示すように daemon キーワードに与えられる引数は、一般的にルーターとして指定されます。

tcp_firewall smtp mx daemon router
firewall.acme.com
TCP-DAEMON

また、関連するキーワードとして、single および single_sys があります。single キーワードは、各宛先アドレス用にメッセージのコピーを 1 つずつ作成するように指定します。single_sys キーワードは、各宛先システム用にメッセージのコピーを 1 つずつ作成します。どちらのキーワードを使用しても、メッセージがキューに入れられる各チャネルに最低 1 つずつメッセージのコピーが作成されることに注意してください。

SMTP 認証、SASL、TLS

キーワード: maysaslserver、mustsaslserver、nosasl、nosaslserver、saslswitchchannel、nosaslswitchchannel

Messaging Server が SASL (Simple Authentication and Security Layer) を使用したSMTP サーバーの認証をサポートするかどうかを指定できます。SASL は RFC 2222 で定義されています、SASL、SMTP 認証、およびセキュリティーの詳細については、第 19 章「セキュリティーとアクセス制御を設定する」を参照してください。

maysaslserver、mustsaslserver、nosasl、nosaslserver, switchchannel、および saslswitchchannel チャネルキーワードは、SMTP プロトコルが使用される際に、TCP/IP チャネルなどの SMTP チャネルによって SASL (SMTP AUTH) が使用されるように設定するためのものです。

デフォルト設定では nosasl が有効になっているため、SASL 認証は許可または試行されません。このキーワードは nosaslserver を包括するため、SASL 認証の使用はすべて禁止されます。maysaslserver を指定すると、SMTP サーバーは、クライアントが SASL 認証の使用を試行することを許可します。mustsaslserver を指定すると、SMTP サーバーは、クライアントが SASL 認証を使用することを要求します。SMTP サーバーは、リモートクライアントが認証に成功しないかぎり、メッセージを受け付けません。

クライアントが SASL の使用に成功したときに着信接続を指定のチャネルに切り替えるには、saslswitchchannel を使います。このキーワードには、切り替え先のチャネルを指定する必要があります。

ヘッダー内の SMTP AUTH から認証済みアドレスを使用する

キーワード: authrewrite

authrewrite チャネルキーワードと関連の AUTH_REWRITE マッピングテーブルを使用すると、認証動作で取得したアドレス情報に基づいてヘッダーとエンベロープアドレスを変更することができます。特に、SASL 認証で、認証された電子メールアドレスが提供されるように設定することができます。FROM_ACCESS マッピングによって無視されることもありますが、通常は SMTP AUTH 情報が使用されます。表 12–23 にあるように、authrewrite キーワードは必須のビット値をとります。

エンベロープおよびヘッダーアドレスの変更はほとんどの場合に正しく行われないため、$Z フラグは厳しく制限する必要があります。

Microsoft Exchange ゲートウェイチャネルを指定する

キーワード: msexchange、nomsexchange

msexchange チャネルキーワードは TCP/IP チャネルで使用して、MTA にこれが Microsoft Exchange ゲートウェイとクライアントとの通信を行うチャネルであることを指示できます。SASL に対応した (maysaslserver キーワード、または mustsaslserver キーワードを使用する) 着信 TCP/IP チャネルに配置されると、MTA の SMTP サーバーが、「誤った」形式 (オリジナルの ESMTP_AUTH 仕様に基づくもの。この仕様は、新しく適切な AUTH 仕様ではなく、適切な ESMTP 形式とは互換性がない) の AUTH を通知することになります。たとえば、Microsoft Exchange クライアントの中には、適切な AUTH 形式を認識せず、不正な AUTH 形式のみを認識するものがあります。

msexchange チャネルキーワードでも、破損した TLS コマンドを通知 (および認識) するようになります。

デフォルトは nomsexchange です。

Transport Layer Security

キーワード: maytls、maytlsclient、maytlsserver、musttls、musttlsclient、 musttlsserver、notls、notlsclient、 notlsserver、tlsswitchchannel

maytls、maytlsclient、maytlsserver、musttls、musttlsclient、musttlsserver、notls、notlsclient、notlsserver、および tlsswitchchannel チャネルキーワードは、TCP/IP チャネルなどの SMTP ベースのチャネルが SMTP プロトコルを使用するときに TLS をどのように処理するかを設定するためのキーワードです。

デフォルト設定では notls が有効になっているため、TLS は許可または試行されません。このキーワードは notlsclient (MTA SMTP クライアントは送信接続に TLS を使用しない。送信接続時に STARTTLS コマンドは発行されない) および notlsserver (MTA SMTP サーバーは着信接続時に TLS の使用を許可しない。SMTP サーバーもコマンド自体も STARTTLS 拡張に通知しない) を包括しています。

maytls が設定されている場合、MTA は TLS 使用の接続を受け入れ、送信接続にも TLS を使用しようと試みます。このキーワードは、maytlsclient (メッセージを送信する際に TLS をサポートする SMTP サーバーに送信するのであれば、MTA SMTP クライアントは TLS を使用する) および maytlsserver (MTA SMTP サーバーが STARTTLS 拡張をサポートすることを通知し、メッセージを着信する際に TLS を使用できる) を包括しています。

TLS が機能するためには、次の条件が整っている必要があります。

• mailsrv アカウントでファイルにアクセスできるように、証明書の保護と所有権が設定されている。

• 証明書が保存されているディレクトリに、mailsrv アカウントでその中のファイルにアクセスできるような保護と所有権が設定されている。

musttls キーワードを指定すると、MTA は送着信接続に必ず TLS を使用します。TLS の使用をネゴシエートできなかったリモートシステムとの電子メールの交換は許可されません。このキーワードは、musttlsclient を包括しているので、MTA SMTP クライアントはメッセージの送信に必ず TLS を使用し、TLS 使用のネゴシエーションが成功しない SMTP サーバーにはメッセージを送りません (MTA は STARTTLS コマンドを発行し、そのコマンドは必ず成功しなけらばならない)。また、このキーワードは musttlsserver も包括しているので、MTA SMTP サーバーは STARTTLS 拡張をサポートすることを通知し、着信メッセージを受け入れる際には必ず TLS を使用し、TLS の使用のネゴシエーションが成功しないクライアントからのメッセージは拒否します。

tlsswitchchannel キーワードは、クライアントが TSL 使用のネゴシエートに成功した場合、着信した接続を指定のチャネルに切り替えるためのキーワードです。このキーワードには、切り替え先のチャネルを指定する必要があります。