| 前へ 目次 索引 次へ | |
| iPlanet Messaging Server 5.1 管理者ガイド | |
第 8 章 チャネル定義を設定する
この章では、MTA 設定ファイル imta.cnf でチャネル定義を設定する方法について説明します。この章を読む前に第 6 章「MTA サービスと設定について」 の内容を理解しておくことをお勧めします。imta.cnf ファイルの書き換え規則の設定については、第 7 章「書き換え規則を設定する」 を参照してください。
チャネルの構造
チャネルの構造
チャネル定義は MTA 設定ファイルの後半部分、すなわち書き換え規則の後に記述されています。ファイル内の最初の空白行が書き換え規則の終了およびチャネル定義の開始を示しています。チャネル定義には、チャネル名、そのチャネルの設定を定義するキーワードリスト (オプション)、および、および特有のチャネルタグ (書き換え規則で使用される、メッセージをチャネルにルーティングするためのタグ) がこの順番で含まれています。それぞれのチャネル定義の間は 1 行の空白行によって区切られています。そのため、1 つのチャネル定義の中にコメント行を含めることはできますが、空白行を含めることはできません。
[空白行]
! チャネル定義の例
チャネル名 キーワード1 キーワード2
チャネル-タグ
[空白行]
チャネル定義は、まとめてチャネル ホストテーブルと呼ばれます。また、チャネルホストテーブルに含まれる個々のチャネル定義は、チャネルブロックと呼ばれます。図 8-1 に、3 つのチャネルブロックを含むチャネルホストテーブルの一例を示します。
図 8-1 簡単な設定ファイルの例 - チャネル定義
! test.cnf - 設定ファイルの例。
!
! 書き換え規則
.
.
.
! チャネル定義開始
! 第 1 チャネルブロック
l
local-host
! 第 2 チャネルブロック
a_channel defragment charset7 usascii
a-daemon
! 第 3 チャネルブロック
b_channel noreverse notices 1 2 3
b-daemon
チャネルホストテーブルは、Messaging Server が使用できるチャネルおよび各チャネルに関連付けられたシステムを定義するものです。
UNIX システムでは、第 1 チャネルブロックは常にローカルチャネル l の説明です (ただし、defaults チャネルは例外で、ローカルチャネルの前にくることがあります)。ローカルチャネルは、ルーティングの決定および UNIX メールツールを使用して送られたメールの配信に使用されます。
既定のチャネル
チャネルによっては iPlanet Messaging Server をインストールした時点ですでに定義されているものもあります。表 8-1 は、これらの既定チャネルのリストです。
チャネル
説明
UNIX のみ。メールを /var/mail に配信します (Messaging Server は /var/mail へのアクセスをサポートしていません。ユーザが /var/mail ストアのメールにアクセスするには、UNIX ツールを使う必要があります)。
サイト提供のプログラムやスクリプトを介してメールを配信するために使用されます。このパイプチャネルによって実行されるコマンドは、管理者が imsimta プログラムのインターフェースを通じて管理します。詳細については、「プログラム配信を設定する」を参照してください。
TCP/IP の上位プロトコルとして SMTP を実装します。マルチスレッド TCP SMTP チャネルには、ディスパッチャ制御下のマルチスレッド SMTP サーバが含まれます。送信された SMTP メールは、必要に応じてジョブコントローラの制御下で動作し、チャネル プログラム tcp_smtp_client によって処理されます。
tcp_local はリモート SMTP ホストからのメールを受信します。メールを送信する場合は、smarhost/ファイアウォール設定が使われているかどうかによって、直接リモート SMTP ホストに送るか、またはスマートホストファイアウォールシステムに送ります。
tcp_intranet はイントラネット内のメールを送受信します。
tcp_auth は tcp_local のスイッチチャネルとして使用されます。認証されたユーザは、リレーブロックの制約を回避するため tcp_auth チャネルに移されます。
tcp_submit は、送信されたメッセージ (通常の場合はユーザエージェントからのメッセージ) を予約されている送信ポート 587 で受け入れます (RFC 2476 を参照)。
遅延メッセージのオフライン処理に使用されるチャネルです。通常、reprocess チャネルはソースまたは宛先チャネルとして公にされません。process チャネルは、他の MTA チャネルと同様、公にされます。
ディレクトリ内でのステータスが非アクティブまたは削除済みになっているユーザへのメッセージの処理に使用されます。通常、受信したメッセージを差出人に送り返し、カスタム返送メッセージを送ります。
SMTP チャネルを設定する
インストールの種類によっては、Messaging Server のインストール時に数種の SMTP チャネルが提供されます (tcp_local、tcp_intranet、tcp_submit、tcp_auth、および tcp_tas)。また、これらのチャネルの定義を変更したり、新規チャネルを作成することも可能です。
SMTP コマンドとプロトコルのサポート
SMTP コマンドとプロトコルのサポート
SMTP チャネルが EHLO、ETRN、VRFY などの SMTP コマンドをサポートするように指定することができます。また、チャネルが DNS ドメイン認証をサポートするかどうかや、どの文字を改行記号として受け入れるかなどを指定することも可能です。この項では、以下の内容について説明します。
チャネルプロトコル選択と改行記号
表 8-2 に、この項で説明されているキーワードのリストを示します。
チャネルプロトコル選択と改行記号
smtp および nosmtp キーワードは、チャネルが SMTP プロトコルをサポートするかどうかを指定するものです。smtp (またはその変形) は、すべての SMTP チャネルに対して必須のキーワードです。smtp_crlf、smtp_cr、smtp_crorlf、および smtp_lf は、MTA が改行記号として受け入れる文字シーケンスの種類を指定するために、SMTP チャネルに対して使用されます。smtp_crlf キーワードを使用すると、キャリッジリターン (CR) + ラインフィーダ (LF) のシーケンスのみが改行記号として認識されます。smtp_lf または smtp キーワードを使用すると、LF のみのターミネータが受け入れられます。また、smtp_cr を使用すると、CR のみのターミネータが受け入れられます。これらのオプションは、受信データにしか適用されません。
SMTP では 改行記号として CRLF が要求されるため、MTA は常に CRLF シーケンスを作成します。各種の smtp キーワードは、MTA がその他の改行記号を受け入れるかどうかを指定するだけのものです。たとえば、MTA が規定通りの SMTP メッセージだけを受け入れ、非標準的な改行記号を含むメッセージを拒否するように指定するには、stmp_crlf を使います。
EHLO コマンドのサポート
SMTP プロトコルは、その他のコマンドの使用のネゴシエーションを行うことができるよう拡張されています (RFC 1869)。これを利用するには、RFC 821 規定の HELO コマンドの代わりに、新しい EHLO コマンドを使用します。EHLO コマンドを受け取った 拡張SMTP サーバはサポートする拡張内容のリストを返します。拡張をサポートしないサーバにこのコマンドを発行した場合は、不明なコマンドエラーのメッセージが返され、エラーメッセージを受け取ったクライアントは折り返し HELO コマンドを送ります。このフォールバックは、サーバが拡張されているかどうかに関わらず機能します。ただし、サーバが RFC 821 に準拠した SMTP を実装していない場合は、問題が発生する可能性があります。特に、認識できないコマンドを受け取ると接続を遮断してしまうサーバもあります。
EHLO コマンドを受け取ったサーバが接続を遮断した場合、SMTP クライアントは HELO コマンドを発行して再接続を試みます。ただし、EHLO を受け取ったリモートサーバが接続を遮断するだけでなく、その他の問題を併発する場合は、クライアントが再接続できないこともあります。
ehlo、noehlo、および checkehlo チャネルキーワードは、このような情況に対処するためのキーワードです。ehlo キーワードは、MTA が最初の接続試行に EHLO コマンドを使用するように指定します。noehlo キーワードは EHLO コマンドの使用をすべて無効にします。checkehlo キーワードは、リモート SMTP サーバによって返された見出しに「ESMTP」文字列が含まれているかどうかを確認し、含まれている場合には EHLO を使用し、含まれていない場合には HELO を使用するように指示します。デフォルトでは、最初の接続試行に対する応答の見出しに「fire away」文字列が含まれている場合は HELO を使用し、それ以外の場合は EHLO を使用するように設定されています。このデフォルト設定は ehlo キーワードと checkehlo キーワードの中間的な効果を得るものであり、この設定を指定するためのキーワードは存在しないことに注意してください。
ETRN コマンドのサポート
RFC 1985 で規定されている ETRN コマンドは SMTP サービスの拡張を可能にするものです。このコマンドによって SMTP サーバがクライアントとの通信に基づいてメッセージキューの処理を開始し、指定のホストにメッセージを配信できるようになります。SMTP クライアントは ETRN を使用して、自分宛てのメッセージキューの処理を開始するようリモート SMTP サーバにリクエストできます。つまり、ETRN は SMTP クライアントがメッセージを受信できるようにリモート 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 はドメインによって確認されたチャネル名をエコーしません。
ETRN コマンドを発行する
sendetrn および nosendetrn チャネルキーワードは、MTA が SMTP 接続開始時に ETRN コマンドを送るかどうかを指定するキーワードです。デフォルト設定では nosendetrn が有効になっているため、MTA は ETRN コマンドを送りません。リモート SMTP サーバが ETRN コマンドをサポートする場合にのみ MTA が ETRN を発行するように指定するには、sendetrn キーワードを使用します。sendetrn キーワードの後ろには、メッセージの配信先となるシステムの名前を記述する必要があります。
VRFY コマンドのサポート
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 チャネルに適用されます。
DNS ドメイン確認
mailfromdnsverify を受信 TCP/IP チャネルに対して設定すると、MTA は SMTP MAIL FROM コマンドで指定されているドメインのエントリが DNS に存在するかどうかを確認し、エントリが存在しない場合にはメッセージを拒否します。デフォルト設定では nomailfromdnsverify が有効になっているため、この確認は行われません。ただし、返信用アドレスに対して DNS 確認を行うと、許可されるべきメッセージも拒否されてしまう可能性があることに注意してください (たとえば、正規のサイトでもそのドメイン名がまだ登録されていない場合や、DNS が適切に動作していない場合など)。これは、RFC 1123 の「Requirements for Internet Hosts (インターネットホストの必要条件)」で規定されている電子メール受信の心得に反する行為です。ただし、存在しないドメインから不特定多数宛てのメール (UBE) が送られる場合は、この確認を行った方がよい場合もあります。
文字セットのラベル
charset7、charset8、および charsetesc チャネルキーワードは、文字セットのラベルが欠如しているメッセージヘッダに文字セット名を挿入するメカニズムをチャネルごとに提供するキーワードです。これらのキーワードを使用する場合は、単一の文字セット名を引数として指定する必要があります。文字セット名が正しいかどうかの確認は行われません。文字セットの変換は、MTA テーブルディレクトリ内の文字セット定義ファイル charsets.txt で定義されている文字セットに対してのみ可能であることに注意してください。できるだけこのファイルで定義されている名前を使用することをお勧めします。メッセージに含まれるのが 7 ビットデータのみの場合は charset7 を、8 ビットデータが含まれる場合は charset8 を使用します。charsetesc は、メッセージに 7 ビットデータおよびエスケープ文字が含まれる場合に使用します。適切なキーワードが指定されていない場合は、Content-type: ヘッダ行に文字セット名が挿入されません。
これらの文字セット指定が既存のラベルより優先されることはありません。メッセージにすでに文字セットラベルが含まれている場合やメッセージがテキストでない場合、これらのキーワードは効果をもたらしません。
charsetesc キーワードは、特に日本語や韓国語の文字セットを使用し、エスケープ文字を含むラベルなしのメッセージを受信するチャネルに便利です。
8 ビットデータ
127 (10進) 以上の序数値を持つ文字の使用は制限される場合があります。特に、SMTP サーバの中には、高ビットを切り捨てるために 8 ビット領域の文字を含むメッセージの文字化けの原因となるものもあります。Messaging Server は、そのようなメッセージを自動的にエンコードし、8 ビットデータがメッセージに直接表示されないようにする機能を備えています。特定のチャネルのキューに入れられるすべてのメッセージにエンコードを適用するには、sevenbit キーワードを使用します。そのような制約がない場合は、eightbit を使用します。
リモート SMTP サーバが 8 ビットをサポートすると明示していない限り、SMTP プロトコルは 8 ビットを許可しません。ただし、拡張 SMTP などの場合は、8 ビット文字の転送が可能かどうかのネゴシエーションを行って決定することもあります。ネゴシエートが失敗した場合に備えて、eightnegotiate キーワードを使用し、チャネルがメッセージをエンコードするよう指定しておくことを強くお勧めします。デフォルト設定ではすべてのチャネルに対してこのキーワードが有効になっているため、ネゴシエーションをサポートしないチャネルは 8 ビットデータの転送が可能であるという仮定のもとに動作します。
Messaging Server がネゴシエーションされていない 8 ビットデータを含むメッセージをすべて拒否するように設定するには、eightstrict キーワードを使用します。
プロトコルストリーミング
メールプロトコルによっては、ストリーミングをサポートするものもあります。ストリーミングがサポートされている場合は、MTA が一度に複数のリクエストを発行し、それぞれに対する応答をバッチで受け取ることができます。streaming は、チャネルに関連付けられたプロトコルのストリーミングの程度を制御するキーワードです。このキーワードには整数値のパラメータが必要です。パラメータの解釈は、プロトコルによって異なります。現時点で MTA がサポートしているのは SMTP チャネル上の試験的なストリーミングだけです。この機能は試験的なもので、将来のリリースで変更される可能性があります。
ストリーミング値の範囲は 0 から 3 までです。値が 0 の場合はストリーミングが指定されず、値が 1 の場合は RCPT TO コマンドグループがストリーミングされ、2 の場合は MAIL FROM/RCPT TO が、3 の場合は HELO/MAIL FROM/RCPT TO または RSET/MAIL FROM/RCPT TO がストリーミングされます。デフォルト値は 0 です。
SMTP 実装ソフトの中には、このストリーミングを必ずしも適切に処理できないものもあります。特に、sendmail は 1 以上のストリーミングレベルを処理できないと言われています。一方、iPlanet Messaging Server はすべてのストリーミングレベルに適切に対応しています。
TCP/IP 接続と DNS 検索のサポート
サーバによる TCP/IP 接続およびアドレス検索の処理方法を指定することができます。この項では、以下の内容について説明します。
TCP/IP ポート番号とインターフェースアドレス
表 8-3 に、この項で説明されている TCP/IP 接続および DNS 検索に関連するキーワードのリストを示します。
TCP/IP ポート番号とインターフェースアドレス
通常、TCP/IP 上に実装された SMTP チャネルは、ポート 25 に接続してメッセージを送信します。SMTP 実装 TCP/IP チャネルがその他のポートを使用するように指定するには、port キーワードを使用します。このキーワードは、PORT ディスパッチャオプション (SMTP 接続を受け入れるために MTA がリッスンするポートを制御するオプション) を補足するものです。interfaceaddress キーワードは、TCP/IP チャネルが送信時にソースアドレスとしてバインドするアドレスを制御します。つまり、複数のインターフェースアドレスが存在するシステム上で、MTA が SMTP メッセージを送信する際にどのアドレスをソース IP アドレスとして使用するかを制御するキーワードです。このキーワードは、INTERFACE_ADDRESS ディスパッチャオプション (接続およびメッセージを受け入れるために TCP/IP チャネルがリッスンするインターフェースアドレスを制御するオプション) を補足するものです。
チャネル接続情報のキャッシング
SMTP プロトコルを使用するチャネルは、過去の接続試行の履歴を含むキャッシュを管理しています。このキャッシュは、アクセスできないホストに繰り返し接続しようとして時間を浪費し、他のメッセージの配信が遅延されることを回避するために使用されます。このキャッシュは送信 SMTP チャネルが動作中の間のみ維持され、動作が終了するたびに削除されます。通常、キャッシュには、成功した接続試行と失敗した接続試行の両方に関する情報が記録されます (成功した試行は、その後失敗する試行を相殺するために記録されます。すなわち、一度接続に成功したホストがその後失敗しても、初めての試行する接続や以前失敗した接続ほど次の接続試行が遅れることはありません)。
ただし、MTA が使用するキャッシング方法がすべての情況において適切であるとは限りません。そこで、チャネルキーワードを使用して MTA キャッシュを調整します。
cacheeverything キーワードは、すべての形式のキャッシングを有効にします。デフォルト設定ではこのキーワードが使用されます。nocache キーワードは、すべてのキャッシングを無効にします。
cachefailures キーワードは、失敗した接続のキャッシングだけを有効にします。このキーワードを使用すると、次の試行は cacheeverything を使用した場合より多くの制約を受けることになります。cachesuccesses は成功した接続だけをキャッシュします。このキーワードは、SMTP チャネルに対する nocache キーワードと同等のものです。
DNS 検索
forwardchecknone、forwardchecktag、および forwardcheckdelete チャネルキーワードは、リバース DNS 検索の影響を修正します。これらのキーワードは、MTA が リバース DNS 検索によって検出された IP 名のフォワード検索を実行するかどうか、および実行する場合にはフォワード検索の結果が最初の IP 番号と一致しなかった場合にどのように対処するかを制御します。デフォルト設定では forwardchecknone キーワードが有効になっているため、フォワード検索は実行されません。forwardchecktag キーワードは、リバース検索が行われる度にフォワード検索を実行し、検出された番号が最初の接続の番号と一致しない場合は IP 名にアスタリスク (*) を付けるように指定します。forwardcheckdelete キーワードは、リバース検索が行われる度にフォワード検索を実行し、その結果が最初の接続の IP アドレスと一致しなかった場合はリバース検索によって検出された名前を無視 (削除) して最初の IP アドレスを使用するように指定します。
注 複数の IP アドレスに「一般的な」IP 名が使用されているサイトの場合、フォワード検索の結果が最初の IP アドレスと一致しないのは比較的頻繁に見られる現象です。
IDENT 検索
IDENT キーワードは、MTA が IDENT プロトコルを使用して接続や検索を処理する方法を制御します。IDENT プロトコルは、RFC 1413 で規定されています。identtcp、identtcpsymbolic、および identtcpnumeric キーワードは、MTA が接続や検索に IDENT プロトコルを使用するように指定するものです。IDENT プロトコルを使用して得た情報 (通常、SMTP 接続を使用しているユーザの ID) は、以下のようにメッセージの Received: ヘッダに挿入されます。
identtcp は 受信した IP 番号に呼応するホスト名 (リバース DNS 検索で検出された名前) および IP 番号そのものを挿入します。
identtcpsymbolic は、受信した IP 番号に呼応するホスト名 (リバース DNS 検索で検出された名前) を挿入します。ただし、IP 番号は Received: ヘッダには含まれません。
注 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: ヘッダにユーザフレンドリーではないホスト名を使用するため、パフォーマンスの向上につながる可能性もあります。
identtcplimited および identnonelimited キーワードは、IDENT 検索、リバース DNS 検索、Received: ヘッダに表示する情報などに関し、identtcp および identnone と同様の効果をもたらします。ただし、異なる点として、identtcplimited および identnonelimited の場合は、switchchannel キーワードの影響で、リバース DNS 検索によってホスト名が検出されたかどうかに関わらず常に IP リテラルアドレスがチャネルスイッチのベースとして使用されます。
TCP/IP MX レコードのサポート
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 キーワードがデフォルトとして設定されています。
ネームサーバ検索
ネームサーバ検索が実行される際、TCP/IP スタックが選択したネームサーバの代わりに nameservers チャネルキーワードを使ってネームサーバのリストを指定することができます。nameservers キーワードには、空白文字で区切られたネームサーバの IP アドレスのリストが必要です。以下の例を参照してください。デフォルト設定では defaultnameservers が有効になっているため、TCP/IP スタックの選択によるネームサーバが使用されます。
UNIX でネームサーバ検索を禁止するには、nsswitch.conf ファイルを編集します。NT の場合は、TCP/IP 設定を変更します。
最後のホスト
lastresort キーワードは、「最後のホスト」つまり他のホストへの接続試行がすべて失敗した場合に最終的な接続先となるホストを指定します。このキーワードは、事実上の最終手段的 MX レコードとして動作します。このキーワードは、SMTP チャネルに対してのみ効果があります。
メール受信用代替チャネル
次の各キーワードは、メール受信用代替チャネルの選択を制御するものです :switchchannel、allowswitchchannel、および noswitchchannel。MTA がリモートシステムの受信接続を許可するには、どのチャネルで接続を確立するかを決定する必要があります。通常、使用するチャネルは転送形式に基づいて決定されます。たとえば、リモートシステムが TCP/IP の上位プロトコルとして SMTP を実装している場合は、自動的に tcp_local チャネルで接続が確立されます。
ただし、異なる性質を持つ複数の送信チャネルが複数のシステムに対して同時に使用される場合は、受信接続と送信接続がそれぞれ異なるチャネルで行われるため、対応するチャネルの性質がリモートシステムに関連付けられません。
この問題は、switchchannel キーワードを使用することにより解決できます。サーバが最初に使用するチャネルに switchchannel を指定すると、送信元ホストの IP アドレスがチャネルテーブルに照合され、一致した場合はソースチャネルがそれに合わせて切り替えられます。一致するものがない場合、または最初のデフォルト受信チャネルに一致するものが検出された場合は、MTA が リバース DNS 検索によって検出したホスト名に一致するエントリを見つけようと試みる場合もあります。ソースチャネルは switchchannel または allowswitchchannel にマークされているチャネルに切り替えられます (デフォルト)。noswitchchannel キーワードは、チャネルの切り替えを行わないよう指定します。
デフォルトでは、サーバが関連付けられているチャネル以外のチャネルに switchchannel を使用しても効果はありません。現在のところ、switchchannel を使用できるのは SMTP チャネルに対してのみですが、いずれにしても SMTP チャネル以外に switchchannel を使用すべきではありません。
ターゲットホストの選択
daemon キーワードは、SMTP チャネル上でターゲットホストの選択を制御するために使用します。通常、ホストへの接続に使用されているチャネルは、メッセージのエンベロープアドレスに表示されます。daemon キーワードは、エンベロープアドレスにどのチャネルが表示されているかに関わらず、チャネルがファイヤウォールやメールハブシステムなど特定のリモートシステムに接続するように設定します。実際のリモートシステム名は、以下の例に示すように daemon キーワードの直後に記述します。
tcp_firewall smtp mx daemon firewall.acme.com
TCP-DAEMONdaemon キーワードの後ろの引数が完全なドメイン名ではない場合、引数は無視され、チャネルは正規ホストに接続します。ファイヤウォールやゲートウェイシステムを正規ホストにする場合は、以下の例に示すように daemon キーワードの引数を router として指定します。
tcp_firewall smtp mx daemon router
firewall.acme.com
TCP-DAEMONまた、関連するキーワードとして、single および single_sys があります。single キーワードは、チャネルの各宛先アドレス用にメッセージのコピーを 1 つずつ作成するように指定します。single_sys キーワードは、各宛先システム用にメッセージのコピーを 1 つずつ作成します。どのキーワードを使用しても、メッセージがキューに入れられる各チャネルごとに最低 1 つずつメッセージのコピーが作成されることに注意してください。
SMTP 認証と SASL
Messaging Server が SASL (Simple Authentication and Security Layer) を使用した SMTP サーバの認証をサポートするかどうかを指定できます。SASL については、RFC 2222 で規定されています。SASL、SMTP 認証、およびセキュリティの詳細については、第 11 章「セキュリティとアクセス制御を設定する」 を参照してください。表 8-4 に、この項で説明している SASL に関連するキーワードのリストを示します。
TLS (Transport Layer Security)
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 (MTA SMTP クライアントは TLS をサポートする。SMTP サーバにメッセージを送信する際に TLS を使用する) および maytlsserver (MTA SMTP サーバが STARTTLS 拡張をサポートすることを通知し、メッセージを受信する際に TLS を使用する) を包括しています。
musttls キーワードは、MTA が送受信接続に必ず TLS を使用するように指定します。TLS 使用のネゴシエーションを行うことができなかったリモートシステムとの電子メールの交換は許可されません。このキーワードは、musttlsclient (MTA SMTP クライアントはメッセージの送信に必ず TLS を使用し、TLS の使用のネゴシエーションが成功しない。SMTP サーバにメッセージを送らない。MTA 発行の STARTTLS コマンドは必ず成功しなければならない) および musttlsserver (MTA SMTP サーバが STARTTLS 拡張をサポートすることを通知し、TLS 使用のメッセージを受け入れる。TLS の使用のネゴシエーションが成功しないクライアントからのメッセージは拒否される) を包括しています。
tlsswitchchannel キーワードは、クライアントが TSL 使用のネゴシエートに成功した場合、受信した接続を指定のチャネルに切り替えるためのキーワードです。このキーワードには、切り替え先のチャネルを指定する必要があります。
チャネル動作のタイプ
Messaging Server は、RFC 2476 規定のメッセージ 送信プロトコルをサポートしています。チャネルを送信専用に設定するには、submit キーワードを使用します。これは、送信専用のポートで動作する SMTP サーバなどの TCP/IP チャネルに対して便利なキーワードです。RFC 2476 は送信専用としてポート 587 を規定しています。
メッセージの処理と配信を設定する
サーバが特定の条件に基づいてメッセージの配信を試みるように指定できます。また、サービスジョブの処理制限や、新しい SMTP チャネルスレッドを作成するタイミングなど、ジョブ処理に関するパラメータを指定することも可能です。この項では、以下の内容について説明します。表 8-5 に、この項で説明しているキーワードのリストを示します。
メッセージの配信
メッセージがチャネルのキューに入る度に、ジョブコントローラはメッセージが確実に配信されるよう新しいジョブプロセスの開始、スレッドの追加、ジョブ実行の確認などを行います。チャネルやプールのジョブ数が制限に達しているために新しいジョブを開始できない場合は、実行中のジョブが終了するのを待って、ジョブ数が制限以下になったら新しいジョブを開始します。チャネルのジョブ数制限は maxjobs チャネルキーワードによって決定され、プールのジョブ数制限は JOB_LIMIT プールオプションによって決定されます。Messaging Server はすべてのメッセージの即時配信を試みます。最初の試行でメッセージを配信できない場合は、該当する backoff キーワードに基づいて配信遅延時間が決定されます。遅延メッセージは backoff キーワードが指定する時間が経過したときに配信され、必要に応じてメッセージを処理するチャネルジョブが開始されます。
チャネルジョブを作成および管理するのはジョブコントローラであり、チャネルジョブはジョブコントローラの処理プール内で実行されます。プールの詳細については、「チャネル実行ジョブの処理プール」を参照してください。
ジョブコントローラのメモリ内における処理中メッセージおよび処理待ちメッセージに関するデータの構造は、ディスクの MTA キュー領域に保存されているメッセージファイル全体の構造を反映しています。ただし、ディスク上のメッセージファイルのバックログがジョブコントローラのメモリ内データ構造のサイズ制限を超過するほど大きくなると、ジョブコントローラはディスク上のメッセージファイルの一部だけをトラックし、トラックしているメッセージだけを処理するようになります。メッセージを配信してメモリに余裕ができると、ジョブコントローラは MTA キュー領域をスキャンしてメモリ内の保存情報をリフレッシュし、メッセージのリストを更新し、ディスクから読み込んだメッセージの処理を開始します。ジョブコントローラは自動的に MTA キュー領域のスキャンを実行します。
メッセージのバックログが頻繁に発生する場合は、MAX_MESSAGES オプションを使用してジョブコントローラを調整します。MAX_MESSAGES オプションの値を大きくするとジョブコントローラはより多くのメモリを使用できるようになるため、メッセージのバックログによるジョブコントローラのメモリ内キャッシュのオーバーフローを回避できます。このため、ジョブコントローラが MTA キューディレクトリをスキャンするのに必要な時間を短縮できます。ただし、ジョブコントローラがメモリ内キャッシュを再構築する必要がある場合は、キャッシュのサイズが大きいために比較的長時間かかることに注意してください。また、ジョブコントローラは起動 (または再起動)する度に MTA キューディレクトリをスキャンします。メッセージのバックログが大きい場合は、バックログが小さい場合に比べて、ジョブコントローラの起動 (または再起動) にも時間がかかることに注意してください。
チャネル実行ジョブの処理プール
複数のチャネルが 1 つのプール内で動作するように設定すると、複数のチャネルが同じプールのリソースを共有できるようになります。特定のチャネル専用に指定されているプール内で他のチャネルが動作するように設定することも可能です。各プール内のメッセージは優先度に基づいて自動的に適切な処理キューに割り当てられ、優先度の高い順に処理されます。詳細については、「サイズに基づくメッセージの優先度」を参照してください。pool キーワードを使用すると、ジョブが作成されるプールをチャネルごとに指定できます。pool キーワードの後ろには、カレントチャネルの配信ジョブのプール先となるプール名を指定する必要があります。プール名の文字数の上限は 12 文字です。
サービスジョブを遅らせるには、after キーワードを使います。after キーワードの後ろには、遅延時間の長さを記述する必要があります。遅延時間に符号なし整数を使用すると、その値はデルタタイム値、つまりメッセージの遅延配信時間までの秒数として認識されます。
サービスジョブの制限
メッセージがチャネルのキューに入る度に、ジョブコントローラはメッセージが確実に配信されるよう新しいジョブプロセスの開始、スレッドの追加、ジョブ実行の確認などを行います。しかし、1 つのサービスジョブではすべてのメッセージを手際よく配信できない場合もあります。メッセージ配信のために開始されるプロセスやスレッドの数には、妥当な制限があります。このプロセスやスレッド数の上限は、プロセッサの数、ディスクの速度、接続の性質などによって決定されます。MTA 設定ファイルでは、以下のものを制御することができます。
1 つのチャネルに対して開始できるプロセス数の上限 (maxjobs チャネルキーワード)
1 つのチャネルに対して開始されるプロセス数の上限は、そのチャネルに対して設定されている maxjobs、またはチャネルが動作しているプールに対して設定されている JOB_LIMIT の最小値に当たります。1 つのチャネルセットに対して開始できるプロセス数の上限 (ジョブコントローラ設定ファイルの該当するプールセクションに設定されている JOB_LIMIT パラメータ)
新しいスレッドまたはプロセスを開始する前に受信したキュー内のメッセージ数 (threaddepth チャネルキーワード)
チャネルによっては、特定の配信プログラム内で実行するスレッド数の上限 (チャネル オプションファイル内の max_client_threads パラメータ)
処理すべきメッセージがある場合、ジョブコントローラは以下の基準に基づいて新しいプロセスを開始します。
チャネルに対してプロセスが実行されておらず、プールのジョブ数が制限に達していない場合は、新しいプロセスを開始します。
特に、SMTP チャネルに対しては、異なるホスト宛てのメッセージがキューに入るにつれて新しいスレッドやプロセスが開始されます。処理すべきメッセージがある場合ジョブコントローラは、SMTP チャネルに対し、以下の基準に基づいて新しいプロセスを開始します。チャネルプログラムがシングルスレッドの場合、またはスレッド数が制限に達していて threaddepth で指定されている以上のバックログがあり、かつチャネルとプールのジョブ数が共に制限に達していない場合は、新しいプロセスを開始します。
チャネルプログラムがマルチスレッドで、スレッド数が制限に達しておらず、かつ threaddepth で指定されている以上のバックログがある場合は、新しいスレッドが開始されます。
SMTP チャネルに対して実行されているプロセスがなく、プールのジョブ数が制限に達していない場合は、新しいプロセスが開始されます。
詳細については、「SMTP チャネルスレッド」を参照してください。スレッド数が制限に達しており (MAX_CLIENT_THREADS)、サービス待ち状態のホスト宛てのメッセージがキューに入り、かつチャネルのジョブ数 (maxjobs) およびプールのジョブ数 (JOB_LIMIT) が共に制限に達していない場合は、新しいプロセスが開始されます。
スレッド数が制限に達しておらず、サービス待ち状態のホスト宛てのメッセージがキューに入った場合は、新しいスレッドが開始されます。
スレッド数が制限に達しておらず、メッセージがキューに入ったためにそのホスト宛てのメッセージのバックログが threaddepth で指定されている以上の数になった場合は、新しいスレッドが開始されます。
filesperjob キーワードを使うと、MTA に追加のサービスジョブを作成するよう指示することもできます。このキーワードには、正の整数を 1 つパラメータとして設定する必要があります。この整数は、複数のサービスジョブを作成するため関連するにチャネルが受け取らなくてはならないキューエントリ (ファイル) の数を指定します。パラメータに 0 またはそれ以下の値を設定すると、サービスジョブは 1 つしか作成されません。キーワードが設定されていない場合は、パラメータの値が 0 であると認識されます。また、実際に作成されるサービスジョブの数は、チャネルが受け取ったキューエントリの合計数によって決定されます。
filesperjob キーワードは、実際のキューエントリ (ファイル) 数を指定値で割って作成するジョブ数を算出します。各メッセージのキューエントリ数は、single や single_sys キーワード、メーリングリストのヘッダ修正アクション、そのほかさまざまな要素によって決定されます。
maxjobs キーワードは、同時実行可能な合計ジョブ数を制限します。maxjobs キーワードの後ろには、整数値を指定する必要があります。算出されたサービスジョブ数がこの値より大きい場合には、maxjobs ジョブだけが作成されます。maxjobs が使用されていない場合のデフォルト値は 100 に設定されています。通常、maxjobs には、そのチャネルが使用するプールまたはサービスプールで同時実行が可能な合計ジョブ数と同じ値、またはそれ以下の値を使用します。
サイズに基づくメッセージの優先度
urgentblocklimit、normalblocklimit、および nonurgentblocklimit キーワードは、サイズに基づいてメッセージの優先度を下げるように MTA に指定するためのものです。これらのキーワードは、ジョブコントローラがメッセージ処理時に適用する優先度に影響を及ぼします。
SMTP チャネルスレッド
マルチスレッドの SMTP クライアントは、メッセージを宛先ごとにそれぞれ異なるスレッドに割り当てるため、送信メッセージを並べ替えます。threaddepth キーワードは、マルチスレッドの SMTP クライアントが 1 つのスレッドに割り当てられるメッセージの数を制限し、それ以上のメッセージがある場合には別のスレッドに割り当てるよう指定します。通常、同じ宛先へのメッセージはすべて 1 つのスレッドによって処理されますが、このキーワードが設定されている場合はそれらのメッセージが複数のスレッドによって処理されるようになります。threaddepth キーワードは、チャネルの接続先の SMTP サーバが複数の接続を同時に処理できる場合に、デーモン ルータ TCP/IP チャネル (ある特定の SMTP サーバに接続する TCP/IP チャネル) 上でマルチスレッドを確立する際に便利です。
チャネルに対するバックログが threaddepth で指定されている以上の数に達すると、ジョブコントローラはより多くのリソースをそのチャネルのキューにあるメッセージの処理に割り当てようとします。チャネルがマルチスレッドの場合、ジョブコントローラはメッセージを処理するジョブがそのチャネルに対して新しくスレッドを開始するように指示し、すべてのジョブのスレッド数がそのチャネルの制限に達している場合 (tcp_* チャネルの MAX_CLIENT_THREADS オプション) は、新しいプロセスを開始するように指示します。シングル スレッドのチャネルに対しては、新しいプロセスを開始するように指示します。ただし、チャネルのジョブ数 (maxjobs) またはプールのジョブ数 (JOB_LIMIT) が制限に達している場合、新しいジョブは開始されません。
複数アドレスの拡張
大部分のチャネルは複数の宛先アドレスを持つメッセージを受け入れますが、1 つのメッセージに複数の宛先アドレスが指定されていると、配信処理に遅延 (オンライン遅延) が生じます。遅延時間が長いとネットワークがタイムアウトが発生し、メッセージの重複送信やその他の問題が発生する可能性があります。MTA は、1 つのメッセージに特定数以上のアドレスが指定されている場合に配信を遅らせて処理 (オフライン処理) することができます。この方法によって、オンライン遅延を大きく軽減することが可能です。処理のオーバーヘッドを遅らせることはできますが、遅延を完全に回避することは不可能です。
この機能を有効にするには、たとえば一般的な reprocessing チャネルと expandlimit キーワードを使用します。expandlimit キーワードには、オフライン処理を開始するまでにチャネルから受け入れることのできるメッセージのアドレス週の上限を示す整数の引き数をとります。expandlimit キーワードが設定されていない場合、オフライン処理は行われません。引数の値を 0 にすると、そのチャネルで受信したすべてのメッセージがオフラインで処理されます。
expandlimit キーワードは、ローカルチャネルおよび reprocessing チャネルには使用できません。使用すると、予測できない事態が発生する可能性があります。
オフライン処理を行うチャネルを指定するには、expandchannel キーワードを使用します。特に設定を変更しない限り、expandchannel が設定されていない場合は reprocessing チャネルが使用されますが、特別な目的のためにはその他の reprocessing チャネルまたは processing チャネルを設定することもできます。expandchannel を使ってオフライン処理を行うチャネルを指定する場合、reprocessing チャネルまたは processing チャネル以外のチャネルを使用することはできません。その他のチャネルを使用すると、予測できない事態が発生する可能性があります。
expandlimit を適切に機能させるには、reprocessing チャネル (またはオフライン処理を実行するその他のチャネル) を MTA 設定ファイルに追加する必要があります。ただし、MTA 設定ユーティリティによって生成された設定ファイルを使用しているのであれば、その必要はありません。
非常に多くの宛先アドレスが指定されているのは、不特定多数宛てメールの特徴です。holdlimit キーワードは、MTA が特定数以上の宛先アドレスを持つメッセージを受信した場合、そのメッセージを .HELD メッセージとして reprocess チャネル (または expandchannel キーワードが指定するチャネル) のキューに入れるように指示します。メッセージは MTA postmaster が手動で介入するまで reprocess キュー内で未処理のまま待機します。
配信不能メッセージに対する通知発行のタイミング
notices、nonurgentnotices、normalnotices、および urgentnotices キーワードは、配信できないメッセージをチャネルキュー内に保持する時間の長さを制御するものです。Messaging Server は、差出人に繰り返し配信不能の警告メッセージを送ることができます。それでもメッセージを宛先に配信できない場合、Messaging Server はそのメッセージを差出人に返送します。メッセージの優先度に基づいて異なる返送方法を適用するには、nonurgentnotices、normalnotices、または urgentnotices キーワードを使用します。これらのキーワードが設定されていない場合は、notices キーワードがすべてのメッセージに適用されます。
キーワードの後ろには、同じ間隔で増加する最高 5 つの整数値を指定できます。これらの値はメッセージが受信されてから警告メッセージが発行されるまでの時間を示すもので、MTA オプションファイル内で RETURN_UNITS が 0 に設定されている場合やオプションが設定されていない場合は、日単位として認識されます。RETURN_UNITS が 1 に設定されている場合は、時間単位として認識されます。
指定された最終時間に達してもメッセージを配信できない場合、そのメッセージは差出人に返送されます。それまでは、キーワードで指定した時間になる度に警告メッセージが送られます。特に設定を変更しない限り、notices キーワードが設定されていない場合は notices 設定が使用されます。notices 設定もない場合は、メッセージを受信してから 3 日後 (または 3 時間後)、6 日後 (または 6 時間後)、9 日後 (または 9 時間後)、12 日目（または 12 時間後）に警告メッセージが送られ、その後もメッセージキューに残っているメッセージが差出人に返送されます。
notices キーワードの構文に、ドット文字やカンマを使用する必要はありません。たとえば、デフォルトの返送ポリシーは以下のように設定されています。
全チャネルの通知発行のタイミングを一括して変更するには、MTA 設定ファイルのチャネルブロックセクションの冒頭に defaults チャネルブロックを追加するか、ローカルチャネルに notices 設定を追加するのが最も簡単な方法です。たとえば、以下のコマンドを使用すると、すべてのチャネルの通知発行タイミングを指定する defaults チャネルを追加できます。
defaults チャネルは、MTA 設定ファイル内にある最初の空白行の直後に記述します。
Postmaster 宛てのメッセージを設定する
長期間にわたってサービスが支障を来たしている場合や、アドレスが不正確な場合には、チャネルプログラムがメッセージを配信できないことがあります。その場合、MTA チャネルプログラムは、配信不能の理由を説明する文章と共に、メッセージを差出人に返送します。メッセージの返送に加えて、MTA は配信できないメッセージに関する詳細な情報を記載した警告メッセージを送ることがあります。通常、この警告メッセージは notices チャネル キーワードが指定するタイムアウトに基づいて送られますが、配信試行に失敗したときに送られることもあります。通知には、問題点の説明と配信試行を継続する時間枠が記載されます。また、多くの場合、該当するメッセージのヘッダと最初の数行も含まれます。
さらに、配信できないメッセージおよび警告メッセージのコピーをすべてローカル postmaster に送るように設定することも可能です。ただし、この設定を使用すると、メッセージの配信不能情況や各種キューの状態を監視するには便利ですが、postmaster 宛てのメッセージが非常に多くなる可能性があります。
表 8-6 に示すキーワードを使用して、postmaster 宛てのメッセージを制御することができます。
チャネルオプションを設定する
TCP/IP チャネルオプションファイルは、TCP/IP チャネルのさまざまな性質を制御するものです。チャネルオプションファイルは、x_option (x 部分は該当チャネル名) という名前で MTA 設定ディレクトリ内に保存されていなければなりません。以下に例を示します : /サーバ-インスタンス/imta/config/tcp_local_option。オプションファイルは、1 つまたは複数のキーワードとその関連値によって構成されています。たとえば、サーバのメーリング リスト拡張を無効にするには、オプションファイルに DISABLE_EXPAND キーワードを追加し、値を 1 に設定します。
また、その他のオプションファイルキーワードを使用すると、以下の制御を行うことができます。
メッセージあたりの宛先数を制限する (ALLOW_RECIPIENTS_PER_TRANSACTION)
チャネルオプションキーワードと構文の詳細については、『Messaging Server リファレンスマニュアル』を参照してください。セッションあたりのメッセージ数を制限する (ALLOW_TRANSACTIONS_PER_SESSION)
MTA ログファイルに記録される情報の内容を微調整する (LOG_CONNECTION, LOG_TRANPORTINFO)
チャネルのデフォルトを設定する
設定ファイルにはさまざまなチャネルキーワードが繰り返し記述されていることがありますが、このような設定を管理するには時間がかかり、エラーの原因にもなります。複数のチャネルに対してまとめてデフォルトのキーワードを指定すると、設定を簡素化することができます。たとえば、以下の行を設定ファイルに追加すると、行中で指定したキーワードがそれ以降のすべてのチャネルブロックに適用されます。
defaults キーワード1 キーワード2 キーワード3 ...
defaults 行はチャネルを特定せずにデフォルトのキーワードを変更するための特殊なチャネルブロックだと考えられます。また、defaults 行に他のチャネルブロック情報を指定する必要はありません (指定しても無視されます)。
1 つのファイルに使用できる defaults 行の数に上限はありません。複数の defaults 行を指定した場合、ファイルの下へ行くほど (後で追加した行ほど) 優先度が高くなります。
設定ファイル内のある位置 (たとえば、外部ファイルのチャネルブロックの独立したセクションの冒頭など) 以降には無条件に defaults 行が適用されないように設定しておく方がよい場合もあります。そのためには、nodefaults 行を使用します。たとえば、以下の行を設定ファイルに挿入すると、それ以前の部分で defaults を使って指定した設定がすべて無効になり、defaults を使用していないのと同じ状態に戻ります。
他のチャネルブロックと同様に、defaults や nodefaults チャネルブロックを使用する場合も、ブロック間の区切りには空白行を使用します。設定ファイル内でローカルチャネルの前に記述できるチャネルブロックは、defaults と nodefaults のみです。ただし、他のチャネルブロックと同様、書き換え規則の前に記述することはできません。
チャネルのログを設定する
MTA は、メッセージがキューに出し入れされる度にログを作成することができます。logging および nologging キーワードは、チャネルごとのメッセージログの作成を制御します。デフォルト設定では、すべてのチャネルに対してログが作成されます。特定のチャネルに対してログの作成を無効にするには、チャネル定義で logging の代わりに nologging キーワードを設定します。ログの詳細については、第 12 章「ログ記録とログ解析」を参照してください。
チャネルのデバッグを設定する
チャネルプログラムによっては、デバッグ目的のためにより詳細な診断出力を生成するオプションコードがあるものもあります。このチャネルごとのデバッグ出力を有効にするためのチャネルキーワードには2種類あります。master_debug キーワードはマスタープログラムのデバッグ出力を有効にし、slave_debug キーワードはスレーブプログラムのデバッグ出力を有効にします。デフォルト設定では nomaster_debug および noslave_debug が有効になっているため、デバッグ出力は生成されません。デバッグを有効にすると、デバッグ出力は各チャネルプログラムに関連付けられているログファイルに記述されます。ログファイルの場所はプログラムによって異なりますが、通常はログディレクトリにあります。マスタープログラムのログファイルの名前は、概して x_master.log (x はチャネル名) という形式になっています。スレーブプログラムのログファイル名の形式は、x_slave.log です。
プログラム配信を設定する
ユーザによっては、受信メールをメールボックスではなく メールソートプログラムや Vacation Notice などの自動返信エージェントに配信して欲しいと望む人もいます。pipe チャネルはサイト提供のユーザごとのプログラムを使用してメッセージを配信します。プログラム配信を有効化するには、まず pipe チャネルが呼び出せるプログラムを登録する必要があります。そのためには、imsimta program ユーティリティを使用して、pipe チャネルから呼び出し可能なコマンドとして登録したものにそれぞれ特有の名前を付けます。これによってエンドユーザが mailprogramdeliveryinfo LDAP 属性の値としてプログラム名を指定できるようになります。
たとえば、UNIX の myprocmail コマンドをユーザが呼び出せるプログラムとして追加するには、imsimta program ユーティリティを使用して以下の例のようにこのコマンドを登録します。この例では、-d ユーザ名 という引数を使用して procmail プログラムをユーザとして実行する myprocmail プログラムが登録されます。
imsimta program -a -m myprocmail -p procmail -g "-d %s" -e user
programs ディレクトリ (サーバ-インスタンス/imta/programs) に実行可能ファイルが存在し、「others」に対して実行権が設定されていることを確認してください。
ユーザがプログラムにアクセスするためには、そのユーザの LDAP エントリに以下の属性および値が含まれている必要があります。
maildeliveryoption: program
mailprogramdeliveryinfo: myprocmailimsimta program ユーティリティの詳細については、『Messaging Server リファレンス マニュアル』を参照してください。
その他の配信プログラムを使用する場合は、そのプログラムが以下の終了コードおよびコマンド行の引数に関する条件を満たしていることを確認してください。
終了コード条件 : pipe チャネルが呼び出す配信プログラムは、チャネルがメッセージをキューから出すか、後で処理するために配信するか、または返送するかを判断できるように、適切なエラーコードを返すものでなくてはなりません。
サブプロセスが終了コード 0 (EX_OK) で終了した場合は、メッセージが適切に配信されたと認識され、MTA のキューから削除されます。終了コード 71、74、75、または 79 (EX_OSERR、EX_IOERR、EX_TEMPFAIL、または EX_DB) で終了した場合は、一時的なエラーが発生したと見なされ、メッセージの配信は延期されます。その他のコードが返されると、メッセージは配信不能として差出人に返送されます。終了コードは、システムヘッダファイル sysexits.h 内で定義されています。
コマンド行の引数 : 可変引数 (%s) を含め、配信プログラムが使用できる引数の数に上限はありません。可変引数は、ユーザが実行するプログラムの場合はユーザ名を、postmaster「inetmail」が実行するプログラムの場合はユーザ名 + ドメイン名を示します。たとえば、以下のコマンド行は procmail プログラムを使用してメールを受取人に配信します。
hold チャネルを使用する
hold チャネルは、一時的に受信不能になっている宛先へのメッセージを保留するためのチャネルです。一時的な受信不能の原因としては、ユーザ名が変更されている最中であったり、メールボックスが別のホストやドメインに移行されている最中であることが考えられます。原因は他にもありますが、この 2 つが最も一般的なものです。hold チャネルにメッセージを保留するには、以下の 2 通りの方法があります。
ユーザの maildeliveryoption 値の 1 つを hold にします。その他の maildeliveryoption 値はすべて無視され (maildeliveryoption は複数値を持つ属性)、そのユーザへのメッセージは hold チャネルにルーティングされます。
他のチャネルとは異なり、hold チャネルのマスタープログラムは自動的に起動するように設定されていません。hold チャネルのキュー内のメッセージは、管理者が hold_master プログラムを呼び出すまでそのままの状態で待機します。hold_slave プログラムを実行します。このプログラムは、その他のすべてのチャネルをチェックし、引数が指定する宛先に一致する宛先を持つすべてのメッセージを hold チャネルに移します。
ユーザを移行するには、まず imadmin modify user を使用して maildeliveryoption を hold に設定することによって、そのユーザが移行中であることを示す必要があります。次に、hold_slave を呼び出し、その他のチャネルのキュー内にあるメッセージを hold チャネルのキューに移してから通常の移行ステップを実行します。移行ステップをすべて完了したら maildeliveryoption=hold を削除し、hold_master を呼び出して適切なチャネルのキューにメッセージを入れます。
conversion チャネルを使用する
conversion チャネルは、MTA を通して配信されるメッセージを本文部分ごとに変換します。MTA トラフィックのサブセットはいずれも変換可能であり、変換プロセスには任意のプログラムやコマンドを使用できます (MTA のネイティブ変換機能には限界があるため、外部コンバータを呼び出す能力が重要になります)。各本文部分の変換には、特殊な conversion チャネル設定が使われます。
変換処理のトラフィックを選択する
変換処理は標準的な MTA チャネルプログラムを使用して実行されますが、このチャネルがアドレスまたは MTA の書き換え規則内で直接指定されていることはあまりありません。MTA は、MTA マッピングファイル (サーバ_ルート/msg-インスタンス/imta/config/mappings) 内のCONVERSIONS マッピングテーブルを使って conversion チャネルへのアクセスを制御します。MTA は、以下の形式の文字列を使って CONVERSIONS マッピングテーブル (存在する場合) をプローブしながら各メッセージを処理します。
IN-CHAN=ソース-チャネル;OUT-CHAN=宛先-チャネル;CONVERT
ソース-チャネルはメッセージの送信元であるチャネル、宛先-チャネルはメッセージの送信先であるチャネルを示します。プローブの結果として返される値は Yes または No という文字列です。Yes の場合、MTA はメッセージを宛先チャネルではなく conversion チャネルに送ります。No の場合および一致するものがない場合は、メッセージは通常の宛先チャネルのキューに送られます。
たとえば、tcp_intranet チャネル以外のチャネルから送られたメッセージのうち、変換処理を必要とするものに対しては、以下のマッピングが適切です。
CONVERSIONS
IN-CHAN=tcp_intranet;OUT-CHAN=tcp_intranet;CONVERT NO
IN-CHAN=*;OUT-CHAN=tcp_intranet;CONVERT YES
conversion チャネルの設定
MTA 設定ファイル (imta.cnf) 内 の conversion チャネルの設定は、デフォルトで実行されます。user@conversion .ローカルホスト名 または user@conversion という形式のアドレスは、CONVERSIONS マッピングの内容に関わらず、すべて conversion チャネルを通してルーティングされます。
変換の制御
conversion チャネルが実行する変換は、MTA 変換ファイル内で定義されている規則によって制御されます。このファイルは、MTA テイラーファイル内の IMTA_CONVERSION_FILE オプションによって指定されているものであり、デフォルト設定では サーバ_ルート/msg-インスタンス/imta/conversions です。MTA 変換ファイルは MIME Content-Type パラメータに準拠する形式のエントリを含むテキストファイルです。各エントリは 1 つまたは複数のグループ化された行から構成され、各行には 1 つまたは複数の name=値; パラメータ句が含まれています。引用規則は Content-Type ヘッダ行のパラメータに関する MIME の様式に準拠します。最終行以外のすべての行には、その末尾にセミコロン (;) が付けられます。一行 (物理行) に入力できる文字数の上限は 252 文字です。論理行を複数の物理行に分割するには、バックスラッシュ (\) 継続文字が使われます。エントリは、セミコロンで終了していない行や空白行が 1 行以上挿入されている所で終了します。たとえば、ims-ms チャネルに送られるメッセージの application/wordperfect5.1 部分を架空のコンバータ「convert」で MS Word に変換するように指定するエントリは、以下のようになります。
out-chan=l; in-type=application; in-subtype=wordperfect5.1;
out-type=application; out-subtype=ddif; out-mode=block;
command="/usr/bin/convert -in=wordp -out=msword <$INPUT_FILE>$OUTPUT_FILE"
変換を理解する
MTA が行う変換には大きく分けて 2 つのカテゴリがあり、各カテゴリはそれぞれ対応するマッピングテーブルおよび MTA の conversions ファイルによって制御されます。最初のカテゴリは MTA が内部で実行する文字セット、フォーマット、およびラベルの変換です。この種の変換は CHARSET-CONVERSION マッピングテーブルによって制御されます。
もう 1 つのカテゴリは、ドキュメントコンバータなどの外部サードパーティプログラムおよびサイトで提供するプロシージャに基づいて行うメッセージ添付ファイルの変換です。この種の変換は CONVERSIONS マッピングテーブルによって制御されます。変換を必要とするメッセージは MTA の conversion チャネルに送られ、conversion チャネルによってサイト指定の外部変換プロシージャが実行されます。
MTA の conversions ファイルは、CONVERSION テーブルによってトリガされる外部変換の詳細、および CHARSET-CONVERSION テーブルによってトリガされる内部変換の詳細を指定するために使用されます。
文字セット変換とメッセージフォーマット変換のマッピング
Messaging Server の基本的なマッピングテーブルの 1 つに、文字セット変換テーブルがあります。CHARSET-CONVERSION という名のこのテーブルは、チャネル間における文字セット変換やメッセージフォーマット変換の種類を指定するために使用されます。多くのシステムでは、文字セットおよびメッセージフォーマットの変換は不必要なため、このテーブルが使われることはありません。しかし、文字セット変換の必要が生じる場合もあります。
CHARSET-CONVERSION マッピングテーブルは、メッセージフォーマットを変換するためにも使用され、多数の非 MIME フォーマットを MIME に変換することができます。MIME エンコーディングおよび構造に変更を加えることもできます。これらのオプションは、MIME または MIME のサブセットだけをサポートするシステムにメッセージを送る際に使用されます。また、MIME フォーマットから非 MIME フォーマットへの変換が可能な場合もあります。
MTA は 2 通りの方法によって CHARSET-CONVERSION マッピングテーブルをプローブします。1 回目のプローブは、MTA がメッセージフォーマットを変換すべきか、また変換する場合はどのフォーマット オプションを使用すべきかを決定するために実行されます (フォーマット変換が指定されていない場合、特定の文字セットへの変換に関するチェックは行われません)。このプローブには、以下のような形式の入力文字列が使用されます。
IN-CHAN=イン-チャネル;OUT-CHAN=アウト-チャネル;CONVERT
イン-チャネルはソースチャネル (メッセージの送信元)、アウト-チャネルは宛先チャネル (メッセージの送信先) を示します。一致するものが見つかった場合は、カンマで区切られたキーワードのリストが返されます。キーワードについては、表 8-7 を参照してください。
文字セットの変換
プローブを行い、メッセージフォーマットを変換する必要があると判断した場合、MTA はメッセージにおける各部分のチェックを開始します。テキスト部分はすべて検出され、その文字セットのパラメータは 2 回目のプローブに使用されます。ただし、変換が必要であると判断されるまで 2 回目のプローブは行われません。2 回目のプローブを行うための入力文字列は以下のとおりです。IN-CHAN=チャネル (入力);OUT-CHAN=チャネル (出力);IN-CHARSET=文字セット (入力)
チャネル (入力)とチャネル (出力)の部分は前述の例と同じです。文字セット(入力)は該当する部分の文字セット名を示します。この 2 回目のプローブで一致するものがない場合、文字セットの変換は行われません (ただし、フォーマットの変換、たとえば MIME 構造への変換などは、最初のプローブで一致したキーワードに基づいて行われます)。一致するものが見つかった場合は、以下の文字列が返されます。
この場合、文字セット (入力)は文字セット (出力)が示す文字セットに変換されます。これらの文字セットは、MTA テーブルディレクトリに含まれる文字セット定義テーブル charsets.txt 内で定義されているものでなくてはなりません。文字セットがこのファイル内で適切に定義されていないと、変換は行われません。しかし、このファイルの中には現在最も利用度の高い数百種の文字セットが定義されているため、特に心配する必要はないでしょう。charsets.txt ファイルの詳細については、imsimta chbuild (UNIX および NT) ユーティリティの説明を参照してください。
すべての条件が満たされると、MTA は文字セットマッピングを作成し、変換を実行します。変換されたメッセージ部分のラベルは、変換後の文字セット名に変更されます。
メッセージフォーマットの変換
前述したように、CHARSET-CONVERSION マッピングテーブルは MIME フォーマットと数種のメーカー独自のメールフォーマット間における添付ファイルの変換にも関わりがあります。以下の各項では、CHARSET-CONVERSION マッピングテーブルによって可能なその他のメッセージフォーマット変換の例を紹介します。
非 MIME バイナリ添付ファイルの変換
メッセージの処理にかかわるチャネルで CHARSET-CONVERSION が有効になっている場合、MIME 以外非標準のフォーマットを使用しているメッセージ、たとえば Microsoft Mail (MSMAIL) SMTP ゲートウェイからのメッセージは、自動的に MIME フォーマットに変換されます。tcp_local チャネルが存在する場合は通常、このチャネルが Microsoft Mail SMTP ゲートウェイからのメッセージを受信します。以下の例は、ローカルユーザ宛てのメッセージのフォーマット変換を有効にするものです。IN-CHAN=tcp_local;OUT-CHAN=ims-ms;CONVERT Yes
すべてのチャネルに対してフォーマット変換を有効にするには、OUT-CHAN=ims-ms を OUT-CHAN=* に変更します。ただし、こうすると tcp_local チャネルからのメールがすべてチェックされることになるため、特定のチャネルに限定する場合より、処理時間が長くなる可能性があります。
さらに、このように無差別な変換を設定すると、エンベロープおよび関連する転送情報部分のみを変換すべきメッセージ (たとえばシステムを通過するだけのメッセージなど) に対してまで広範な変換処理を行うことになりかねません。
MIME を Microsoft Mail SMTP ゲートウェイが理解できるフォーマットに変換するには、MTA 設定ファイルで Microsoft Mail SMTP ゲートウェイ専用のチャネル (tcp_msmail など) を設定し、マッピングファイルに以下の内容を追加します。
IN-CHAN=*;OUT-CHAN=tcp_msmail;CONVERT RFC1154
MIME ヘッダラベルの変換
ユーザエージェントやゲートウェイによっては、より正確な MIME ヘッダを作成するために十分な情報があるにも関わらず、比較的無益な MIME ヘッダを作成するものもあります。最も良い方法はそのようなエージェントやゲートウェイの設定を適切に変更することですが、それが不可能な場合には有用な MIME ヘッダを構築するように MTAを設定します。最初のプローブの際に CHARSET-CONVERSION マッピングテーブルが Yes または Always キーワードを返した場合、MTA は conversions ファイルが存在するかどうかを確認します。ファイルが存在する場合、MTA はそのファイルをチェックして RELABEL=1 という記述があるかどうかを確認し、ある場合はそのエントリの指定に従って MIME ラベルを変換します。
たとえば、以下のような CHARSET-CONVERSION テーブルと MTA conversions ファイルのエントリの組み合わせなら、メッセージは tcp_local チャネルから ims-ms チャネルにルーティングされます。さらに、受信時の MIME ラベルが application/octet-stream でファイル名パラメータの拡張子が ps または msw の場合には、それぞれ application/postscript または application/msword という新しいラベルが付けられます (このより正確なラベルは、もともとユーザエージェントやゲートウェイがメッセージに付けておくべきものです)。
MacMIME フォーマットの変換
Macintosh ファイルには、Macintosh 特有の情報を含むリソースフォークと、他のプラットフォームで使用できるデータを含むデータフォークの 2 つの部分があります。さらに、Macintosh ファイルの転送には一般に 4 種類の異なるフォーマットが使用されるため、Macintosh ファイルを転送するにはより複雑な処理が必要となります。Applesingle、Binhex、および Macbinary フォーマットは、Macintosh リソースフォークと Macintosh データフォークを 1 つにエンコードしたものから成り立っています。Appledouble フォーマットの場合は、リソースコードとデータフォークがそれぞれ独立した部分として存在しています。このため、Macintosh 以外のプラットフォームでは、リソースフォーク部分を無視してデータフォーク部分のみを使用できる Appledouble が最も便利です。逆に、Macintosh への送信には、他の 3 種類のフォーマットが便利です。MTA は、これらの Macintosh フォーマット間の変換を実行することができます。MTA は CHARSET-CONVERSION キーワードである Appledouble、Applesingle、Binhex、および Macbinary によって MacMIME フォーマット部分をそれぞれ multipart/appledouble、application/applefile、application/mac-binhex40、または application/macbinary の MIME フォーマットに変換します。さらに、Binhex および Macbinary キーワードは、MIME Content-type: ヘッダに X-MAC-TYPE および X-MAC-CREATOR パラメータを含む特定の非 MacMIME フォーマットへの変換もリクエストします。CHARSET-CONVERSION キーワードの Block は、MTA に対し、MacMIME フォーマット部分のデータフォークのみを抽出し、リソースフォークを破棄するようリクエストします (ただし、このキーワードを使用すると一部の情報が失われるため、Appledouble キーワードの使用をお勧めします)。
たとえば、以下の CHARSET-CONVERSION テーブルは ims-ms チャネルにメッセージを配信する場合に Appledouble フォーマットへの変換を MTA に指示します。
IN-CHAN=*;OUT-CHAN=l;CONVERT Appledouble
この場合、すでに MacMIME フォーマットが使用されている部分のみが Appledouble フォーマットに変換されます。
Appledouble または Block フォーマットへの変換には、オリジナルの Macintosh ファイルに含まれる Macintosh クリエータおよびタイプ情報に基づいて Appledouble または Block フォーマットの部分のデータフォークに付ける MIME ラベルを指定するために、MAC-TO-MIME-CONTENT-TYPES マッピングテーブルが使用されることもあります。このテーブルのプローブには、「フォーマット|タイプ|クリエータ|ファイル名」形式が使用されます。フォーマットの値には SINGLE、BINHEX、MACBINARY のどれかが指定され、タイプの値には Macintosh タイプ情報 (16進)、クリエータの値には Macintosh クリエータ情報 (16進)、そしてファイル名の値には実際のファイル名が指定されます。
たとえば、ims-ms チャネルにメッセージを送る場合に Appledouble フォーマットに変換し、MACBINARY または BINHEX 部分から MS Word または PostScript に変換されたドキュメントに特定の MIME ラベルを付けるには、以下のテーブルが適切です。
マッピングエントリのテンプレート (右側) に $Y フラグが設定されていない場合、指定したラベルは付けられません。MTA テーブル ディレクトリ内の mac_mappings.sample ファイルには、その他の種類の添付ファイルに関するサンプル エントリが記載されています。
MacMIME 以外のフォーマットが使用されている部分を Binhex または Macbinary フォーマットに変換するには、X-MAC-TYPE および X-MAC-CREATOR MIME Content-type: パラメータ値が必要です。通常これらのパラメータ値を持たない部分にそれを強要するために MIME ラベルの変換を実行することも可能です。
サービス変換
MTA の変換サービス機能をサイト提供のプロシージャと一緒に使用すると、新しい形式のメッセージを作成することができます。前述の CHARSET-CONVERSION や conversion チャネルの場合は個別の MIME メッセージ部分を操作しますが、変換サービスはすべての MIME メッセージ部分 (MIME ヘッダと内容) および MIME メッセージ全体を操作します。また、他のCHARSET-CONVERSION 操作や conversion チャネルの操作とは異なり、変換サービスは独自で MIME 逆アセンブリ、デコード、再エンコード、および再アセンブリを行います。他の CHARSET-CONVERSION 操作と同様に、変換サービスは CHARSET-CONVERSION マッピング テーブルを通じて有効化されます。CHARSET-CONVESION マッピングテーブルを最初にプローブした結果が Yes または Always キーワードの場合、MTA は conversions ファイルが存在するかどうかをチェックします。conversions ファイルが存在する場合は、ファイル内に SERVICE-COMMAND を指定するエントリがあるかどうかを確認し、ある場合はそれを実行します。conversions ファイルのエントリの形式は以下のとおりです。
in-chan=channel-pattern;
in-type=type-pattern; in-subtype=subtype-pattern;
service-command=commandここでコマンド文字列に注目してください。これは、たとえばドキュメントコンバータを呼び出すなどのサービス変換を行うために必要なコマンドです。このコマンドが実行されると、変換を必要とするメッセージを含む入力ファイルが処理され、新しいメッセージテキストを含む出力ファイルが生成されます。UNIX では、コマンドが成功した場合には 0、失敗した場合にはその他の値で終了する必要があります。
入力ファイル名、出力ファイル名、メッセージのエンベロープ受取人アドレスを含むファイルの名前などを伝達するためには、環境変数が使われます。これらの 3 つの環境変数は以下のとおりです。
これらの環境変数の値は、通常の方法でコマンド行に代入することができます。UNIX では、変数名の前に「＄」記号を挿入します。
前へ 目次 索引 次へ
Copyright (c) 2001 Sun Microsystems, Inc. 既存部分の一部: Copyright (c) 2001 Netscape Communications Corp. All rights reserved.
最終更新日 2001 年 5 月 24 日