前へ 目次 索引 DocHome 次へ |
iPlanet Messaging Server 5.2 管理者ガイド |
第 8 章 チャネル定義を設定する
この章では、MTA 設定ファイル imta.cnf でのチャネルキーワード定義の使用方法について説明します。この章を読む前に、第 6 章「MTA サービスと設定について」、および「チャネル定義」と「MTA 設定ファイル」をお読みください。この章には、以下の節があります。
チャネルキーワードの一覧 (アルファベット順)
チャネルキーワードの一覧 (アルファベット順)
次の表にキーワードの一覧をアルファベット順に示します。
表 8-1    チャネルキーワード (アルファベット順)
キーワード
ページ
キーワード
ページ
キーワード
ページ
キーワード
ページ
機能別チャネルキーワード
次の表に分類したキーワードの一覧を示します。
表 8-2    機能別チャネルキーワード (太字はデフォルト)
キーワード
ページ
定義
アドレス処理
エントリの一致の確認中に特別なサブアドレスの処理を行わない。エイリアスが一致するとみなされるためには、サブアドレスを含むメールボックス全体が一致する必要がある
添付と MIME 処理
文字セットと 8 ビットデータ
MTA キュー領域でのファイル作成
ヘッダー
4 桁の日付表示から先頭の 2 桁を削除する。2 桁の日付表示を要求するメールシステムとの互換性を提供するための機能なので、その他の目的のために使用しないこと
メッセージがキューに入れられたときに、元のメッセージヘッダーが作成される前にオプションファイルからそのメッセージのヘッダーにトリミングの規則を適用する (注意して使用すること)
日付 / 時刻ヘッダーから曜日情報を削除する。この情報が処理できないメールシステムとの互換性を提供するための機能なので、その他の目的のために使用しないこと
メッセージの宛先になっているエンベロープ受取人アドレスが 1 つだけの場合は、そのエンベロープの To: アドレスを Received: ヘッダー行に含める
MTA がエンベロープの From: アドレスを変更する場合は、受信メッセージの Received: ヘッダー行を作成するときに元のエンベロープの From: アドレスを含める
受信チャネルの一致と切り替え
ログ記録とデバッグ
長いアドレスリストやヘッダー
メールボックスフィルタ
通知メッセージとポストマスターメッセージ (完全な通知手順については 150 ページを参照)
正式なチャネル名でのユーザ名がポストマスターのメッセージは postmaster@ローカルホストにリダイレクトされる。ローカルホストには、ローカルホスト名 (ローカルチャネルの名前) が入る
処理制御とジョブ送信 (より大きい機能単位については 表 8-7 を参照)
配信不能メッセージを再配信する回数。normalbackoff、nonurgentbackoff、urgentbackoff キーワードで置き換え可能
マスターとスレーブの両方のプログラムによって処理されるチャネル
優先度にかかわらず、送信後すべてのメッセージの配信を即座に開始する
マスタープログラムによって処理されるチャネル (master)
指定値以上のサイズを持つメッセージの優先度を「低」以下 (2 番目の優先度) に設定する。該当するメッセージは次の定期ジョブまで処理されない
マスタープログラムによって処理されるチャネル (slave)
重要度の上限
メッセージのサイズ制限、ユーザ制限容量、権限
指定値以上のサイズを持つメッセージの優先度を「低」以下 (2 番目の優先度) に設定する。該当するメッセージは次の定期ジョブまで処理されない
SMTP 認証、SASL および TLS (より大きい機能単位については 233 を参照)
MTA SMTP クライアントは TLS をサポートする SMTP サーバにメッセージを送信する際に TLS を使用する
MTA SMTP サーバが STARTTLS 拡張をサポートすることを通知し、メッセージを受信する際に TLS を使用することを許可する
TCP/IP チャネルで使用して、MTA にこれが MS Exchange ゲートウェイとクライアントとの通信を行うチャネルであることを指示する
MTA SMTP クライアントは、メッセージの送信に必ず TLS を使用する (MTA は STARTTLS コマンドを発行し、このコマンドは必ず成功する必要がある)
MTA SMTP サーバが STARTTLS 拡張をサポートすることを通知し、メッセージを受信する際に TLS を使用する
送信接続時に MTA SMTP クライアントは TLS を使用することがない (送信接続時に STARTTLS コマンドが発行されない)
受信接続時に MTA SMTP サーバは TLS の使用を許可しない (SMTP サーバもコマンド自体も STARTTLS 拡張に通知しない)
クライアントが TLS ネゴシエーションに成功した場合、受信接続が指定のチャネルに切り替えられる。このキーワードには、切り替え先のチャネルを指定する必要がある
SMTP コマンドとプロトコル (より大きい機能単位については 表 8-4 を参照)
SMTP プロトコルをサポートする。smtp キーワードはすべての SMTP チャネルで必須(このキーワードは smtp_crorlf と同等)
キャリッジリターン (CR) 、ラインフィーダ (LF) のシーケンス、または完全な CRLF が改行記号として使用可能である
TCP/IP 接続および DNS 検索サポート (より大きい機能単位については 表 8-5 を参照)
リバース DNS 検索のあとに正引き検索を行い、リバース DNS 検索で返された名前の正引き検索がオリジナルの接続の IP 番号に一致するかどうかを確認する。一致しない場合、リバース DNS 検索で返された名前は削除され、IP アドレスが使用される
リバース DNS 検索が実行して返された名前を正引き検索して、IP 番号がオリジナルの接続の IP 番号に一致するかどうかを確認する。一致しなければ名前に「*」を付ける
IDENT 検索を実行しない。IP からホスト名への変換を実行し、Received: ヘッダーにホスト名と IP アドレスを含める
IDENT 検索を実行しない。IP からホスト名への変換を実行し (ただしチャネルの切り替えを行う際にはホスト名を使用しない)、Received: ヘッダーにホスト名と IP アドレスの両方を含める
受信 SMTP 接続での IDENT 検索と IP からホスト名への変換を実行し、Received: ヘッダーにホスト名と IP アドレスの両方を含める
受信 SMTP 接続での IDENT 検索と IP からホスト名への変換を実行する。チャネルの切り替えを行う際にはホスト名を使用しない。Received: ヘッダーにホスト名と IP アドレスを含める
受信 SMTP 接続での IDENT 検索と IP からホスト名への変換を実行し、Received: ヘッダーにホスト名だけを含める
TCP/IP スタックが選択したネームサーバの代わりに照合するネームサーバのリストを指定する。nameservers には、空白文字で区切られたネームサーバの IP アドレスのリストが必要
port
その他
チャネルのデフォルトを設定する
設定ファイルにはさまざまなチャネルキーワードが繰り返し記述されていることがあります。このような設定を管理するには時間がかかり、エラーの原因にもなります。複数のチャネルに対してまとめてデフォルトのキーワードを指定すると、設定を簡素化することができます。たとえば、以下の行を設定ファイルに追加すると、行中で指定したキーワードがそれ以降のすべてのチャネルブロックに適用されます。
defaults keyword1 keyword2 keyword3 ...
defaults 行はチャネルを特定せずにデフォルトのキーワードを変更するための特殊なチャネルブロックだと考えられます。また、defaults 行にほかのチャネルブロック情報を指定する必要はありません (指定しても無視されます)。
1 つのファイルに使用できる defaults 行の数に上限はありません。複数の defaults 行を指定した場合、ファイルの下へ行くほど (あとで追加した行ほど) 優先度が高くなります。
設定ファイル内のある位置 (たとえば、外部ファイルのチャネルブロックの独立したセクションの冒頭など) 以降には無条件に defaults 行が適用されないように設定しておく方がよい場合もあります。そのためには、nodefaults 行を使用します。たとえば、以下の行を設定ファイルに挿入すると、それ以前の部分で defaults を使って指定した設定がすべて無効になり、defaults を使用していないのと同じ状態に戻ります。
ほかのチャネルブロックと同様に、defaults や nodefaults チャネルブロックを使用する場合も、ブロック間の区切りには空白行を使用します。設定ファイル内でローカルチャネルの前に記述できるチャネルブロックは、defaults と nodefaults のみです。ただし、ほかのチャネルブロックと同様、書き換え規則の前に記述することはできません。
SMTP チャネルを設定する
インストールの種類によっては、Messaging Server のインストール時に数種の SMTP チャネルが提供されます (以下の表を参照)。このようなチャネルは TCP/IP の上位プロトコルとして SMTP を実装します。マルチスレッド TCP SMTP チャネルには、ディスパッチャ制御下のマルチスレッド SMTP サーバが含まれる。送信された SMTP メールは、必要に応じてジョブコントローラの制御下で動作し、チャネルプログラム tcp_smtp_client によって処理されます。
この節で説明するチャネルキーワードを追加したり削除することで、これらのチャネルの定義を変更したり、新規チャネルを作成することも可能です。また、オプションファイルは、TCP/IP チャネルのさまざまな特徴を制御するために使用されます。このようなオプションファイルは、MTA 設定ディレクトリ (ServerRoot/msg-instance/imta/config) に保存し、x_option という名前を付けなければなりません。この「x」はチャネルの名前です。詳細については『iPlanet Messaging Server リファレンスマニュアル』を参照してください。
SMTP チャネルオプションを設定する
ヘッダー内の SMTP AUTH から認証済みアドレスを使用する
ヘッダー内の SMTP AUTH から認証済みアドレスを使用する
SMTP チャネルオプションを設定する
TCP/IP チャネルオプションファイルは、TCP/IP チャネルのさまざまな特性を制御します。ファイルには x_option という名前を付けてください。ファイル名の x はチャネル名となります。たとえば、/ServerInstance/imta/config/tcp_local_option のようになります。オプションファイルは、1 つまたは複数のキーワードとその関連値によって構成されています。たとえば、サーバのメーリングリストのエクスパンドを無効にするには、オプションファイルに DISABLE_EXPAND キーワードを追加し、値を 1 に設定します。
その他のオプションファイルキーワードを使用すると、以下の制御を行うことができます。
メッセージ当たりの宛先数を制限する (ALLOW_RECIPIENTS_PER_TRANSACTION)
チャネルオプションキーワードとシンタックスの詳細については、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。接続当たりのメッセージ数を制限する (ALLOW_TRANSACTIONS_PER_SESSION)
MTA ログファイルに記録される情報のタイプを微調整する (LOG_CONNECTION、LOG_TRANSPORTINFO)
SMTP コマンドとプロトコルのサポート
SMTP チャネルが EHLO、ETRN、VRFY などの SMTP コマンドをサポートするように指定することができます。また、チャネルが DNS ドメイン確認をサポートするかどうかや、どの文字を改行記号として受け入れるかなどを指定することも可能です。この項では、以下の内容について説明します。
チャネルプロトコル選択と改行記号
表 8-4 に、この節で説明されているキーワードのリストを示します。
チャネルプロトコル選択と改行記号
キーワード : smtp、nosmtp、smtp_crlf、smtp_cr、smtp_crorlf、smtp_lfsmtp および 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 を使用すると、CR のみのターミネータが受け入れられます。これらのオプションは、受信データにしか適用されません。
SMTP では 改行記号として CRLF が要求されるため、MTA は常に CRLF シーケンスを生成します。各種の smtp キーワードは、MTA がその他の非標準的な改行記号を受け入れるかどうかを指定するだけのものです。たとえば、MTA が規定どおりの SMTP メッセージだけを受け入れ、非標準的な改行記号を含むメッセージを拒否するように指定するには、stmp_crlf を使います。
EHLO コマンドのサポート
キーワード : ehlo、noehlo、checkehloSMTP プロトコルは、その他のコマンドの使用のネゴシエーションを行うことができるよう拡張されています (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、novrfyRFC 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 はドメインによって確認されたチャネル名をエコーしません。
disableetrn では、ETRN コマンドに対するサポートが完全に無効となります。SMTP サーバで、ETRN はサポートされているコマンドとしてアドバタイズされません。
ETRN コマンドを送信する
sendetrn および nosendetrn チャネルキーワードは、MTA が SMTP 接続開始時に ETRN コマンドを送るかどうかを指定するためのものです。デフォルト設定では nosendetrn が有効になっているため、MTA は ETRN コマンドを送りません。リモート SMTP サーバが ETRN コマンドをサポートする場合にのみ MTA が ETRN を発行するように指定するには、sendetrn キーワードを使用します。sendetrn キーワードの後ろには、メッセージの配信先となるシステムの名前を記述する必要があります。
VRFY コマンドのサポート
キーワード : domainvrfy、localvrfy、vrfyallow、vrfydefault、vrfyhideVRFY コマンドは、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、nomailfromdnsverifymailfromdnsverify を受信 TCP/IP チャネルに対して設定すると、MTA は SMTP MAIL FROM コマンドで指定されているドメインのエントリが DNS に存在するかどうかを確認し、エントリが存在しない場合にはメッセージを拒否します。デフォルト設定では nomailfromdnsverify が有効になっているため、この確認は行われません。ただし、返信アドレスに対して DNS 確認を行うと、許可されるべきメッセージも拒否されてしまう可能性があることに注意してください (たとえば、正規のサイトでもそのドメイン名がまだ登録されていない場合や、DNS が適切に動作していない場合など)。これは、RFC 1123 の「Requirements for Internet Hosts (インターネットホストの必要条件)」で規定されている電子メール受信の心得に反する行為です。ただし、存在しないドメインから不特定多数宛てのメール (UBE) が送られる場合は、この確認を行った方がよい場合もあります。
文字セットのラベルと 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 ...
hostnameContent-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 ポート番号とインタフェースアドレス
表 8-5 に、この項で説明されている 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、cachesuccessesSMTP プロトコルを使用するチャネルは、過去の接続試行の履歴を含むキャッシュを管理しています。このキャッシュは、アクセスできないホストに繰り返し接続しようとして時間を浪費し、ほかのメッセージの配信が遅延されることを回避するために使用されます。このキャッシュは送信 SMTP チャネルが動作中の間のみ維持され、動作が終了するたびに削除されます。
通常、キャッシュには、成功した接続試行と失敗した接続試行の両方に関する情報が記録されます(成功した試行は、その後失敗する試行を相殺するために記録されます。すなわち、一度接続に成功したホストがその後失敗しても、はじめて試行する接続や以前失敗した接続ほど次の接続試行が遅れることはありません)。
ただし、MTA が使用するキャッシング方法がすべての状況に適しているというわけではありません。そこで、チャネルキーワードを使用して MTA キャッシュを調整します。
cacheeverything キーワードは、すべての形式のキャッシングを有効にします。デフォルト設定ではこのキーワードが使用されます。nocache キーワードは、すべてのキャッシングを無効にします。
cachefailures キーワードは、失敗した接続のキャッシングだけを有効にします。このキーワードを使用すると、次の試行は cacheeverything を使用した場合より多くの制約を受けることになります。cachesuccesses は成功した接続だけをキャッシュします。このキーワードは、SMTP チャネルに対する nocache キーワードと同等のものです。
リバース DNS 検索
キーワード : forwardchecknone、forwardchecktag、forwardcheckdeleteforwardchecknone、forwardchecktag、および forwardcheckdelete チャネルキーワードは、リバース DNS 検索の影響を修正します。これらのキーワードは、MTA が DNS リバース検索によって検出された IP 名の正引き検索を実行するかどうか、および実行する場合には正引き検索の結果がオリジナルの接続の IP 番号と一致しなかった場合にどのように対処するかを制御します。
デフォルト設定では forwardchecknone キーワードが有効になっているため、正引き検索は実行されません。forwardchecktag キーワードは、リバース検索が行われるたびに正引き検索を実行し、検出された番号が最初の接続の番号と一致しない場合は IP 名にアスタリスク (*) を付けるように指定します。forwardcheckdelete キーワードは、リバース検索が行われるたびに正引き検索を行い、リバース検索で返された名前の正引き検索がオリジナルの接続の IP アドレスに一致しなかった場合はリバース検索で返された名前を無視 (削除) するように、MTA に指示します。
注 複数の IP アドレスに「一般的な」IP 名が使用されているサイトの場合、正引きの結果が最初の IP アドレスと一致しないのは比較的頻繁に見られる現象です。
IDENT 検索
キーワード : identnone、identnonelimited、identtnonnumeric、identnonesymbolic、identtcp、identtcpnumeric、identtcpsymbolic、identtcplimitedIDENT キーワードは、MTA が IDENT プロトコルを使用して接続や検索を処理する方法を制御します。IDENT プロトコルは、RFC 1413 で規定されています。
identtcp、identtcpsymbolic、および identtcpnumeric キーワードは、MTA が接続や検索に IDENT プロトコルを使用するように指定するものです。IDENT プロトコルから入手した情報 (通常、SMTP 接続を使用しているユーザの ID) は、次のようにメッセージの Received: ヘッダー行に挿入されます。
identtcp は受信した IP 番号に呼応するホスト名 (DNS リバース検索で検出された名前) および IP 番号そのものを挿入します。
IDENT クエリの試行でパフォーマンスヒットが発生する場合があります。そうすると、ルーターは認識できないポートへの接続試行を次第に「ブラックホール化」するようになります。IDENT 検索でこのような状況が発生した場合は、接続がタイムアウトするまで MTA には応答が返されません (通常、このタイムアウトは TCP/IP スタックが制御するもので、1、2 分ほどかかります)。identtcpsymbolic は受信した IP 番号に呼応するホスト名 (リバース DNS 検索で検出された名前) を挿入します。IP 番号そのものは Received: ヘッダーに含まれません。
identtcpnumeric は受信した IP 番号を挿入します。リバース DNS 検索は実行されません。
注 identtcp、identtcpsymbolic、または identtcpnumeric による IDENT 検索が役に立つのは、リモートシステムで IDENT サーバが稼働している場合です。
別のパフォーマンスの問題が、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 レコードのサポート
キーワード : mx、nomx、defaultmx、randommx、nonrandommxTCP/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 アドレスのリストが必要です。以下の例を参照してください。
デフォルト設定では defaultnameservers が有効になっているため、TCP/IP スタックの選択によるネームサーバが使用されます。
UNIX でネームサーバ検索を禁止するには、nsswitch.conf ファイルを編集します。NT の場合は、TCP/IP 設定を変更します。
lastresort キーワードは、「最後のホスト」つまりほかのホストへの接続試行がすべて失敗した場合に最終的な接続先となるホストを指定します。このキーワードは、事実上の最終手段的 MX レコードとして動作します。このキーワードは、SMTP チャネルに対してのみ効果があります。
このキーワードでは、「最終手段的システム」の名前を指定する単一のパラメータが必要です。たとえば、以下のようになります。
tcp_local single_sys smtp mx lastresort mailhub.siroe.com
TCP-DAEMON
受信メール用代替チャネル (切り替えチャネル)
キーワード : switchchannel、allowswitchchannel、noswitchchannel
233 ページの「saslswitchchannel」および 235 ページの「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_sysdaemon キーワードの解釈と使用は、適用するチャネルの種類によって異なります。
daemon キーワードは、SMTP チャネル上でターゲットホストの選択を制御するために使用します。
通常、ホストへの接続に使用されているチャネルは、メッセージのエンベロープアドレスに表示されます。daemon キーワードは、エンベロープアドレスにどのチャネルが表示されているかにかかわらず、チャネルがファイヤウォールやメールハブシステムなど特定のリモートシステムに接続するように設定します。実際のリモートシステム名は、以下の例に示すように daemon キーワードの直後に表示されます。次に例を示します。
tcp_firewall smtp mx daemon firewall.acme.com
TCP-DAEMONdaemon キーワードの後ろの引数が完全なドメイン名ではない場合、引数は無視され、チャネルは正規ホストに接続します。ファイヤウォールやゲートウェイシステムを正規ホスト名として指定する場合、以下の例に示すように 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 SecurityLayer) を使用した SMTP サーバの認証をサポートするかどうかを指定できます。SASL は RFC 2222 で定義されています。SASL、SMTP 認証、セキュリティの詳細については、第 12 章「セキュリティとアクセス制御を設定する」を参照してください。
maysaslserver、mustsaslserver、nosasl、nosaslserver, itchchannel、および saslswitchchannel チャネルキーワードは、SMTP プロトコルが使用される際に、TCP/IP チャネルなどの SMTP チャネルによって SASL (SMTP AUTH) が使用されるように設定するためのものです。
デフォルト設定では nosasl が有効になっているため、SASL 認証は許可または試行されません。このキーワードは nosaslserver を包括するため、SASL 認証の使用はすべて禁止されます。maysaslserver を指定すると、SMTP サーバは、クライアントが SASL 認証の使用を試行することを許可します。mustsaslserver を指定すると、SMTP サーバは、クライアントが SASL 認証を使用することを要求します。SMTP サーバは、リモートクライアントが認証に成功しないかぎり、メッセージを受け付けません。
クライアントが SASL の使用に成功したときに受信接続を指定のチャネルに切り替えるには、saslswitchchannel を使います。このキーワードには、切り替え先のチャネルを指定する必要があります。
ヘッダー内の SMTP AUTH から認証済みアドレスを使用する
キーワード : authrewriteMTA が認証された差出人の情報をヘッダーに含めるようにするために、authrewrite チャネルキーワードをソースチャネルに使用することもできます。FROM_ACCESS マッピングによって無視されることもありますが、通常はSMTP AUTH 情報が使用されます。表 8-6 にあるように、authrewrite キーワードは必須の整数値をとります。
表 8-6    authrewrite の整数値
値
使用目的
AUTH 差出人を含む Resent-from: や Resent-sender: がすでに存在していれば、Sender: ヘッダーまたは Resent-sender: ヘッダーを追加する
Microsoft Exchange ゲートウェイチャネルを指定する
キーワード : msexchange、nomsexchangemsexchange チャネルキーワードは TCP/IP チャネルで使用して、MTA にこれが Microsoft Exchange ゲートウェイとクライアントとの通信を行うチャネルであることを指示できます。SASL 対応の (maysaslserver キーワード、または mustsaslserver キーワードを使用) 受信 TCP/IP チャネルで配置されると、MTA の SMTP サーバが「不正な」形式 (オリジナルの ESMTP AUTH 仕様に基づく。この仕様は新しい適切な AUTH 仕様ではなく、適切な ESMTP 形式と互換性を持たない) を使って AUTH をアドバタイズするようになります。たとえば、Microsoft Exchange クライアントの中には、適切な AUTH 形式を認識せず、不正な AUTH 形式のみを認識するものがあります。
msexchange チャネルキーワードでも、破損した TLS コマンドをアドバタイズ (および認識) するようになります。
Transport Layer Security
キーワード : maytls、maytlsclient、maytlsserver、musttls、musttlsclient、musttlsserver、notls、notlsclient、notlsserver、tlsswitchchannelmaytls、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 を使用できる) を包括しています。
musttls キーワードを指定すると、MTA がは送受信接続に必ず TLS を使用します。TLS の使用をネゴシエーションを行うことができなかったリモートシステムとの電子メールの交換は許可されません。このキーワードは、musttlsclient (MTA SMTP クライアントはメッセージの送信に必ず TLS を使用し、TLS の使用のネゴシエーションが成功しない SMTP サーバにはメッセージを送らない。MTA 発行の STARTTLS コマンドは必ず成功しなければならない)および musttlsserver (MTA SMTP サーバが STARTTLS 拡張をサポートすることを通知し、TLS 使用のメッセージを受け入れる際には必ず TLS を使用する。TLS の使用のネゴシエーションが成功しないクライアントからのメッセージは拒否される) を包括しています。
tlsswitchchannel キーワードは、クライアントが TSL 使用のネゴシエートに成功した場合、受信した接続を指定のチャネルに切り替えるためのキーワードです。このキーワードには、切り替え先のチャネルを指定する必要があります。
メッセージの処理と配信を設定する
サーバが特定の条件に基づいてメッセージの配信を試みるように指定できます。また、サービスジョブの処理制限や、新しい SMTP チャネルスレッドを作成するタイミングなど、ジョブ処理に関するパラメータを指定することも可能です。この項では、以下の内容について説明します。
「チャネルの方向性を設定する」
メッセージの処理と配信の詳細については、「ジョブコントローラ」および 「ジョブコントローラファイル」を参照してください。表 8-7 に、この節で説明されているキーワードのリストを示します。
チャネルの方向性を設定する
キーワード : master、slave、bidirectionalチャネルを処理するプログラムは、マスタープログラム (master)、スレーブプログラム (slave)、あるいは両方のプログラム (bidirectional) という 3 つのキーワードで指定されます。これらのどのキーワードも指定されていない場合のデフォルトは bidirectional です。これらのキーワードによって、チャネルのキューにメッセージが入れられたときに MTA が配信活動を開始するかどうかが決まります。
これらのキーワードを使用すると、対応するチャネルプログラムの特徴が反映されるようになります。これらのキーワードをいつ、どこで使用すべきかについては、MTA がサポートする各種チャネルの説明を参照してください。
指定配信日を実行する
キーワード : deferred、nodeferreddeferred チャネルキーワードは、Deferred-delivery: ヘッダー行の認識と処理を行います。未来の deferred 指定配信日が付いているメッセージは、有効期限が切れて返されるか、あるいは指定配信日がくるまでチャネルのキューに保管されます。Deferred-delivery: ヘッダー行の形式と操作の詳細については、RFC 1327 を参照してください。
デフォルトのキーワードは nodeferred です。RFC 1327 では配信日指定によるメッセージ処理のサポートが義務付けられていますが、実際にそれを効果的に行えば、人々がディスク制限容量の拡張手段としてメールシステムを使用できるようになります。
配信失敗メッセージの再配信回数を指定する
キーワード : backoff、nonurgentbackoff、normalbackoff、urgentbackoff、noticesデフォルトでは、配信に失敗したメッセージの再配信回数はメッセージの優先度によって異なります。以下にデフォルトの再配信間隔を分単位で示します。優先度に続いて数字が示されていますが、最初の数字は最初に配信に失敗してから再配信を試みるまでの時間 (分) です。
優先度が高い : 30、60、60、120、120、120、240
優先度が標準 : 60、120、120、240、240、240、480
優先度が低い : 120、240、240、480、480、480、960高い優先度では、最初の失敗から 30 分後に最初の再配信を試み、最初の再配信から 60 分後に 2 回目の再配信を、2 回目の再配信から 120 分後に 3 回目の再配信を試みます。最後に示した配信後は同じ間隔で再配信が試みられます。優先度が高いメッセージの場合では 240 分ごとに再配信が試みられます。
再配信が行われるのは、notices、nonurgentnotices、normalnotices、または urgentnotices キーワードで指定された期間内です。期間内に配信が成功しなければ、配信失敗通知が作成され、メッセージは差出人に返送されます。notices キーワードの詳細については、「通知メッセージの配信間隔を設定するには」を参照してください。
backoff キーワードを使うと、優先度ごとにメッセージ再配信間隔を設定することができます。nonurgentbackoff は優先度が低いメッセージの再配信間隔を指定します。normalbackoff は優先度が標準のメッセージの再配信間隔を指定します。urgentbackoff は優先度が高いメッセージの再配信間隔を指定します。backoff のどのキーワードも指定されていなければ、優先度とは無関係に再配信間隔が指定されます。
urgentbackoff "pt30m" "pt1h" "pt2h" "pt3h" "pt4h" "pt5h" "pt8h" "pt16h"
これは優先度の高いメッセージの再配信の場合です。最初の配信失敗から 30 分後に最初の再配信を試み、その 1 時間後 (最初の失敗から 1 時間半後) に 2 回目の再配信、2 時間後に 3 回目、3 時間後に 4 回目、4 時間後に 5 回目、5 時間後に 6 回目、8 時間後に 7 回目、16 時間後に 8 回目の再配信をそれぞれ試みます。その後は notices キーワードで指定した期間内まで 16 時間ごとに再配信を試みます。期間内に配信が成功しなければ、配信失敗通知が作成され、メッセージは差出人に返送されます。間隔のシンタックスは ISO 8601P に記述されており、『iPlanet Messaging Server リファレンスマニュアル』でも説明されています。
normalbackoff "pt30m" "pt1h" "pt8h" "p1d" "p2d" "p1w"
最初の配信失敗から 30 分後に最初の再配信を試み、その 1 時間後に 2 回目の再配信、8 時間後に 3 回目、1 日後に 4 回目、2 日後に 5 回目、1 週間後に 6 回目の再配信をそれぞれ試みます。その後は notices キーワードで指定した期間内まで毎週、再配信を試みます。期間内に配信が成功しなければ、配信失敗通知が作成され、メッセージは差出人に返送されます。
最後に、優先度によらない、すべての配信失敗メッセージの例を示します。
backoff "pt30m" "pt120m" "pt16h" "pt36h" "p3d"
nonurgentbackoff、normalbackoff、および urgentbackoff で置き換えなければ、どのメッセージも、最初の配信失敗から 30 分後に最初の再配信を試み、その 120 分後に 2 回目の再配信、16 時間後に 3 回目、36 時間後に 4 回目、3 日後に 5 回目の再配信をそれぞれ試みます。その後は notices キーワードで指定した期間内まで 3 日ごとに再配信を試みます。期間内に配信が成功しなければ、配信失敗通知が作成され、メッセージは差出人に返送されます。
チャネル実行ジョブのプールを処理する
キーワード : pool複数のチャネルが 1 つのプール内で動作するように設定すると、複数のチャネルが同じプールのリソースを共有できるようになります。特定のチャネル専用に指定されているプール内でほかのチャネルが動作するように設定することも可能です。各プール内のメッセージは優先度に基づいて自動的に適切な処理キューに割り当てられます。優先度の高いメッセージは優先度が低いメッセージよりも先に処理されます。(「サイズに基づくメッセージの優先度」 を参照)
pool キーワードを使用すると、ジョブが作成されるプールをチャネルごとに指定できます。pool キーワードの後ろには、現在のチャネルの配信ジョブのプール先となるプール名を指定する必要があります。プール名の長さの上限は 12 バイトです。
ジョブコントローラの概念と設定については、「ジョブコントローラファイル」、「ジョブコントローラ」、および 「サービスジョブの制限」を参照してください。
サービスジョブの制限
キーワード : maxjobs、filesperjobメッセージがチャネルキューに入れられるたびに、ジョブコントローラはメッセージを配信するためのジョブが実行されていることを確認します。これには、新規ジョブプロセスの開始、スレッドの追加、実行中のジョブの確認などの操作が含まれます。しかし、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 が使用されていない場合のデフォルト値は 100 に設定されています。通常、maxjobs には、そのチャネルが使用するプールまたはサービスプールで同時実行が可能な合計ジョブ数と同じ値、またはそれ以下の値を使用します。
サイズに基づくメッセージの優先度
キーワード : urgentblocklimit、normalblocklimit、nonurgentblocklimiturgentblocklimit、normalblocklimit、および nonurgentblocklimit キーワードは、サイズに基づいてメッセージの優先度を下げるように MTA に指定するためのものです。これらのキーワードは、ジョブコントローラがメッセージ処理時に適用する優先度に影響を及ぼします。
SMTP チャネルスレッド
キーワード : threaddepthマルチスレッドの SMTP クライアントは、メッセージを宛先ごとにそれぞれ異なるスレッドに割り当てるために、送信メッセージを並べ替えます。threaddepth キーワードは、マルチスレッドの SMTP クライアントが 1 つのスレッドに割り当てられるメッセージの数を制限し、それ以上のメッセージがある場合には別のスレッドに割り当てるよう指定します。通常、同じ宛先へのメッセージはすべて 1 つのスレッドによって処理されますが、このキーワードを指定すると、それらのメッセージが複数のスレッドによって処理されるようになります。
threaddepth キーワードは、チャネルの接続先の SMTP サーバが複数の接続を同時に処理できる場合に、デーモンルーター TCP/IP チャネル (ある特定の SMTP サーバに接続する TCP/IP チャネル) 上でマルチスレッドを確立する際に便利です。
チャネルに対するバックログが threaddepth で指定されている以上の数に達すると、ジョブコントローラはより多くのリソースをそのチャネルのキューにあるメッセージの処理に割り当てようとします。チャネルがマルチスレッドの場合、ジョブコントローラはメッセージを処理するジョブがそのチャネルに対して新しくスレッドを開始するように指示し、すべてのジョブのスレッド数がそのチャネルの制限に達している場合 (tcp_* チャネルの MAX_CLIENT_THREADS オプション) は、新しいプロセスを開始するように指示します。シングルスレッドのチャネルに対しては、新しいプロセスを開始するように指示します。ただし、チャネルのジョブ数 (maxjobs) またはプールのジョブ数 (JOB_LIMIT) が制限に達している場合、新しいジョブは開始されません。
複数アドレスの拡張
キーワード : expandlimit、expandchannel、holdlimit大部分のチャネルは複数の宛先アドレスを持つメッセージを受け入れますが、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 ポストマスターが手動で介入するまで reprocess キュー内で未処理のまま待機します。
サービス変換を有効にする
キーワード : service、noserviceservice キーワードは、CHARSET-CONVERSION エントリにかかわらず、無条件でサービスを有効にします。noservice キーワードが設定されている場合、チャネルで受信するメッセージのサービス変換は、CHARSET-CONVERSION で有効にします。
アドレス処理を設定する
この節ではアドレス処理を行うキーワードを説明します。この章には、以下の節があります。
「サービス変換を有効にする」
「メッセージがキューから取り出されるときのアドレス書き換え」
「不完全なアドレスを修正する際に使用するホスト名を指定する」
「Recipient ヘッダー行がないメッセージを有効にする」
「エンベロープ To: アドレスと From: アドレスから Received: ヘッダー行を作成する」
アドレスのタイプと規則
キーワード : 822、733、uucp、header_822、header_733、header_uucpこのキーワードのグループでは、チャネルでサポートするアドレスのタイプが制御されます。転送レイヤ (メッセージエンベロープ) に使われるアドレスとメッセージヘッダーに使われるアドレスとは区別されます。
822 (sourceroute)
ソースルートのエンベロープアドレス。このチャネルでは、ソースルートを含む、完全な RFC 822 形式のエンベロープアドレス規則がサポートされます。sourceroute キーワードは、822 と同義で使用できます。ほかのエンベロープアドレスタイプのキーワードが指定されていない場合、これがデフォルトになります。
733 (percents)
パーセント記号のエンベロープアドレス。このチャネルでは、ソースルートを除く、完全な RFC 822 形式のエンベロープアドレスがサポートされます。ソースルートは、パーセント記号の規則を使用して、書き換える必要があります。percents キーワードは、733 と同義で使用できます。
注 SMTP チャネルで 733 アドレス規則を使用すると、SMTP エンベロープの転送レイヤのアドレスでもこれらの規則が使われるようになります。これは、RFC 821 に違反する場合があるため、必要時以外は 733 を使用しないようにします。
uucp (bangstyle)
Bang スタイルのエンベロープアドレス。このチャネルでは、エンベロープの RFC 976 の bang スタイルアドレス規則に準拠するアドレスが使用されます (たとえば、UUCP チャネル)。bangstyle キーワードは、uucp と同義で使用できます。
header_822
ソースルートのヘッダーアドレス。このチャネルでは、ソースルートを含む、完全な RFC 822 形式のヘッダーアドレス規則がサポートされます。ほかのヘッダーアドレスタイプのキーワードが指定されていない場合、これがデフォルトになります。
header_733
パーセント記号のヘッダーアドレス。このチャネルでは、ソースルートを除く、完全な RFC 822 形式のヘッダーアドレスがサポートされます。ソースルートは、パーセント記号の規則を使用して、書き換える必要があります。
注 メッセージヘッダーで 733 アドレス規則を使用すると、RFC 822 と RFC 976 に違反する場合があります。このキーワードは、チャネルがソースルートアドレスを処理できないシステムに接続することが確実な場合以外は使用しないようにします。
header_uucp
UUCP または bang スタイルのヘッダーアドレス。このキーワードの使用はお勧めしません。使用すると RFC 976 に違反することになります。
! と % を使用するアドレスを解釈する
キーワード : bangoverpercent、nobangoverpercent、percentonlyアドレスは常に RFC 822 と RFC 976 に準拠して解釈されます。ただし、これらの規格で扱われていない複合アドレスの処理方法については、あいまいな部分があります。特に、A!B%C という形式のアドレスは次のどちらにも解釈できます。
A がルーティングホストで、C が最終的な宛先ホスト
または
C がルーティングホストで、A が最終的な宛先ホスト
RFC 976 では、メールプログラムが後者の規則を使ってアドレスを解釈できるという旨が示唆されていますが、そのような解釈が要求されるとは書かれていません。状況によっては、前者の解釈方法を使ったほうがよい場合があるかもしれません。bangoverpercent キーワードを使うと、前者の A!(B%C) のように解釈されます。nobangoverpercent キーワードを使うと、後者の (A!B)%C のように解釈されます。nobangoverpercent がデフォルトです。
注 このキーワードは、A!B@C 形式のアドレス処理に影響を与えません。これらのアドレスは、常に (A!B)@C として扱われます。このような処理は RFC 822 と RFC 976 の両方で義務付けられています。
percentonly キーワードで、bang パスが無視されます。このキーワードが設定されている場合、パーセントはルーティング用に解釈されます。
アドレスにルーティング情報を追加する
キーワード : exproute、noexproute、improute、noimprouteMTA が扱うアドレスモデルは、すべてのシステムがほかのすべてのシステムのアドレスを知っていて、それらのアドレスにどのように到達するかを知っているものと想定しています。しかし、このような理想は、世界に知られていない 1 つ以上のシステムにチャネルが接続する (たとえば、プライベートな TCP/IP ネットワーク内にあるマシン) 場合など、どのような場合にも当てはまるとはかぎりません。このチャネルにあるシステムのアドレスは、サイトの外にあるリモートのシステムからは見ることができないようになっているのかもしれません。このようなアドレスに応答したい場合は、ローカルマシンを通ってメッセージをルーティングするようリモートのシステムに指示するソースルートを含んでいなければなりません。そうすれば、ローカルマシンは (自動的に) これらのマシンにルーティングすることができます。
exproute キーワード (explicit routing の略) は、アドレスがリモートのシステムに渡されるときに、関連するチャネルが明示的なルーティングを要するということを MTA に指示します。このキーワードがチャネルに指定されている場合、MTA により、ローカルシステムの名前 (またはローカルシステムの現在のエイリアス) を含むルーティング情報が、チャネルに一致するすべてのヘッダーアドレスとすべてのエンベロープの From: アドレスに追加されます。noexproute はデフォルトで、ルーティング情報を追加しないことを指定します。
EXPROUTE_FORWARD オプションは、後方を探すアドレスに対する exproute の動作を制限するために使用できます。MTA が適切なルーティングを独自に実行することができないチャネルを通して相手システムに接続する場合には、別の状況が発生します。この場合、ほかのチャネルに関連するアドレスはすべて、能力のないシステムに接続するチャネルに送られたメール内で使用されるときに、ルーティング指定を必要とします。
この状況を処理するには、黙示的なルーティングと improute キーワードが使用されます。MTA は、ほかのチャネルに合致するすべてのアドレスが improute マークの付いたチャネルに送られたメールの中で使用されるときにルーティングを必要とすることを知っています。デフォルトの noimproute は、指定されたチャネルに送られるメッセージのアドレスにルーティングの情報を加えないことを指定するものです。IMPROUTE_FORWARD オプションは、後方を探すアドレスに対する improute の動作を制限するために使用できます。
exproute および improute キーワードは慎重に使用するようにしてください。これらのキーワードは、アドレスを長く、より複雑にし、相手側のシステムで使用されているインテリジェントなルーティング機能を妨害する可能性があります。明示的ルーティングと黙示的ルーティングを、指定ルートと混同しないようにしてください。指定ルートは、書き換え規則からアドレスにルーティング情報を挿入するときに使用されます。これは、特殊な A@B@C 書き換え規則テンプレートによってアクティブになります。
指定ルートは、アクティブになったときに、ヘッダーとエンベロープ内のすべてのアドレスに適用されます。指定ルートは特定の書き換え規則によってアクティブになるもので、通常、現在使用中のチャネルとは関係がありません。一方、明示的ルーティングと黙示的ルーティングはチャネルごとに制御され、挿入されるルートアドレスは常にローカルシステムのものです。
明示的なルーティングアドレスの書き換えを無効にする
キーワード : routelocalroutelocal チャネルキーワードでは、アドレスをチャネルに書き換える際に、MTA にアドレスのすべての明示的ルーティングを短絡化しようとします。明示的にルーティングされたアドレス (!、%、または @ の文字を使用) は簡略化されています。
このキーワードを内部 TCP/IP チャネルなどの「内部」チャネルに使用すると、SMTP リレーブロッキングの設定を簡単にすることができます。
ただし、明示的 % やその他のルーティングを必要とする可能性があるチャネルには、このキーワードを使用してはいけません。
メッセージがキューから取り出されるときのアドレス書き換え
キーワード : connectalias、connectcanonical通常、MTA はチャネルのキューにメッセージを入れるときにアドレスを書き換えます。メッセージがキューから取り出されるときに、さらに書き換えが行われることはありません。したがって、ホスト名が変更されたときにチャネルのキュー内に元のホスト名宛てのメッセージがまだ残っていても、問題は生じません。
connectalias キーワードは、受取人のアドレスに書かれているホストに配信するように、MTA に指示します。デフォルトでは、このキーワードが使用されます。connectcanonical キーワードは、MTA が接続するシステムのホストエイリアスに接続するように指示します。
不完全なアドレスを修正する際に使用するホスト名を指定する
キーワード : remotehost、noremotehost、defaulthost、nodefaulthostMTA は、間違って設定された、あるいは標準に準拠しないメーラーや SMTP クライアントから、ドメイン名を含まないアドレスを受け取ることがよくあります。MTA は、そのようなメッセージを通過させる前に、アドレスを有効な形式にしようと試みます。MTA は、アドレスにドメイン名を付け加える (たとえば、@siroe.com を mrochek に付け加える) ことによってそれを行います。
エンベロープ To: アドレスにドメイン名がない場合、MTA では常にローカルホスト名を追加するものと仮定します。From: アドレスなどのその他のアドレスの場合、MTA SMTP サーバには、ドメイン名に関して少なくとも 2 つのオプションが考えられます。それらのオプションとは、ローカル MTA ホスト名と、クライアント SMTP でレポートされたリモートホスト名です。また場合によっては、そのチャネルで受信するメッセージに特定のドメイン名を追加するという、3 つめのオプションが考えられる可能性もあります。最初の 2 つのオプションは、どちらもある程度の頻度で発生することが考えられるため、適切なものと考えられます。不適切に構成された SMTP クライアントを扱う場合には、リモートホストのドメイン名を使用することが適切です。メッセージを掲示するために SMTP を使う POP や IMAP クライアントのように軽量級のリモートメールクライアントを扱う場合には、ローカルホストのドメイン名を使用することが適切です。また、(POP や IMAP などの) 軽量級のリモートメールクライアントの場合は、各クライアントにはローカルホスト以外の専用の特定ドメイン名があります。この場合には、その他の特定ドメイン名の追加が適当な場合もあります。MTA がとれる最善の策は、チャネルごとに選択できるようにすることです。
noremotehost チャネルキーワードはローカルホストの名前が使用されるように指定するものです。デフォルトのキーワードは noremotehost です。
defaulthost チャネルキーワードを使用して、受信側のユーザ ID に追加する特定のホスト名を指定します。このキーワードの後ろには、チャネルで受信するアドレスを完成させるためのドメイン名 (エンベロープ From: 内とヘッダー内) を追加します。送信チャネルの場合は、defaulthost キーワードの最初の引数もエンベロープ To: アドレスに影響します。 省略可能な 2 番目のドメイン名 (中に少なくとも 1 つのピリオドが含まれている) を指定してエンベロープ To: アドレスを完成させることもできます。 nodefaulthost はデフォルトです。
switchchannel キーワードは、前のセクション「受信メール用代替チャネル (切り替えチャネル)」で説明されているとおり、受信 SMTP 接続を特定のチャネルに関連付けるために使用することができます。この機能は、リモートのメールクライアントを、適切な処理を受けることができるチャネルにグループ化するために使用することができます。代わりの方法として、(標準に準拠しないクライアントが多数に使用されていたとしても) 標準に準拠するリモートメールクライアントを配備する方が、MTA ホストでネットワーク全体の問題を解決しようとするより簡単です。
Recipient ヘッダー行がないメッセージを有効にする
キーワード : missingrecipientpolicyRFC 822 (Internet) メッセージには、受取人ヘッダー行である To:、Cc:、または Bcc: ヘッダー行が必要です。そのようなヘッダー行がないメッセージは無効になります。しかし、うまく稼働していないユーザエージェントやメーラー (たとえば、古いバージョンの sendmail) は、無効なメッセージを受け入れます。
missingrecipientpolicy キーワードは、そのようなメッセージを扱うときに使用すべきアプローチを指定する整数値をとります。このキーワードが明示的に表現されていない場合は、デフォルト値の 0 が使用され、To: ヘッダーにエンベロープ To: アドレスが使用されます。
表 8-8    missingrecipientpolicy の値
値
動作
MISSING_RECIPIENT_POLICY オプションは、MTA システムがデフォルトでこの動作をするように設定するためのものであることに注意してください。初期の Messaging Server 設定では、MISSING_RECIPIENT_POLICY が 1 に設定されます。
不正な空白の受取人ヘッダーを削除する
キーワード : dropblank、nodropblankRFC 822 (インターネット) メッセージでは、To:、Resent-To:、Cc:、Resent-Cc: ヘッダーにはアドレスが少なくとも 1 つ必要です。空白値は使用できません。ただし、一部のメーラーでは、このような不正なヘッダーが生成されることがあります。ソースチャネルに dropblank チャネルキーワードが指定されている場合、MTA により受信メッセージからこれらの不正な空白ヘッダーが削除されます。
チャネル固有のリバースデータベースの使用を有効にする
キーワード : reverse、noreversereverse キーワードは、チャネルのキューに入れられたメッセージ内のアドレスを、アドレスリバースデータベースまたは REVERSE マッピング (存在する場合) のいずれかに対して照合し、必要に応じて変更するように指示するものです。また、noreverse は、チャネルのキューに入れられたメッセージのアドレスを、アドレスリバース処理から外すことを指定するものです。デフォルトのキーワードは reverse です。詳細については、「内部形式から公的な形式にアドレスを変換するには」を参照してください。
制限されたメールボックスのエンコーディングを有効にする
キーワード : restricted、unrestrictedメールシステムの中には、RFC 822 で許されるアドレスのすべての形式を扱うことができないものもあります。もっとも一般的に見られる例は、設定ファイルが不適切に設定された sendmail ベースのメーラーです。引用されたローカルパート (あるいはメールボックス仕様) が頻繁に見られる問題の原因です。
これは大きな問題なので、この問題を回避するための方策が RFC 1137 に記載されています。基本的なアプローチは、アドレスから引用を取り除き、引用を要する文字を、アトムに許可する文字にマップする変換規則を適用することです (ここで使われているアトムという語の定義については RFC 822 を参照)。たとえば、上記のアドレスは次のようになります。
restricted チャネルキーワードでは、MTA に、このチャネルがこのエンコーディングを必要とするメールシステムに接続することを示します。すると MTA は、メッセージがチャネルに書かれるときに、ヘッダーとエンベロープアドレスの両方において引用されたローカルパートをエンコードします。そのチャネルの受信メールのアドレスは自動的にデコードされます。unrestricted キーワードは、RFC 1137 エンコーディングとデコーディングを実行するように MTA に指示します。デフォルトは unrestricted キーワードです。
注 restricted キーワードは、引用されたローカルパートを受け入れることができないシステムに接続するチャネルに対して適用します。引用されたローカルパートを実際に生成するチャネルには適用しないでください。(そのようなアドレスを生成することができるチャネルは、そのようなアドレスを処理することができると想定されるからです。)
Return-path: ヘッダー行を生成する
キーワード : addreturnpath、noaddreturnpath通常、Return-path: ヘッダー行の追加は、最終的な配信を実行するチャネルが行います。ただし、ims-ms チャネルなどの一部のチャネルでは、MTA で Return-path: ヘッダー行を追加する方が、チャネルで追加するよりも効率的です。addreturnpath キーワードでは、このチャネルのキューにメッセージを入れる際に、MTA により Return-path: ヘッダーが追加されます。
エンベロープ To: アドレスと From: アドレスから Received: ヘッダー行を作成する
キーワード : receivedfor、noreceivedfor、receivedfrom、noreceivedfromreceivedfor キーワードは、メッセージの宛先になっているエンベロープ受取人アドレスが 1 つだけの場合は、そのエンベロープの To: アドレスを Received: ヘッダー行に含めるように MTA に指示します。デフォルトのキーワードは receivedfor です。noreceivedfor キーワードは、エンベロープアドレス情報を含めずに、Received: ヘッダー行を作成するよう MTA に指示します。
receivedfrom キーワードは、たとえばメーリングリストの拡大などのために MTA がエンベロープ From: アドレスを変更した場合、受信メッセージの Received: ヘッダー行を作成する際は MTA に元のエンベロープの From: アドレスを含めるように指示します。receivedfrom はデフォルトのキーワードです。noreceivedfrom キーワードは、元のエンベロープ From: アドレスを使わずに Received: ヘッダー行を作成するよう MTA に指示します。
アドレスヘッダー行内のコメントを処理する
キーワード : commentinc、commentmap commentomit、commentstrip、commenttotal、sourcecommentinc、sourcecommentmap、sourcecommentomit、sourcecommentstrip、sourcecommenttotalMTA は必要なときだけヘッダー行の内容を解釈します。ただし、省略形のアドレスを書き換えてなくすために (それ以外の場合は、有効なアドレスに変換するために)、アドレスを含むすべての登録されたヘッダー行を解析しなければなりません。この処理の途中では、コメント (括弧で囲まれた文字列) が抽出され、ヘッダー行が再構成されるときに変更されるか、あるいは除外されることがあります。
この動作は、commentinc、commentmap、commentomit、commentstrip、および commenttotal キーワードを使用して制御されます。commentinc キーワードは、ヘッダー行内のコメントを残すように MTA に指示します。デフォルトでは、このキーワードが使用されます。commentomit キーワードは、アドレスヘッダー、たとえば To:、From:、あるいは Cc: ヘッダー行からコメントを取り除くよう MTA に指示します。
commenttotal キーワードは、MTA にすべてのヘッダー行 (Received: ヘッダー行を除く) からコメントを削除するように指示します。このキーワードは通常特に使い道はなく、お勧めもしません。commentstrip は MTA にすべてのコメントフィールドから、すべての非原子的文字列を削除するように指示します。commentmap キーワードは、COMMENT_STRINGS マッピングテーブルを通じてコメント文字列を実行します。
ソースチャネルでは、この動作は sourcecommentinc、sourcecommentmap、sourcecommentomit、sourcecommentstrip、および sourcecommenttotal の各キーワードを使用して制御されます。sourcecommentinc キーワードは、MTA にヘッダー行のコメントを維持するように指示します。デフォルトでは、このキーワードが使用されます。sourcecommentomit キーワードは、MTA にアドレスヘッダー (To:、From:、Cc: などのヘッダー) からすべてのコメントを削除するように指示します。commenttotal キーワードは、MTA にすべてのヘッダー行 (Received: ヘッダー行を除く) からコメントを削除するように指示します。このキーワードは通常特に使い道はなく、お勧めもしません。最後に、sourcecommentstrip キーワードは MTA に、すべてのコメントフィールドから非原子的文字を削除するように指示します。sourcecommentmap キーワードは、ソースチャネルを通じてコメント文字列を実行します。
COMMENT_STRINGS マッピングテーブルのシンタックスは、次のとおりです。
エントリテンプレートに $Y フラグが設定されている場合、元のコメントは指定したテキスト (閉じる括弧を含むこと) に置き換えられます。
アドレスヘッダー行内の個人名を処理する
キーワード : personalinc、personalmap、personalomit、personalstrip、sourcepersonalinc、sourcepersonalmap、sourcepersonalomit、sourcepersonalstrip書き換えプロセスの際には、省略形のアドレスを書き換えてなくすために (それ以外の場合は、有効なアドレスに変換するために)、アドレスを含むすべてのヘッダー行を解析しなければなりません。このプロセスの際に、個人名 (角括弧で区切られたアドレスの前にある文字列) が抽出されますが、これはヘッダー行を再構築するときに変更したり除外したりできます。
この動作は、personalinc、personalmap、personalomit、および personalstrip キーワードの使用によって制御されます。キーワード personalinc は、ヘッダー内の個人名を残すよう MTA に指示します。デフォルトでは、このキーワードが使用されます。personalomit キーワードは、MTA にすべての個人名を削除するように指示します。personalstrip キーワードは、MTA にすべての個人名フィールドから、すべての非原子的文字を削除するように指示します。personalmap キーワードは、MTA に PERSONAL_NAMES マッピングテーブルを通じて個人名を実行するように示します。
ソースチャネルでは、この動作は sourcepersonalinc、sourcepersonalmap、sourcepersonalomit、または sourcepersonalstrip キーワードを使用して制御されます。sourcepersonalinc キーワードは、MTA にヘッダーの個人名を維持するように指示します。デフォルトでは、このキーワードが使用されます。sourcepersonalomit キーワードは、MTA にすべての個人名を削除するように指示します。最後に、sourcepersonalstrip キーワードは MTA に、すべての個人名フィールドから非原子的文字を削除するように指示します。sourcepersonalmap キーワードは、MTA にソースチャネルを通じて個人名を実行するように示します。
PERSONAL_NAMES マッピングテーブルのシンタックスは、次のとおりです。
テンプレートで $Y フラグが設定されている場合、元の個人名は指定したテキストで置き換えられます。
エイリアスファイルとエイリアスデータベースプローブを指定する
キーワード : aliaslocal通常、ローカルチャネル (UNIX の1 チャネル) に書き換えられるアドレスのみが、エイリアスファイルとエイリアスデータベースで検索されます。aliaslocal キーワードをチャネルに使用すると、そのチャネルに書き換えられるアドレスも、エイリアスファイルとエイリアスデータベースで検索するようにできます。作成される検索プローブの形式は、ALIAS_DOMAINS オプションで制御されます。
サブアドレスを処理する
キーワード : subaddressexact、subaddressrelaxed、subaddresswildサブアドレスの概念の背景として、ネイティブと ims-ms のチャネルでは + 記号がアドレスのローカル部分 (メールボックスの部分) として解釈されます。特に、name+subaddress@domain の形式のアドレスでは、MTA はプラス記号の後ろのメールボックス部分をサブアドレスとみなします。ローカルチャネルでは、サブアドレスを追加の余分な情報とみなして、サブアドレスを考慮せず実際にアカウント名への配信を行います。ims-ms チャネルでは、サブアドレスを配信先のフォルダ名と解釈します。
また、サブアドレスはローカルチャネル (UNIX の L チャネル) によるエイリアスの検索、aliaslocal キーワードでマークされたすべてのチャネルによるエイリアスの検索、およびディレクトリチャネルによるメールボックスの検索に影響を与えます。これらの検索に対するサブアドレスの処理については、設定可能です。アドレスをエントリと比較する場合、MTA では必ず最初に完全一致の検索にサブアドレスを含むメールボックス全体を確認します。追加のチェックを実行するかどうかは、設定可能です。
subaddressexact キーワードは、MTA にエントリの一致の確認中に、特別なサブアドレスの処理を行わないように指示します。エイリアスが一致するとみなされるためには、サブアドレスを含むメールボックス全体が一致しなければなりません。その他の比較 (特に、ワイルドカードによる比較や、サブアドレスを削除した比較) は行われません。subaddresswild キーワードは、MTA に、サブアドレスを含む完全な一致を検索したあと、「名前+*」の形式のエントリを検索するように指示します。subaddressrelaxed キーワードは MTA に、完全一致と「名前+*」の形式の一致を検索したあと、名前の部分のみの一致を検索するように指示します。subaddressrelaxed では、次の形式のエイリアスエントリが、名前か「名前+サブアドレス」に一致し、名前を新規の名前に、「名前+サブアドレス」を「新規の名前+サブアドレス」に変換します。デフォルトのキーワードは subaddressrelaxed です。
このように、subaddresswild キーワードや subaddressrelaxed キーワードは、エイリアスやディレクトリが使用されていて、ユーザが任意のサブアドレスを使用してメールの受信を希望する場合に便利です。これらのキーワードを使用することにより、アドレスの各サブアドレスに独立のエントリを作成する必要がなくなります。
これらのキーワードは、ローカルチャネル (UNIX の L チャネル) とディレクトリチャネル、および aliaslocal キーワードでマークされたチャネルにかぎり使用できます。
標準の Messaging Server 設定では、実際に subaddressrelaxed キーワード (ほかのキーワードが明示的に使用されていない場合のデフォルト) を指定した L チャネルでリレーします。
チャネル固有の書き換え規則チェックを有効にする
キーワード : rules、norulesrules キーワードは、MTA にこのチャネルにおけるチャネル固有の書き換え規則のチェックを強制するように指示します。デフォルトでは、このキーワードが使用されます。norules キーワードは、MTA にこのチャネルをチェックしないように指示します。これらの 2 つのキーワードは、通常デバッグに使用され、実際のアプリケーションで使用されることはほとんどありません。
ソースルートを削除する
キーワード : dequeue_removeroutedequeue_removeroute キーワードは、メッセージがキューから取り出されると、エンベロープの To: アドレスからソースルートを削除します。現在、このキーワードは tcp-* チャネルだけに実装されています。ソースルートを正しく処理しないシステムにメッセージを転送する場合に便利なキーワードです。
エイリアスからアドレスを指定する
キーワード : viaaliasoptional、viaaliasrequiredviaaliasrequired は、チャネルに一致する最終受取人アドレスをエイリアスで作成するように指定するキーワードです。最終受取人アドレスとは、関連するエイリアス拡張を行ったあとで一致するアドレスです。アドレスを受取人アドレスとして MTA に直接渡すことはできません。チャネルに書き換えただけでは十分ではないからです。チャネルに書き換えたアドレスをエイリアスを使って拡張し、間違いなくそのチャネルと一致していることを確認する必要があります。
たとえば、ローカルチャネルで viaaliasrequired キーワードを使って、任意のアカウント (たとえば UNIX システム上のネイティブな任意の Berkeley メールボックス) に配信させないようにすることができます。
デフォルトは viaaliasoptional であり、そのチャネルに一致する最終受取人アドレスはエイリアスで作成する必要がありません。
ヘッダー処理を設定する
この節ではヘッダーとエンベロープ情報を扱うキーワードを説明します。この章には、以下の節があります。
「埋め込まれたヘッダーを書き換える」
埋め込まれたヘッダーを書き換える
キーワード : noinner、innerヘッダー行の内容は必要なときにだけ解釈されます。ただし、メッセージの中にメッセージを埋め込むことができる能力 (メッセージ /RFC822) があるために、MIME メッセージには複数のメッセージヘッダーが含まれていることもあります。通常、MTA は一番外側のメッセージヘッダーだけを解釈し、書き換えます。オプションとして、メッセージの内部ヘッダーに書き換え規則を適用するように指示することも可能です。
この動作は、noinner および inner キーワードを使用して制御できます。キーワード noinner は、内部ヘッダー行を書き換えないように MTA に指示するものです。デフォルトでは、このキーワードが使用されます。キーワード inner は、メッセージを解析して、内部ヘッダーを書き換えるように MTA に指示します。これらのキーワードはどのチャネルにも適用できます。
メッセージヘッダー行を選択して削除する
キーワード : headertrim、noheadertrim、headerread、noheaderread、innertrim noinnertrimMTA には、メッセージから特定のメッセージヘッダー行をトリミングする (取り除く)、チャネル単位の機能があります。これは、チャネルキーワードと関連する 1 つまたは 2 つのヘッダーオプションファイルの組み合わせによって行われます。headertrim キーワードは、チャネルに関連するヘッダーオプションファイルを作成し、元のメッセージヘッダーが処理されたあと、チャネルのキューに入れられたメッセージのヘッダーをそれに基づいてトリムするよう MTA に指示します。noheadertrim キーワードは、ヘッダートリミングを行いません。デフォルトは noheadertrim キーワードです。
innertrim キーワードは、埋め込まれた MESSAGE/RFC822 部分のような、内部メッセージ部分にヘッダートリミングを実行するよう MTA に指示します。noinnertrim キーワードはデフォルトで、内部メッセージ部分のどのヘッダーにもトリミングを実行しないよう MTA に指示します。
headerread キーワードは、元のメッセージヘッダーが処理される前に、そのチャネルに関連しているヘッダーオプションファイルを参照して、そのソースチャネルによってキューに入れられているメッセージのヘッダーをトリムするよう MTA に指示します。一方、headertrim ヘッダートリミングはメッセージが処理されたあとに適用され、ソースチャネルではなく宛先チャネルになります。noheaderread キーワードは、キューに入っているメッセージのヘッダートリミングを行いません。noheaderread がデフォルトです。
headeromit および headerbottom キーワードとは異なり、headertrim および headerread キーワードはどのチャネルにも適用できます。ただし、重要なヘッダー情報をメッセージから取り除くと MTA が正常に動作しなくなることもあるので、注意してください。取り除くヘッダーまたは制限するヘッダーを選ぶ際には、十分な配慮が必要です。この機能があるのは、特定のヘッダー行を取り除いたり、制限したりしなければならないような状況が発生することがあるからです。
ヘッダー情報をメッセージから取り除くと、MTA が正常に動作しなくなることもあります。取り除くヘッダーまたは制限するヘッダーを選ぶ際には、配慮が必要です。これらのキーワードは、特定のヘッダー行を取り除いたり、制限したりしなければならないような稀な状況で指定します。ヘッダー行を取り除く前に、そのヘッダー行の用途を十分に理解し、それを取り除いた場合の結果を考慮してください。
headertrim および innertrim キーワードのヘッダーオプションファイルには、channel_headers.opt という形式の名前があります。このチャネルには、ヘッダーオプションファイルが関連付けられているチャネルの名前が入ります。同じように、headerread キーワードのヘッダーオプションファイルには、channel_read_headers.opt の形式で名前があります。これらのファイルは MTA の設定ディレクトリ (server_root/msg-instance/imta/config/) に保存されます。
X-Envelope-to: ヘッダー行の生成と削除
キーワード : x_env_to、nox_env_tox_env_to および nox_env_to キーワードは、特定のチャネルのキューに入れられたメッセージのコピーに X-Envelope-to ヘッダー行を生成するかどうかを制御します。single キーワードでマークされているチャネルでは、x_env_to はこれらのヘッダーの生成を有効にし、nox_env_to はキュー内のメッセージからこれらのヘッダーを削除します。デフォルトは nox_env_to です。
x_env_to キーワードには、有効にするための single キーワードが必要です。
日付表示を 2 桁から 4 桁に変換する
キーワード : datefour、datetwoオリジナルの RFC 822 仕様では、メッセージヘッダーの日付フィールドに 2 桁の年表示を使用することが規定されています。これはあとで RFC 1123 により 4 桁に変更されました。しかし、古いメールシステムの中には、4 桁の日付を受け入れないものもあります。また、新しいメールシステムの中には、2 桁の日付を受け入れなくなったものもあります。
注
datefour および datetwo キーワードは、MTA によるメッセージヘッダー内の日付フィールド処理を制御するものです。datefour キーワードがデフォルトで、すべての年表示フィールドを 4 桁に展開するように MTA に指示します。値が 50 以下の 2 桁の日付表示には 2000 が加えられ、50 より大きいものには 1900 が付け加えられます。
datetwo キーワードは、4 桁の日付表示から先頭の 2 桁を取り去るように MTA に指示します。これは、2 桁の日付表示を要求する、標準に準拠していないメールシステムとの互換性を提供する目的で行われます。その他の目的のために使用してはなりません。
日付の曜日を指定する
キーワード : dayofweek、nodayofweekRFC 822 仕様では、メッセージヘッダー内の日付フィールドにおいて、日付の前に曜日を付けることができます。ただし、システムの中には曜日情報を受け入れられないものもあります。そのため、ヘッダーに含めると便利な情報であるにもかかわらず、曜日情報を含めないシステムもあります。
dayofweek および nodayofweek キーワードは、MTA による曜日情報処理を制御するものです。dayofweek キーワードがデフォルトで、これは曜日情報を残し、曜日情報がない場合にはその情報を月日 / 時間ヘッダーに追加するよう MTA に指示します。
nodayofweek キーワードは、月日 / 時間ヘッダーから先頭の曜日情報を取り除くよう MTA に指示します。これは、この情報を適切に処理することができない、標準に準拠していないメールシステムとの互換性を提供する目的で行われます。その他の目的のために使用してはなりません。
長いヘッダー行を自動分割する
キーワード : maxheaderaddrs、maxheadercharsメッセージ転送形式、特に sendmail の実装の中には、長いヘッダー行を適切に処理できないものがあります。これは、ヘッダーが破壊されるだけでなく、誤ったメッセージ拒否の原因になりがちです。これは重大な規格違反ですが、よく発生する問題です。
MTA には、長いヘッダー行を複数の独立したヘッダー行に分割するチャネルごとの機能があります。maxheaderaddrs キーワードは 1 つの行にいくつのアドレスを含められるかを制御し、maxheaderchars キーワードは 1 行に何バイト分の文字を含められるかを制御します。どちらのキーワードにも、限度を指定する 1 つの整数引数が必要です。デフォルトでは、ヘッダー行の長さもアドレスの数も制限されていません。
ヘッダーの配置と折り返し
キーワード : headerlabelalign、headerlinelengthheaderlabelalign キーワードは、このチャネルのキューに入れられたメッセージヘッダーの配置ポイントを制御するものです。整数値の引数をとります。配置ポイントとは、ヘッダーの内容を揃えるためのマージンです。たとえば、配置ポイントが 10 のヘッダー行は次のようになります。
To: joe@siroe.com
From: mary@siroe.com
Subject: Alignment testデフォルトの headerlabelalign は 0 で、ヘッダーは揃えられません。headerlinelength キーワードは、このチャネルのキューに入れられたメッセージヘッダー行の長さを制御します。これよりも長い行は、RFC 822 の折り返し規則に基づいて折り返されます。
これらのキーワードは、メッセージキュー内にあるメッセージのヘッダー形式を制御するだけのものです。実際のヘッダーの表示は、通常、ユーザエージェントによって制御されます。さらに、ヘッダーはインターネットを転送されるときに何度もリフォーマットされるため、メッセージヘッダーをフォーマットしない単純なユーザエージェントといっしょに使用された場合には、これらのキーワードの効果が見られないこともあります。
ヘッダーの最大長を指定する
キーワード : maxproccharsたくさんのアドレスを含む長いヘッダー行の処理には、多くのシステムリソースを費やすことがあります。maxprocchars キーワードは、MTA が処理して書き換えることができるヘッダーの最大長を指定するために使用されます。これよりも長いヘッダーを持つメッセージも受け入れられて配信されますが、異なる点は、長いヘッダー行は書き換えられないということです。このキーワードには、1 つの整数引数が伴います。デフォルトでは、どのような長さのヘッダーも処理されます。
機密度チェック
キーワード : sensitivitynormal、sensitivitypersonal、sensitivityprivate sensitivitycompanyconfidential機密度チェックのキーワードは、チャネルが受け入れられる機密度の上限を設定するものです。デフォルトは sensitivitycompanyconfidential で、どの機密度レベルのメッセージも通過を許されます。Sensitivity: ヘッダーのないメッセージは、通常のメッセージ、つまり、機密度のもっとも低いメッセージとみなされます。このようなキーワードで指定された機密度よりも高い機密度が指定されたメッセージがチャネルのキューに入れられると、次のようなエラーメッセージが表示され、拒否されます。
message too sensitive for one or more paths used (使用されている 1 つ以 上のパスに対してメッセージの機密度が高すぎます。)
MTA では、受取人ごとではなく、メッセージごとに機密度のチェックが行われます。1 人の受取人の宛先チャネルが機密度チェックに失敗した場合、そのチャネルに関連付けられた受取人だけでなく、すべての受取人のメッセージが返送されます。
ヘッダーのデフォルト言語を設定する
キーワード : languageヘッダーのエンコードされた単語には、特定言語を含ませることが可能です。デフォルトの言語は、language キーワードで指定されます。
添付と MIME 処理
この節では添付と MIME 処理を扱うキーワードを説明します。この章には、以下の節があります。
「Encoding: ヘッダー行を無視する」
Encoding: ヘッダー行を無視する
キーワード : ignoreencoding、interpretencodingMTA は、Yes CHARSET-CONVERSION を使用して、さまざまな非標準のメッセージ形式を MIME に変更することができます。特に、RFC 1154 形式では非標準の Encoding: ヘッダー行が使用されます。しかし、ゲートウェイの中には、ヘッダー行に対して誤った情報を出すものもあり、その結果、このヘッダー行を無視したほうがいい場合もあります。ignoreencoding キーワードは、Encoding: ヘッダー行をすべて無視するよう MTA に指示するものです。
注 MTA の CHARSET-CONVERSION が有効になっていないかぎり、このようなヘッダーはいずれにしても無視されます。interpretencoding キーワードは、特にほかの設定が行われている場合を除き、MTA にすべての Encoding: ヘッダー行に注目するように指示します。これはデフォルトです。
メッセージあるいは部分メッセージの自動再組立
キーワード : defragment、nodefragmentMIME 規格には、メッセージをより小さな部分に分割するための message/partial コンテンツタイプがあります。これはメッセージがサイズ制限のあるネットワークを通過する場合、または信頼性の低いネットワークを通過する場合に便利です。メッセージの断片化により、ある種の「チェックポイント」が提供され、メッセージの転送中にネットワークエラーが発生した場合でも、操作の不要な繰り返しを防ぐことができます。メッセージが宛先に到着したときに自動的に再組み立てが行われるように、それぞれの部分に情報が含まれています。
MTA では、defragment チャネルキーワードと再組立チャネルを使うことによって、メッセージの再組み立てを行うことができます。チャネルが defragment でマークされていれば、このチャネルのキューに入れられるメッセージまたは部分メッセージはすべて、代わりに再組立チャネルのキューに入れられます。すべての部分が到着したら、メッセージは再構築されて本来の宛先に送られます。nodefragment は、このような特別な処理を無効にするものです。デフォルトのキーワードは nodefragment です。
大きなメッセージの自動断片化
キーワード : maxblocks、maxlines電子メールシステムまたはネットワーク転送形式の中には、特定のサイズを超えるメッセージを処理できないものがあります。MTA には、チャネルごとにそのような制限を課す機能があります。設定されたサイズよりも大きなメッセージは自動的に複数の、より小さなメッセージに分割 (断片化) されます。このような断片に使用されるコンテンツタイプは message/partial で、同じメッセージの各部分が互いに関連付けられ、受信先のメーラーによって自動的に再組立されるように固有 ID の引数が付け加えられます。
maxblocks および maxlines キーワードは、自動断片化の対象となるサイズ制限枠を課すために使用されます。これらのキーワードの後ろには 1 つの整数値が続きます。maxblocks キーワードは、1 つのメッセージに許可するブロックの最大数を指定します。1 つの MTA ブロックは通常 1024 バイトで、これは MTA オプションファイルにある BLOCK_SIZE オプションを使用して変更することができます。maxlines キーワードは、1 つのメッセージに許可する最大行数を指定します。これらの 2 つの制限は、必要に応じて同時に課すことができます。
メッセージヘッダーは、ある程度メッセージのサイズに含まれています。メッセージヘッダーを複数のメッセージに分割することはできないにもかかわらず、それ自体が指定されたサイズ制限を超えてしまうこともあるので、メッセージヘッダーのサイズを管理するためにかなり複雑なしくみが使われます。この論理は、MTA オプションファイルにある MAX_HEADER_BLOCK_USE と MAX_HEADER_LINE_USE オプションによって制御されます。
MAX_HEADER_BLOCK_USE は、0 から 1 までの間の実数を指定するために使用されます。デフォルト値は 0.5 です。この場合、メッセージのヘッダーは、(maxblocks キーワードで指定された) 1 つのメッセージが占めることができる合計のブロック数の半分を占めることができます。メッセージヘッダーがそれより大きい場合、MTA は MAX_HEADER_BLOCK_USE と maxblocks の積を、* MAX_HEADER_BLOCK_USE ヘッダーのサイズ (ヘッダーサイズは、実際のヘッダーサイズと maxblocks より小さいものとみなされる) としてとります。
たとえば、maxblocks が 10 で MAX_HEADER_BLOCK_USE がデフォルトの 0.5 である場合、5 ブロックより大きいメッセージヘッダーは 5 ブロックのヘッダーとして取り扱われ、メッセージのサイズが 5 あるいはそれ以下のブロックの場合、断片化されません。0 を指定すると、メッセージのサイズ制限をあてはめる場合にヘッダーは無視されます。
1 を指定すると、利用可能なサイズのすべてをヘッダーに使うことができます。それぞれの断片は、サイズ制限を超えたかどうかにかかわらず、常に最低 1 行のメッセージ行を含みます。MAX_HEADER_LINE_USE および maxlines キーワードも、同様に動作します。
メッセージ行の長さを制限する
キーワード : linelengthSMTP 仕様では、1000 バイトまでのテキスト行が許可されています。しかし、転送形式の中には、行長に制限を課すものもあります。linelength キーワードは、チャネルごとに許される最大のメッセージ行の長さを制限するしくみを提供します。特定のチャネルのキューに入れられたメッセージの中で、そのチャネルに指定された行長を超えるメッセージは自動的にエンコードされます。
MTA にはさまざまなエンコーディング方式が用意されており、エンコーディングの結果、行長は常に 80 バイト以下になります。エンコーディングが行われた元のメッセージは、適切なデコーディングのフィルタを通すことによって元の状態に戻すことができます。
注 エンコーディングは、行長を 80 バイトより短くするだけです。行長に 80 バイトより短い値を指定しても、指定された制限より短い行にできるとはかぎりません。
linelength キーワードでは、データのエンコーディングで転送用のソフト改行が実行されます。このエンコーディングは、通常受信側でデコードされるため、元の長い行が復元されます。ハード改行については、「Record, text」CHARSET-CONVERSION を参照してください。
メッセージのサイズ制限、ユーザ制限容量、権限
この節では、メッセージのサイズ制限、ユーザ制限容量、権限を設定するキーワードについて説明します。この章には、以下の節があります。
「絶対的なメッセージサイズ制限を指定する」
絶対的なメッセージサイズ制限を指定する
キーワード : blocklimit、noblocklimit、linelimit、nolinelimit、sourceblocklimitメッセージは断片化によって自動的に小さな部分に分割されますが、場合によっては、管理者が指定した制限より大きいメッセージを拒否しなければならないこともあります (たとえば、サービス拒否のアタックを回避するためなど)。
blocklimit、linelimit、および sourceblocklimit キーワードは、絶対的なサイズ制限を実施するために使用されます。これらのキーワードの後ろには、それぞれ 1 つの整数値が必要です。
blocklimit キーワードは、1 つのメッセージに許可するブロックの最大数を指定します。MTA は、これよりも多いブロックを含むメッセージがチャネルのキューに入れられるのを拒否します。1 つの MTA ブロックは通常 1024 バイトで、これは MTA オプションファイルにある BLOCK_SIZE オプションを使用して変更することができます。
sourceblocklimit キーワードは、受信メッセージに許可するブロックの最大数を指定します。MTA は、これよりも多いブロックを含むメッセージがチャネルのキューに入れられるのを拒否します。つまり、blocklimit は宛先チャネルに、sourceblocklimit はソースチャネルに適用されます。1 つの MTA ブロックは通常 1024 バイトで、これは MTA オプションファイルにある BLOCK_SIZE オプションを使用して変更することができます。
linelimit キーワードは、1 つのメッセージに許可する最大行数を指定します。MTA は、この数以上の行を含むメッセージがチャネルのキューに入れられるのを拒否します。これらの 2 つのキーワード (blocklimit と linelimit) は、必要に応じて同時に指定することができます。
同じ制限をすべてのチャネルに課すためには、LINE_LIMIT および BLOCK_LIMIT オプションを使用します。これらの制限は、すべてのチャネルに適用できるという利点があります。したがって、MTA サーバは、メッセージ受信情報を得る前に、それをメールクライアントに知らせることができます。この効果によって、メッセージ拒否の処理を簡略化できるプロトコルもあります。
nolinelimit および noblocklimit チャネルキーワードはデフォルトであり、LINE_LIMIT や BLOCK_LIMIT MTA オプションで適用されている全体的な制限以外の制限がないことを意味します。
制限容量超過ユーザへのメール配信を処理する
キーワード : holdexquota、noexquotanoexquota および holdexquota キーワードは、Berkeley メールボックスユーザ (UNIX) 宛てのメッセージの処理を制御します。ここでいうメッセージとは、ディスク制限容量を超過しているユーザがローカルチャネルのユーザ ID に配信したメッセージです。
noexquota は MTA に、制限容量を超過したユーザ宛てのメッセージを、差出人に返送するように指示します。holdexquota は MTA に、制限容量超過ユーザ宛てのメッセージを保留にするように指示します。これらのメッセージは、配信可能になるまで、またはタイムアウトになってメッセージ返送ジョブによって返送されるまで、MTA キュー内に保持されます。
MTA キュー領域でのファイル作成
この節では、MTA キュー領域でのファイル作成を指定してディスクリソースを制御するキーワードを説明します。この章には、以下の節があります。
「複数のアドレスを処理する方法を制御する」
複数のアドレスを処理する方法を制御する
キーワード : multiple、addrsperfile、single、single_sysMTA では、キューに入れられたそれぞれのメッセージに複数の宛先アドレスを使用できるようになっています。チャネルプログラムの中には、1 つの受取人を持つメッセージ、限定された数の受取人を持つメッセージ、あるいは 1 つのメッセージコピーにつき 1 つの宛先システムを持つメッセージしか処理できないものもあります。たとえば、SMTP チャネルのマスタープログラムは、(1 つのチャネルがすべての SMTP トラフィックのために使用されるのにもかかわらず) 1 つのトランザクションで 1 つのリモートホストとの接続を確立するため、そのホストへのアドレスのみが処理されます。
もう 1 つの例として、SMTP サーバの中には、1 度に処理できる受取人の数を制限し、このタイプのエラーを処理できないものもあります。
multiple、addrsperfile、single、および single_sys キーワードは、複数のアドレスを処理する方法を制御するために使用できます。single キーワードは、各宛先アドレス用にメッセージのコピーを 1 つずつ作成するように指定します。single_sys キーワードは、各宛先システム用にメッセージのコピーを 1 つずつ作成します。multiple キーワードは、デフォルトではチャネル全体のメッセージのコピーを 1 つ作成します。
注 どちらのキーワードを使用しても、メッセージがキューに入れられる各チャネルごとに最低 1 つずつメッセージのコピーが作成されることに注意してください。
addrsperfile キーワードは、チャネルのキューにある 1 つのメッセージファイルに関連付けられる受取人の最大数に制限を付けるために使用されます。これによって、1 つの操作で処理される受取人の数が制限されます。このキーワードは、1 つのメッセージファイルに許可する受取人アドレスの最大数を指定する 1 つの整数引数を必要とします。この数に達すると MTA は自動的にそれらを処理するために追加のメッセージファイルを作成します。(一般に、デフォルトの multiple キーワードはメッセージファイル内の受取人数に制限を課さないことを意味します。ただし SMTP チャネルのデフォルトは 99 です。)
複数のサブディレクトリにチャネルメッセージキューを拡散する
キーワード : subdirsデフォルトでは、チャネルのキューに入れられたすべてのメッセージは、ディレクトリ /imta/queue/channel-name にあるファイルとして格納されます。この「channel-name」はチャネルの名前です。ただし、TCP/IP チャネルのように、たくさんのメッセージを処理し、処理を待つメッセージファイルをたくさん格納しがちなチャネルの場合は、それらのメッセージファイルを複数のサブディレクトリに拡散するようなファイルシステムを使った方が処理能力が向上する可能性があります。この機能を提供するのが subdirs チャネルキーワードです。チャネルのメッセージを拡散するサブディレクトリの数を指定する整数を、このキーワードの後ろに付けます。
tcp_local single_sys smtp subdirs 10
ログ記録とデバッグを設定する
この節では、ログ記録とデバッグのキーワードについて説明します。
「ログ記録のキーワード」
ログ記録のキーワード
キーワード : logging、nologgingMTA は、メッセージがキューに出し入れされるたびにログを作成することができます。logging および nologging キーワードは、チャネルごとのメッセージログの作成を制御します。デフォルト設定では、すべてのチャネルに対してログが作成されます。特定のチャネルに対してログの作成を無効にするには、チャネル定義で logging の代わりに nologging キーワードを設定します。
ログ記録については、第 13 章「ログ記録とログ解析」を参照してください。
デバッグのキーワード
キーワード : master_debug、slave_debug、nomaster_debug、noslave_debugチャネルプログラムによっては、デバッグ目的のためにより詳細な診断出力を生成するオプションコードがあるものもあります。このチャネルごとのデバッグとの出力の生成機能を有効にするためのチャネルキーワードには 2 種類あります。master_debug キーワードはマスタープログラムのデバッグ出力を有効にし、slave_debug キーワードはスレーブプログラムのデバッグ出力を有効にします。デフォルトでは nomaster_debug および noslave_debug が有効になっているため、デバッグ出力は生成されません。
デバッグを有効にすると、デバッグ出力は各チャネルプログラムに関連付けられているログファイルに記述されます。ログファイルの場所はプログラムによって異なりますが、通常はログディレクトリにあります。マスタープログラムのログファイル名は、通常 x_master.log の形式をとります。ここで x はチャネル名です。また、スレーブプログラムのログファイル名は、通常 x_slave.log の形式をとります。
UNIX では、master_debug と slave_debug が 1 チャネルに対して有効になっている場合は、ユーザが MTA デバッグ情報を含む imta_sendmail.log-uniqueid ファイルを、現在のディレクトリに受信できます (ディレクトリに書き込み権がある場合。書き込み権がない場合はデバッグにより stdout に出力)。
Loopcheck を設定する
キーワード : loopcheck、noloopcheckloopcheck キーワードは、MTA が MTA 自身と通信しているかどうかを確認するために、SMTP EHLO 応答見出しに文字列を入れます。loopcheck が設定されている場合、SMTP サーバでは XLOOP 拡張がアドバタイズされます。
XLOOP をサポートする SMTP サーバと通信する場合、MTA の SMTP クライアントにより、アドバタイズされた文字列と MTA の値が比較され、クライアントが SMTP サーバと通信している場合は、メッセージがただちに返送されます。
その他のキーワード
この節では、その他のキーワードを説明します。この章には、以下の節があります。
「チャネル動作のタイプ」
チャネル動作のタイプ
キーワード : submitsubmitMessaging Server は、RFC 2476 規定のメッセージ送信プロトコルをサポートしています。チャネルを送信専用に設定するには、submit キーワードを使用します。これは通常、特別なポートで実行され、メッセージを送信する目的だけに使用される SMTP サーバなどの TCP/IP チャネルに便利です。RFC 2476 では、このようなメッセージ送信に使用するためにポート 587 を確立します。
user キーワードは、pipe チャネルでどのユーザ名で実行するかを示すのに使用されます。
user の引数は、通常小文字に変換されますが、引数に引用符が付けられている場合は、元の大文字と小文字が維持されます。
メールボックスフィルタファイルの場所を指定する
キーワード : filter、nofilter、channelfilter、nochannelfilter、destinationfilter nodestinationfilter、sourcefilter、nosourcefilter、fileinto、nofileintofilter キーワードは、そのチャネル用のユーザフィルタファイルの場所を指定するために、ネイティブチャネルと ims-ms チャネルに対して使用します。このキーワードは、フィルタファイルの場所を示す URL を引数としてとります。nofilter がデフォルトで、ユーザメールボックスフィルタがそのチャネルに対して有効にならないことを示します。
一般的な MTA チャネルにチャネルレベルのフィルタを指定するには、受信と送信のメッセージに対してそれぞれ sourcefilter と destinationfilter のキーワードを使用します。これらのキーワードは、チャネルフィルタファイルの場所を示す URL を引数としてとります。nosourcefilter と nodestinationfilter がデフォルトで、チャネルのどちらの方向にもチャネルメールボックスフィルタが無効になります。
旧バージョンの channelfilter キーワードと nochannelfilter キーワードは、それぞれ destinationfilter と nodestinationfilter と同義です。
fileinto キーワードは、現在 ims-ms チャネルに対してのみサポートされており、fileinto メールボックスフィルタ演算子が適用された場合、アドレスをどのように変更するかを指定します。ims-ms チャネルの場合、通常の使用方法は以下のとおりです。
上の例では、最初のサブアドレスの代わりに、フォルダ名をサブアドレスとして元のアドレスに挿入するように指定しています。
前へ 目次 索引 DocHome 次へ
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.
最新更新日 2002 年 2 月 27 日