前へ     目次     索引     DocHome     次へ     
iPlanet Messaging Server 5.2 管理者ガイド



第 6 章   MTA サービスと設定について


この章では、一般的な MTA サービスと設定について説明します。より具体的で詳細な説明については、ほかの章を参照してください。この章には、以下の節があります。



MTA 設定ファイル

MTA の主要設定ファイルは imta.cnf です。デフォルトでは、このファイルは instance_root/imta/config/imta.cnf にあります。このファイルには、MTA チャネル定義およびチャネル書き換え規則が含まれています。書き換えられた宛先アドレスに関連付けられたチャネルが、宛先チャネルとなります。

この節では、MTA 設定ファイルについて簡単に説明します。書き換え規則と、MTA 設定ファイルを構成するチャネル定義の詳細については、第 7 章「書き換え規則を設定する」および第 8 章「チャネル定義を設定する」を参照してください。

MTA 設定ファイルを変更することにより、サイトで使用されるチャネルを確立し、書き換え規則を介して各チャネルが処理するアドレスの種類を決定することができます。設定ファイルは、使用可能な転送方法 (チャネル) および転送経路 (書き換え規則) を指定し、アドレスの種類を適切なチャネルに関連付けることにより電子メールシステムの設計を定めるファイルです。

設定ファイルは、ドメイン書き換え規則とチャネル定義の 2 つの部分から構成されます。ファイルの最初にドメイン書き換え規則があり、チャネル定義との間には空白行が 1 行あります。チャネル定義はチャネルテーブルと総称されています。個々のチャネル定義がチャネルブロックを構成します。

次の imta.cnf 設定ファイルの例は、書き換え規則を使って適切なチャネルにメッセージをルーティングする方法を示しています。わかりやすくするために、ドメイン名は使用していません。書き換え規則は設定ファイルの前半部分にあり、そのあとにチャネル定義が続いています。

図 6-1    簡単な MTA 設定ファイル
! test.cnf - An example configuration file. (1)
!
! これは、単に設定ファイルの例です。It serves
! no useful purpose and should not be used in a real system.
!
! Part I: Rewrite rules
a     $U@a-daemon (2)
b     $U@b-daemon
c     $U%c@b-daemon
d     $U%d@a-daemon
              (3)
! Part II: Channel definitions
l             (4)
local-host

a_channel defragment charset7 usascii (5)
a-daemon

b_channel noreverse notices 1 2 3
b-daemon

</usr/iplanet/server5/msg-tango/table/internet.rules (6)

以下に、上記設定ファイルの主な項目 (括弧に入っている太字の番号付き) について説明します。

  1. コメント行を示すには、感嘆符 (!) を使用します。感嘆符は行頭に表示されていなければなりません。その他の場所にある感嘆符は、文字として解釈されます。

  2. 書き換え規則は設定ファイルの前半部分にあります。書き換え規則に空白行を入れることはできません。コメント行 (行頭に感嘆符が付いている) を入れることはできます。

  3. 設定ファイル内で最初に現れる空白行は、書き換え規則の終わりとチャネル定義の始まりを表します。これらの定義は「チャネルホストテーブル」と総称され、MTA が使用できるチャネルと、各チャネルに関連付けられた名前を定義します。

  4. 通常、最初のチャネルブロックはローカルチャネル (l チャネル) です。各チャネル定義ブロックは、空白行で区切られています(defaults チャネルは例外で、このチャネルは l チャネルより先に表示されます)。

  5. 典型的なチャネル定義は、チャネル名 (a_channel)、チャネルの設定を定義するキーワード (defragment charset7 usascii)、およびルーティングシステム (a-daemon) で構成されます。ルーティングシステムはチャネルタグとも呼ばれます。

  6. ほかのファイルの内容を設定ファイルに含めることもできます。行頭に「小なり」(<) の記号があると、その行の残りはファイル名として扱われます。ファイル名は絶対名でフルパスでなければなりません。指定されたファイルが開かれ、設定ファイルのその場所にほかのファイルの内容が入れられます。ファイルの包含は、3 階層までネストすることができます。設定ファイルに含めるファイルは、設定ファイルと同じように、だれでも読み取り可能でなければなりません。

表 6-1 に、上記の設定でアドレスをルーティングする方法の例を示します。

表 6-1    アドレスと関連付けられたチャネル

アドレス

チャネルキュー

u@a  

a_channel  

u@b  

b_channel  

u@c  

b_channel  

u@d  

a_channel  

MTA 設定ファイルの詳細については、「書き換え規則」、「チャネル定義」、および第 7 章「書き換え規則を設定する」を参照してください。



dirsync の設定


Messaging Server のデフォルトのインストールでは、dirsync モードの操作を使用します (付録 B「MTA ダイレクト LDAP 操作」で説明しているダイレクト LDAP モードを使用する方法もあります)。dirsync モードでは、MTA は、メッセージを処理するたびにディレクトリサービスを照会するのではなく、ディレクトリ情報をキャッシュに保存し、データが必要な場合はキャッシュにアクセスします。

ディレクトリサービスに格納されているディレクトリ情報は、dirsync というプログラムによって絶えず更新されています。このため、ディレクトリキャッシュも、ディレクトリサービス内のディレクトリ情報に合わせて定期的に更新 (同期化) する必要があります。同期には 2 種類の方法があります。

  • 完全同期 - 既存のキャッシュは新しいキャッシュに置き換えられ、ディレクトリサービスのユーザおよびグループのエントリを使って完全に再構築される。同期後、MTA 設定ファイルは再構築され、MTA が自動的に再起動する

  • 増分同期 - 既存のキャッシュは、前回の完全同期または増分同期以降に作成されたユーザおよびグループのエントリを使って定期的に更新される。MTA は再起動しない

デフォルトでは、MTA ディレクトリキャッシュでは、毎日午前 2 時に完全同期が実行され、10 分おきに増分同期が実行されます。

表 6-2 に、完全同期または増分同期で行われる更新を示します。

表 6-2    MTA ディレクトリキャッシュの更新

MTA ディレクトリキャッシュの更新

完全同期

増分同期

新規ユーザエントリの追加  

○  

○  

修正したユーザエントリの更新  

○  

○  

*削除したユーザエントリの破棄  

○  

×  

既存の配布リストへの新規メンバーの追加  

○  

○  

既存の配布リストから削除したメンバーの破棄  

○  

○  

新規の配布リストの追加  

○  

○  

*削除した配布リストの破棄  

○  

×  

*削除したエントリに対して増分同期を実行するには、そのエントリのステータスに削除済みのマークが付いている必要があります。増分同期の実行後、MTA はそのユーザまたはグループが存在しないものとみなします。実際にディレクトリエントリを削除する作業は、増分同期のあとに行ってください。

通常、ディレクトリの同期は自動的に行われます。ただし、必要に応じて、imsimta dirsync コマンドを使って MTA ディレクトリキャッシュを再作成または更新することができます。imsimta dirsync コマンドの詳細については、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。


ディレクトリ同期設定パラメータ

表 6-3 に、ディレクトリ同期設定パラメータの一覧を示します。


表 6-3    ディレクトリ同期設定パラメータ 

パラメータ

説明

local.imta.ldsearchtimeout  

ユーザおよびメーリングリストの情報を検索する際の LDAP 検索のタイムアウトを指定する。デフォルトでは、タイムアウトは発生しない  

local.imta.hostnamealiase  

LDAP エントリがローカルであるかどうかを確認するためにそのエントリの mailhost または mailRoutingHosts 属性をチェックする際に、dirsync プロセスは local.hostname パラメータを使って比較を行う。さらに、local.imta.hostnamealiases パラメータにより、ホスト名エイリアスのカンマ区切りのリストが提供される。dirsync プロセスは、これらの 2 つのパラメータによって提供されるすべてのホスト名を使って、エントリがローカルであるかどうかを調べる  

local.imta.mailaliases  

デフォルトでは、mail および mailAlternateAddress という LDAP 属性のみがルーティング可能なメールアドレスとみなされる。または、local.imta.mailaliases パラメータにより、LDAP 属性のカンマ区切りのリストが提供される。このリストはデフォルト属性を上書きする。たとえば、メッセージをルーティングする際に、MTA は次の 4 つの属性を考慮する

local.imta.mailaliases=mail,mailAlternateAddress,
rfc822mailbox,rfc822mailalias  

local.imta.ugfilter  

このパラメータは、ユーザやメーリングリストの情報を検索する際に、dirsync が使用する LDAP 検索フィルタを設定する

デフォルトのフィルタは (objectClass=inetLocalMailRecipient)

たとえば、inetLocalMailRecipient オブジェクトクラスおよび myispSubscriber オブジェクトクラスで LDAP エントリだけを考慮する場合は、このパラメータを次のように設定する

local.imta.ugfilter=(&(objectClass=inetLocalMailRecipient)(objectClass=myispSubscriber))

注 : 増分同期の場合は、このフィルタにタイムスタンプフィルタが追加される。このため、カスタムフィルタを ( ) で囲む必要がある  

local.imta.
statssamplesize  

このパラメータを設定すると、dirsync は、開始時からのユーザとメーリングリストのエントリ数の要約、および平均値 (エントリ数/秒) を標準出力で印刷する。ユーザとメーリングリストは、同期が完了したかどうかにかかわらず計算される  

local.imta.reverseenabled  

リバースデータベースの生成をトリガする。デフォルト値は、yes である。リバースデータベースの実際の使用は、USE_REVERSE_DATABASE オプションで制御される  

local.imta.ssrenabled  

サーバ側規則 (SSR) データベースの生成をトリガする。デフォルト値は、yes である。SSR データベースの実際の使用は、ssr チャネルキーワードで制御される  

local.imta.vanityenabled  

バニティドメイン (msgVanityDomain ユーザ LDAP 属性) が有効であるかどうかを制御する。デフォルトは yes である  

local.imta.
catchallenabled  

キャッチオールアドレス (@domain 形式の mail または mailAlternateAddress) が有効であるかどうかを制御する。デフォルトは yes である  

local.imta.scope  

このパラメータは、dirsync が同期化するエントリを指定する

mailhost 属性がローカルホストであるユーザおよびメーリングリストのエントリだけをキャッシュする場合は、値に local を指定する

mailhost 属性に関係なくユーザおよびメーリングリストのエントリをキャッシュする場合は、値に domains を指定する。これはパラメータがない場合のデフォルト値である

ドメイン、ユーザ、またはメーリングリストをキャッシュしない場合は、値に nobody を指定する  



マッピングファイル


MTA コンポーネントの多くは、テーブル検索に基づいた情報を使用します。このタイプのテーブルは、入力文字列を出力文字列に変える (マップする) のに使用されます。このようなテーブルはマッピングテーブルと呼ばれ、通常 2 つのカラムで構成されます。最初 (左側) のカラムにはパターンを照合する入力文字列が、2 番目 (右側) のカラムにはその入力文字列がマップされた (テンプレート) 結果の出力文字列が並んでいます。

MTA データベースのほとんどは、このタイプのテーブルのインスタンスです。これらのデータベースにはさまざまなタイプの MTA データが含まれています。マッピングテーブルとは混同しないでください。ただし、MTA データベースファイルには、ワイルドカード検索機能がありません。データベース全体でワイルドカードに一致するものを検索するのは非効率的だからです。

MTA マッピングファイルは、複数のマッピングテーブルをサポートします。ワイルドカード機能もあり、複数の手順や反復マッピング方法にも対応しています。このアプローチは、データベースを使用する場合に比べ、さらに多くの処理を必要とします。特に、エントリ数が多い場合などはなおさらです。ただし、それに付随して柔軟性が増すため、同等のデータベースにおけるエントリのほとんどを必要としなくなり、全体的にオーバーヘッドが少なくなります。

表 6-4 に、本書で説明するマッピングテーブルの一覧を示します。


表 6-4    iPlanet Messaging Server のマッピングテーブル 

マッピングテーブル

ページ

説明

CHARSET-CONVERSION  

296  

チャネル間における文字セット変換やメッセージフォーマット変換の種類を指定するために使用される  

COMMENT_STRINGS  

254  

アドレスヘッダーのコメント (括弧で囲まれた文字列) を変更するために使用される  

CONVERSIONS  

280  

変換チャネルのメッセージトラフィックを選択するために使用される  

"domain lookup"  

548  

ダイレクト LDAP モードで、エイリアスを検索するツリーのベースを検索するために使用される  

FORWARD  

149  

エイリアスファイルまたはエイリアスデータベースを使用した場合と同様の転送を行う  

FROM_ACCESS  

306  

エンベロープの From アドレスに基づいてメールをフィルタリングする場合に使用する。このテーブルは、To アドレスが不適切な場合に使用する  

INTERNAL_IP  

318  

内部のシステムとサブネットを認識する  

MAIL_ACCESS  

306  

SEND_ACCESS テーブルと PORT_ACCESS テーブルを組み合わせた情報に基づいて受信接続をブロックする場合に使用する  

NOTIFICATION_LANGUAGE  

150  

通知メッセージをカスタマイズまたはローカライズする  

ORIG_MAIL_ACCESS  

306  

ORIG_SEND_ACCESS テーブルと PORT_ACCESS テーブルを組み合わせた情報に基づいて受信接続をブロックする場合に使用する  

ORIG_SEND_ACCESS  

306  

エンベロープ From アドレス、エンベロープ To アドレス、ソースおよび宛先チャネルに基づいて、受信接続をブロックする  

PERSONAL_NAMES  

255  

個人名 (角括弧で区切られたアドレスの前にある文字列) を変更するために使用される  

PORT_ACCESS  

306  

IP 番号に基づいて受信接続をブロックする  

REVERSE  

145  

内部形式から公のアドバタイズ形式にアドレスを変換する  

SEND_ACCESS  

306  

エンベロープ From アドレス、エンベロープ To アドレス、ソースおよび宛先チャネルに基づいて、受信接続をブロックする  

X-ATT-NAMES  

289  

マッピングテーブルからパラメータ値を検索するために使用される  


マッピングファイルの検索と読み込み

マッピングテーブルは、MTA マッピングファイルに保存されています。これは、MTA テイラーファイルの IMTA_MAPPING_FILE オプションで指定されているファイルで、デフォルトは server_root/msg-instance/imta/config/mappings です。マッピングファイルの内容は、コンパイルされた設定に取り込まれます。

マッピングファイルは、だれでも読み取り可能でなければなりません。だれでも読み取りおよびアクセスが可能でないと、誤作動をまねくことになります。


マッピングファイルのファイル形式

マッピングファイルは、一連のテーブルで構成されています。各テーブルはその名前で始まり、名前の先頭は必ずアルファベット文字です。テーブル名の次には必ず空白行が続き、そのあとにテーブルのエントリが続きます。エントリには、インテンド行がない場合とある場合があります。各エントリ行は、1 つ以上のスペースまたはタブで区切られた 2 つのカラムから成ります。エントリ内のスペースはすべて、$ 文字で囲む必要があります。各テーブル名のあとおよびテーブル間には空白行が必要ですが、1 つのテーブル内のエントリ間に空白行があってはなりません。コメント行を挿入する場合は、その行の 1 列目を感嘆符 (!) にします。

つまり、ファイル形式は以下のようになります。
TABLE1_NAME

   pattern1-1    template1-1
   pattern1-2    template1-2
   pattern1-3    template1-3
      .              .
      .              .
      .              .
   pattern1-n    template1-n

TABLE2_NAME

   pattern2-1    template2-1
   pattern2-2    template2-2
   pattern2-3    template2-3
       .            .
       .            .
       .            .
   pattern2-n    template2-n

          .
          .
          .

TABLE3_NAME

          .
          .
          .

TABLE2_NAME マッピングテーブルを使用するアプリケーションは、pattern2-2 文字列を template2-2 で指定された文字列にマップします。各パターンまたはテンプレートには、252 文字までを含めることができます。マッピングテーブルに含まれるエントリの数に制限はありません (ただし、エントリが必要以上に多い場合は、CPU とメモリを大量に消費することになります)。252 文字を超えるの長い行は、円記号 (¥) を行の末尾に置くことで次の行に続けることができます。2 つのカラム間および最初のカラムの前にある空白スペースは削除しないでください。

マッピングファイルでマッピングテーブル名が重複することは許されていません。


マッピングファイルにほかのファイルを含める

マッピングファイルにはほかのファイルを含めることができます。次の形式の行を使用します。
<file-spec

これによって、マッピングファイル内の file-spec の行が、その実際のファイルに置き換えられます。ファイル指定には、完全なファイルパス (ディレクトリなど) が必要です。この方法で含めるファイルは、だれでも読み取り可能でなければなりません。マッピングファイルに含めるファイルにはコメントを入れることもできます。含めるファイルは 3 段階までネスティングすることができます。含められたファイルは、マッピングファイルと一緒に読み込まれます。オンデマンドで読み込まれるのではないため、ファイルを含めることによってパフォーマンスまたはメモリを節約することはできません。


マッピングの動作

マッピングファイル内のマッピングはすべて一定の方法で適用されます。マッピングごとに異なるのは、入力文字列のソースとマッピング出力の使用目的のみです。

マッピングの動作は、常に入力文字列とマッピングテーブルから始まります。マッピングテーブルのエントリは、テーブルに表示される順に上から下へ 1 つずつスキャンされます。各エントリの左側の部分がパターンとして使用され、入力文字列は大文字/小文字の区別なくそのパターンと比較されます。


マッピングエントリのパターン

パターンには、ワイルドカード文字を含めることができます。たとえば、次のような一般的なワイルドカード文字を使用できます。アスタリスク (*) は 0 個以上の文字と一致し、パーセント記号 (%) は 1 文字と一致します。アスタリスク、パーセント記号、スペース、およびタブの前にドル記号 ($) を置くことによって、これらの記号を引用できます。アスタリスクやパーセント記号を引用した場合は、特別な意味は失われます。パターンやテンプレートを正しく認識させるために、その中のスペースやタブは文字として認識させる必要があります。ドル記号を文字として使用するには、2 重のドル記号 ($$) を使用します。この場合、最初のドル記号によって、2 番目のドル記号が文字として認識されるようになります。

表 6-5    マッピングパターンのワイルドカード 

ワイルドカード  

説明  

%  

1 文字だけ一致する  

*  

0 個以上の文字と一致する。左から右への最大限の一致を使用する  

後照合  

説明  

$ n*  

n 番めのワイルドカードまたはグロブに一致する  

修飾子  

説明  

$_  

左から右への最低限の一致を使用する  

$@  

後続のワイルドカードまたはグロブの「保存」をオフにする  

$^  

後続のワイルドカードまたはグロブの「保存」をオンにする (デフォルト設定)  

グロブワイルドカード  

説明  

$A%  

A 〜 Z または a 〜 z の 1 文字と一致する  

$A*  

A 〜 Z または a 〜 z の 0 個以上の文字と一致する  

$B%  

1 つのバイナリ数字 (0 または 1) と一致する  

$B*  

0 個以上のバイナリ数字 (0 または 1) と一致する  

$D%  

1 つの 10 進数 (0 〜 9) と一致する  

$D*  

0 個以上の 10 進数 (0 〜 9) と一致する  

$H%  

1 つの 16 進数 (0 〜 9 または A 〜 F) と一致する  

$H*  

0 個以上の 16 進数 (0 〜 9 または A 〜 F) と一致する  

$O%  

1 つの 8 進数 (0 〜 7) と一致する  

$O*  

0 個以上の 8 進数 (0 〜 7) と一致する  

$S%  

1 つの記号セット文字 (例 : 0 〜 9、A 〜 Z、a 〜 z、_、$) と一致する  

$S*  

0 個以上の記号セット文字 (例 : 0 〜 9、A 〜 Z、a 〜 z、_、$) と一致する  

$T%  

1 つのタブ、垂直タブ、またはスペース文字と一致する  

$T*  

0 個以上のタブ、垂直タブ、またはスペース文字と一致する  

$X%  

$H% と同義  

$X*  

$H* と同義  

$[ c]%  

文字 c と一致する  

$[ c]*  

任意の数の文字 c と一致する  

$[ c1 c2 ... cn ]%  

文字 c1、c2、cn のいずれか 1 つと一致する  

$[ c1 c2 ... cn ]*  

文字 c1、c2、cn のいずれかと任意の数一致する  

$[ c1 -cn ]%  

c1 から cn の範囲内の任意の 1 文字と一致する  

$[ c1 -cn ]*  

c1 から cn の範囲内の任意の文字列と一致する  

$< IPv4>  

ビットは無視し、IPv4 アドレスと一致する  

$(IPv4)  

プレフィックスビットを維持した状態で、IPv4 アドレスと一致する  

${IPv6}  

IPv6 アドレスと一致する  

グロブ内、つまり $[...] 内では、円記号 (¥) は引用符となります。実際のハイフン (-) または右角括弧 (]) をグロブ内で表すには、ハイフンまたは右角括弧に円記号を付ける必要があります。

パターン内のその他の文字はすべて、文字として使用されます。特に、一重引用符や二重引用符、および括弧は、マッピングパターンやテンプレートにおいて特殊な意味を持たず、通常の文字とみなされます。このため、不正なアドレスや部分的なアドレスに対応するエントリの書き出しが簡単になります。

複数の修飾子、または修飾子および後照合を指定するには、シンタックスにドル記号を 1 つだけ使用します。たとえば、最初のワイルドカードを、後照合そのものを保存せずに後照合するには、$@$0 ではなく $@0 を使用します。

マッピングパターンのテスト、特にパターン内のワイルドカードの動作のテストを行うには、imsimta test -mapping ユーティリティを使用できます。

アスタリスクのワイルドカードは、パターンを左から右へスキャンすることにより、一致する対象を最大化します。たとえば、文字列 a/b/c をパターン */* と比較する場合、左のアスタリスクが「a/b」に一致し、右のアスタリスクが残りの c に一致します。

$_ 修飾子は、ワイルドカードによる照合を最小にするため、パターンの左から右に向かって、もっとも可能性の少ない一致がその一致とみなされます。たとえば、a/b/c 文字列を $_*/$_* というパターンと比較した場合、左側の $_* は a と、右側の $_* は b/c と一致します。


IP の照合

IPv4 接頭辞の照合では、IP アドレス、またはサブネットを指定し、そのあとにオプションとして、照合比較の際に有効となるスラッシュと接頭辞のビット数を続けます。たとえば、次の例は 123.45.67.0 サブネット内にあるものに一致します。

$(123.45.67.0/24)

IPv4 照合でビットを無視する場合は、IP アドレスまたはサブネットを指定し、そのあとにオプションとして、照合を確認する際に無視するスラッシュとビット数を続けます。たとえば、次の例は 123.45.67.0 サブネット内にあるものに一致します。

$<123.45.67.0/8>

次の例は、123.45.67.4 から 123.45.67.7 の範囲内にあるものに一致します。

$<123.45.67.4/2>

IPv6 照合は、IPv6 アドレスまたはサブネットを照合します。


マッピングエントリのテンプレート

指定したエントリのパターン比較に失敗した場合は、何の動作も行われず、次のエントリのスキャンへ移行します。比較が成功した場合は、エントリの右側の部分がテンプレートとして使用され、出力文字列が生成されます。このテンプレートによって、入力文字列がテンプレートの指示によって構成された出力文字列に置き換えられます。

テンプレート内のほとんどすべての文字が、そのまま出力文字列として生成されますが、ドル記号 ($) は例外です。

ドル記号の後ろにドル記号、スペース、またはタブが続く場合は、出力文字列内にドル記号、スペース、またはタブが生成されます。これらの文字を出力文字列に挿入するには、引用符を付ける必要があります。

ドル記号とそれに続く n 桁目は、置換を要求します。ドル記号とそれに続くアルファベット文字は、「メタ文字」と呼ばれます。メタ文字自体は、テンプレートで作成される出力文字には表示されませんが、いくつかの特殊な置換や処理を生成します。特殊な置換および標準処理のメタ文字の一覧については、表 6-6を参照してください。その他のメタ文字はマッピング特有の用途に制限されています。

テンプレートの照合パターン内に $C、$E、$L または $R のいずれかのメタ文字がある場合、それらはマッピング処理に影響を及ぼし、処理の終了または続行を決定します。つまり、1 つのエントリの出力文字列が別のエントリの入力文字列となるような反復的なマッピングテーブルエントリを設定することができます。テンプレートの照合パターン内に $C、$E、$L、または $R のどのメタ文字も含まれていない場合は、$E (マッピング処理の即時終了) が行われます。

無限ループを避けるために、マッピングテーブル内のパス (文字列が渡されること) の反復回数には制限があります。前回のパスと同じか、それより長いパターンを使用してパスが反復されるたびに、カウンタは 1 増えます。文字列が直前のものより短い場合は、カウンタがゼロにリセットされます。カウンタが 10 に達すると、マッピングの反復要求は受け付けられません。

表 6-6    マッピングテンプレートの置換とメタ文字  

置換シーケンス

置き換える内容

$n  

左から数えて n 番目のワイルドカードフィールド  

$#...#  

シーケンス番号の置換  

$]...[  

LDAP による URL 検索。結果的に置換が行われる  

$|...|  

提供された文字列に指定したマッピングテーブルを適用する  

${...}  

一般的なデータベース置換  

$[...]  

サイト提供ルーチンを呼び出す。結果的に置換が行われる  

メタ文字  

説明  

$C  

次のテーブルエントリからマッピング処理を続行し、このエントリの出力文字列をマッピング処理の新しい入力文字列として使用する  

$E  

マッピング処理をただちに終了し、このエントリの出力文字列をマッピング処理の最終結果とする  

$L  

次のテーブルエントリからマッピング処理を続行し、このエントリの出力文字列を新しい入力文字列として使用する。テーブル内のすべてのエントリを照合したら、もう一度最初のテーブルエントリから照合する。後続の照合エントリにメタ文字 $C、$E、または $R がある場合は、それらのエントリが優先される  

$R  

マッピングテーブルの最初のエントリからマッピング処理を続行し、このエントリの出力文字列をマッピング処理の新しい入力文字列として使用する  

$?x?  

マッピングエントリが x パーセントの割合で成功する  

$¥  

後続のテキストを小文字にする  

$^  

後続のテキストを大文字にする  

$_  

後続のテキストを元の状態で残す  

$:x  

指定したフラグが設定されている場合にのみ一致する  

$;x  

指定したフラグが解除されている場合にのみ一致する  


ワイルドカードフィールドの置換 ($n)
ドル記号の後ろに数字 n が続いている場合、これは、パターン内の n 番目のワイルドカードに一致するデータに置き換えられます。ワイルドカードには、0 から順に番号が付けられています。たとえば、次のエントリは入力文字列 PSI%A::B に一致し、その結果 b@a.psi.siroe.com という出力文字列を生成します。
PSI$%*::*    $1@$0.psi.siroe.com

また、入力文字列 PSI%1234::USER は、出力として生成される USER@1234.psi.siroe.com と照合されます。入力文字列 PSIABC::DEF は、このエントリ内のパターンに一致しないため置換は行われません。つまり、このエントリから出力文字列は生成されません。


テキストの大文字小文字の制御 ($¥、$^、$_)
メタ文字 $¥ は後続のテキストを小文字に変換し、メタ文字 $^ は後続のテキストを大文字に変換するものです。また、メタ文字 $_ は、後続のテキストを元の大文字/小文字の状態で残します。たとえば、これらのメタ文字は、マッピングを使って大文字/小文字の区別が有効なアドレスを変更する際に役立ちます。


処理制御 ($C、$L、$R、$E)
メタ文字 $C、$L、$R、および $E は、マッピング処理を終了するかどうか、またいつ終了するかなど、マッピング処理に影響を与えます。これらのメタ文字には、以下の効果があります。

  • $C は現在のエントリの出力文字列をマッピング処理の新しい入力文字列として使用し、次のエントリからマッピング処理を続行します。

  • $L は、現在のエントリの出力文字列をマッピング処理の新しい入力文字列として使用し、次のエントリからマッピング処理を続行します。一致するエントリが見つからない場合には、もう一度そのテーブルの最初のテーブルエントリから照合を開始します。後続の照合エントリにメタ文字 $C、$E または $R がある場合には、それらのエントリが優先されます。

  • $R は、現在のエントリの出力文字列をマッピング処理の新しい入力文字列として使用し、テーブルの最初のエントリからマッピング処理を続行します。

  • $E はマッピング処理を終了し、このエントリの出力文字列が最終結果となります。デフォルト設定は$E です。

マッピングテーブルのテンプレートは、左から右にスキャンされます。「成功」または「失敗」するエントリ (たとえば、一般データベースの置換またはランダム値で制御されるエントリ) に $C、$L、または $R のフラグを設定するには、メタ文字 $C、$L、または $R を成功または失敗するエントリ部分の左側に配置します。エントリのそれ以外の部分が失敗しても、フラグは表示されません。


ランダムに成功または失敗するエントリ ($?x?)
マッピングテーブルのエントリに $?x? というメタ文字がある場合は、これによって、x パーセントの割合でエントリが「成功」します。それ以外の場合、エントリは「失敗」し、マッピングエントリの入力文字列が変更されずにそのまま出力文字列となります (マッピングによっては、エントリが失敗したこととエントリが一致しなかったこととは、必ずしも同義ではありません)。x は、成功率を指定するための実数値です。

たとえば、IP アドレスが 123.45.6.78 であるシステムが、自分のサイトに大量の SMTP 電子メールを送信していて、このメールの量を少し減らしたいとします。この場合、PORT_ACCESS マッピングテーブルを次のように使用できます。たとえば、接続の 25 パーセントのみを許可し、残りの 75 パーセントを拒否するとします。次のマッピングテーブル PORT_ACCESS は、$?25? を使用し、$Y のあるエントリを 25 パーセントの割合で成功させます (すなわち、接続を許可します)。残りの 75 パーセントの割合でエントリが失敗すると、そのエントリの最初の $C によって MTA が次のエントリからマッピングを続行するため、接続試行が拒否され、「Try again later (あとでもう一度試してください)」という SMTP エラーメッセージが表示されます。
PORT_ACCESS

  TCP|*|25|123.45.6.78|*         $C$?25?$Y
  TCP|*|25|123.45.6.78|*         $N45s$ 4.40$ Try$ again$ later


シーケンス番号の置換 ($#...#)
$#...# 置換は、MTA シーケンスファイルに保存されている値を増やし、その値をテンプレート内に入れます。たとえば、マッピングテーブルを使ってファイル名を生成するときなど、マッピングテーブルの出力に固有の修飾子があることが望ましい場合に、シーケンス番号付きの固有文字列を生成することができます。

以下のいずれかのシンタックスを使用できます。
$#seq-file-spec|radix|width#
$#seq-file-spec|radix#
$#seq-file-spec#

必須の引数 seq-file-spec は、既存の MTA シーケンスファイルに対する完全なファイル仕様であり、オプションの引数 radix および width は、それぞれ出力するシーケンス値の基数および桁数を指定するものです。デフォルトの基数は 10 ですが、-36 〜 36 の範囲内の基数も使用できます。たとえば、基数 36 では 0 〜 9、A 〜 Z の文字からなる値を使用することができます。デフォルトでは、シーケンス値は自然幅で出力されますが、大きな桁数を指定すると、桁数に合わせるために数値の左側に 0 が追加されます。

桁数を明示的に指定する場合は、基数も明示的に指定する必要があります。

上記にあるように、マッピングで参照される MTA シーケンスファイルはすでに存在するものでなければなりません。MTA シーケンスファイルを作成するには、以下のコマンドを使用します。
touch seq-file-spec

または
cat >seq-file-spec

マッピングテーブルを使ってアクセスされるシーケンス番号ファイルは、だれでも読み取り可能でないと正常に操作できません。また、このようなシーケンス番号ファイルを使用するには、MTA ユーザアカウント (imta_tailor ファイルで nobody として設定) を持つことが必要です。


LDAP クエリ URL の置換 $]...[
$]ldap-url[ の形式の置換は、特別に処理されます。ldap-url は LDAP クエリ URL として解釈され、LDAP クエリの結果が置換されます。ホストとポートが省略された標準の LDAP URL が使用されます。ホストとポートは、代わりに LDAP_HOST オプションと LDAP_PORT オプションで指定されます。LDAP URL は次のように指定する必要があります。

ldap:///dn[?attributes[?scope?filter]]

上記の角括弧 ([ と ]) は、URL のオプションの部分を示します。dn は検索ベースを指定する名前で、この部分は必須です。URL の attributes、scope、および filter の各オプションを指定すると、より細かい情報が返されます。つまり、attributes では、この LDAP クエリに一致する LDAP ディレクトリエントリから返される属性を指定します。scope には、base (デフォルト)、one、または sub のいずれかを指定できます。filter には一致するエントリの特徴を記述します。

特定の LDAP URL 置換シーケンスは、LDAP クエリ URL 内で使用できます。


マッピングテーブルの置換 ($|...|)
$|mapping、argument| 形式の置換は、特殊な方法で処理されます。MTA は、MTA マッピングファイル内の mapping で指定されている補足的なマッピングテーブルを探し、その補足的なマッピングテーブルで argument を入力文字列として使用します。この補足的なマッピングテーブルは既存のものであり、置換が成功した場合にはその出力文字列に $Y フラグを設定しなければなりません。この補足的なマッピングテーブルが存在しなかったり、または $Y フラグを設定しなかった場合には、補足的なマッピングテーブルの置換は失敗し、元のマッピングエントリも失敗とみなされます。元の入力文字列が出力文字列として使用されます。

マッピングテーブルの置換を行うマッピングテーブルエントリで $C、$R、または $L などの処理制御メタ文字を使用する場合は、処理制御メタ文字をマッピングテーブルテンプレート内のマッピングテーブル置換の左側に配置します。そうしないと、マッピングテーブルの置換が「失敗」したときに、処理制御メタ文字が処理されません。


一般データベースの置換 (${...})
${text} 形式の置換は、特殊な方法で処理されます。text 部分は、一般データベースにアクセスするための鍵として使われます。このデータベースは imsimta crdb ユーティリティにより生成されます。text がデータベース内のエントリに一致すると、データベース内の対応するテンプレートがその文字列に置き換えられます。text がデータベース内のエントリに一致しない場合は、入力文字列がそのまま出力文字列として使用されます。

一般データベースは、正しい操作が行われるように、だれでも読み取り可能でなければなりません。

一般データベースの置換を行うマッピングテーブルエントリで、$C、$R、または $L などの処理制御メタ文字を使用する場合は、処理制御メタ文字をマッピングテーブルテンプレート内の一般データベース置換の左側に配置します。そうしないと、一般データベースの置換が「失敗」したときに、処理制御メタ文字が処理されないことになります。


サイト提供ルーチンの置換 ($[...])
$[image,routine,argument] 形式の置換は、特殊な方法で処理されます。image、routine、argument の各部分は、カスタマ提供のルーチンを探し、呼び出すために使用されます。UNIX では、MTA は dlopen および dlsym を使って動的に共有ライブラリ image から指定した routine をロードし、呼び出します。Windows NT のランタイムでは、MTA により routine ルーチンがダイナミックリンクライブラリの image から呼び出されます。そのとき、その routine は、以下の引数を伴った関数として呼び出されます。
status = routine (argument, arglength, result, reslength)

argument および result は、252 バイトの文字列バッファです。argument および result は、文字列へのポインタ (たとえば、C 言語での char* のように) として渡されます。arglength および reslength は、参照によって渡される符号付きの long 型整数です。入力時、argument にはマッピングテーブルテンプレートからの argument 文字列が含まれ、arglength にはその文字列の長さが含まれます。値を返すときには、resultに結果文字列が入り、reslengthにその長さが入ります。この結果文字列が、マッピングテーブルテンプレート内の $[image,routine,argument] に置き換わります。routineは、マッピングテーブルの置換が失敗した場合には 0 を返し、成功した場合には -1 を返します。置換が失敗した場合は、通常、元の入力文字列がそのまま出力文字列として使用されます。

サイト提供ルーチンの置換を行うマッピングテーブルエントリで、$C、$R、または $L などの処理制御メタ文字を使用する場合は、処理制御メタ文字をマッピングテーブルテンプレート内のサイト提供ルーチン置換の左側に配置します。そうしないと、マッピングテーブルの置換が「失敗」したときには、処理制御メタ文字が処理されないことになります。

サイト提供ルーチンの呼び出し機構によって、MTA のマッピング処理はさまざまな方法で拡張することができます。たとえば、マッピングテーブル PORT_ACCESS または ORIG_SEND_ACCESS 内で、ロードモニタサービスへの呼び出しを行い、その結果を使って接続やメッセージを受け入れるかどうかを決定することができます。

image (サイト提供の共有ライブラリイメージ) は、だれでも読み取り可能でなければなりません。



その他の MTA 設定ファイル


imta.cnf ファイルのほかにも、iPlanet Messaging Server にはMTA サービスを設定するのに役立ついくつかの設定ファイルがあります。表 6-7 にファイルの一覧を示します。


表 6-7    MTA 設定ファイル 

ファイル

説明

自動返信オプションファイル  

autoreply プログラムによって使用されるオプション
instance_root/imta/config/autoreply_option  

エイリアスファイル (必須)  

ディレクトリにないエイリアスを実行する
instance_root/imta/config/aliases  

TCP/IP (SMTP) チャネルオプションファイル (または SMTP オプションファイル)  

チャネル固有のオプションを設定する
instance_root/imta/config/channel_option  

変換ファイル  

変換チャネルがメッセージ本体部分の変換を制御するのに使用する
instance_root/imta/config/conversions  

Dirsync オプションファイル (dirsync モードで実行する場合のみ必須)  

dirsync プログラムによって使用されるオプション
instance_root/imta/config/dirsync.opt  

ディスパッチャ設定ファイル (必須)  

ディスパッチャ用の設定ファイル
instance_root/imta/config/dispatcher.cnf  

ジョブコントローラファイル (必須)  

ジョブコントローラ が使用する設定ファイル
/instance_root/imta/config/job_controller.cnf  

MTA 設定ファイル (必須)  

アドレスの書き換え、ルーティング、およびチャネル定義に使用する
/instance_root/imta/config/imta.cnf  

マッピングファイル (必須)  

マッピングテーブルのリポジトリ
/instance_root/imta/config/mappings  

オプションファイル  

グローバル MTA オプションのファイル
/instance_root/imta/config/option.dat  

テイラーファイル (必須)  

場所といくつかの調整パラメータを指定するファイル
/instance_root/imta/config/imta_tailor  


自動返信オプションファイル

自動返信ファイル autoreply_option は、自動返信または Vacation プログラムのオプションを設定します。詳細については、iPlanet Messaging Server リファレンスマニュアルを参照してください。


エイリアスファイル

エイリアスファイル aliases は、ディレクトリに設定されていないエイリアスを設定します。その例として、ルートのアドレスが挙げられます。このファイルで設定したエイリアスがディレクトリにもある場合は、ファイル内の設定が無視されます。エイリアスおよび aliases ファイルの詳細については、「エイリアス」を参照してください。

aliases ファイルに変更を加えた場合は、必ず MTA を再起動してください。


TCP/IP (SMTP) チャネルオプションファイル

TCP/IP チャネルオプションファイルは、TCP/IP チャネルのさまざまな特性を制御します。ファイルには x_option という名前を付けてください。ファイル名の x はチャネル名となります。たとえば、/ServerInstance/config/imta/tcp_local_option のようになります。詳細は、「SMTP チャネルオプションを設定する」を参照してください。すべてのチャネルオプションキーワードおよびシンタックスの詳細については、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。


変換ファイル

変換ファイル conversions は、MTA を介して送受信されるメッセージの変換チャネルにおける変換方法を指定します。変換には、MTA トラフィックの任意のサブセットを選択できます。また、変換処理を行うには、プログラムまたはコマンドの任意のセットを使用できます。MTA は変換ファイルに基づいて、それぞれのメッセージ本文に対する適切な変換を選択します。

このファイルのシンタックスの詳細については、「変換チャネル」を参照してください。


Dirsync オプションファイル

Dirsync オプションファイル dirsync.opt は、コマンドラインで設定できない dirsync プログラムのオプションを設定します。詳細については、「dirsync の設定」とiPlanet Messaging Server リファレンスマニュアルを参照してください。


ディスパッチャ設定ファイル

ディスパッチャ設定ファイル dispatcher.cnf は、ディスパッチャの設定情報を指定します。インスール時に作成されたデフォルトの設定ファイルをそのまま使用することができます。ただし、セキュリティやパフォーマンスなどの理由でデフォルトの設定ファイルを変更する場合には、dispatcher.cnf ファイルを編集します (詳細については、「ディスパッチャ」を参照)。

ディスパッチャ設定ファイルの形式は、ほかの MTA 設定ファイルの形式に似ています。オプションを指定する行は、次の形式で記述されています。

option=value

option はオプション名、value はオプションを設定する文字列または整数です。option に整数値を指定できる場合は、b%v の文字列表記規則を使って基数を指定できます。この場合、b は基数 10 で表される基数であり、v は基数 b で表される実際の値です。これらのオプションの仕様は、次のオプション設定を適用するサービスに対応するセクションにグループ分けされています。各行では、次の形式が使用されます。

[SERVICE=service-name]

service-name はサービスの名前です。最初のオプション仕様、すなわちこのようなセクションタグよりも前に記述されているオプション仕様はすべてのセクションに適用されます。

以下に、ディスパッチャ設定ファイル (dispatcher.cnf) の例を示します。
! The first set of options, listed without a [SERVICE=xxx]
! header, are the default options that will be applied to all
! services.
!
MIN_PROCS=0
MAX_PROCS=5
MIN_CONNS=5
MAX_CONNS=20
MAX_LIFE_TIME=86400
MAX_LIFE_CONNS=100
MAX_SHUTDOWN=2
!
! Define the services available to Dispatcher
!
[SERVICE=SMTP]
PORT=25
IMAGE=server_root/msg-instance/imta/lib/tcp_smtp_server
LOGFILE=server_root/msg-instance/imta/log/tcp_smtp_server.log

このファイルのパラメータの詳細については、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。


マッピングファイル

マッピングファイル mappings は、MTA が入力文字列を出力文字列にマップする方法を定義します。

MTA コンポーネントの多くは、テーブル検索に基づいた情報を使用します。一般に、このタイプのテーブルは、入力文字列を出力文字列に変える (マップする) のに使用されます。このようなテーブルは、マッピングテーブルと呼ばれ、通常 2 つのカラムで構成されます。最初 (左側) のカラムには入力文字列が、2 番目 (右側) のカラムにはその入力文字列に関連付けられた出力文字列が並んでいます。MTA データベースのほとんどは、このタイプのマッピングテーブルです。ただし、MTA データベースファイルには、ワイルドカード検索機能がありません。データベース全体でワイルドカードに一致するものを検索するのは非効率的だからです。

マッピングファイルによって、MTA が複数のマッピングテーブルをサポートできるようになります。さらに、完全なワイルドカード機能もあり、複数の手順や反復マッピング方法にも対応しています。このアプローチは、データベースを使用する場合に比べ、さらに多くの処理を必要とします。特に、エントリ数が多い場合などはなおさらです。ただし、それに付随して柔軟性が増すため、同等のデータベースにおけるエントリのほとんどを必要としなくなり、全体的にオーバーヘッドが少なくなります。

imsimta test -mapping コマンドを使ってマッピングテーブルをテストすることができます。マッピングファイルのシンタックスおよび test -mapping コマンドの詳細については、「マッピングファイル」および『iPlanet Messaging Server リファレンスマニュアル』を参照してください。


オプションファイル

オプションファイル option.dat はグローバル MTA オプションを指定します。これはチャネル固有のオプションとは逆のオプションです。

オプションファイルを使って、MTA 全体に適用されるさまざまなパラメータのデフォルト値を無効にすることができます。特に、オプションファイルは、設定ファイルやエイリアスファイルが読み込まれるさまざまなテーブルのサイズを確立するのに使用されます。また、MTA が許可するメッセージのサイズを制御したり、MTA 設定で許可するチャネル数を指定したり、許可する書き換え規則の数を設定したりできます。

オプションファイルのシンタックスの詳細については、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。


テイラーファイル

テイラーファイル imta_tailor は、さまざまな MTA コンポーネントの場所を設定します。MTA が正常に機能するには、imta_tailor ファイルが常に ServerInstance/imta/config ディレクトリ内になければなりません。

このファイルを編集して特定の設定にその変更を反映させることはできますが、その際には注意が必要です。このファイルを変更した場合は、必ずMTA を再起動してください。MTA が停止しているときに変更を行うのが望ましい方法です。

注

特に必要でないかぎり、このファイルを変更することは避けてください。


このファイルの詳細については、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。


ジョブコントローラファイル

ジョブコントローラは、メッセージを配信するためのチャネルジョブを作成および管理します。これらのチャネルジョブは、ジョブコントローラ内の処理プール内で実行されます。プールは、チャネルジョブが実行される「場所」であると考えることができます。プールは、プール外のジョブとリソースを奪い合うことなく処理できる計算領域です。ジョブコントローラの概念とチャネルキーワードの設定については、「ジョブコントローラ」、「チャネル実行ジョブのプールを処理する」、および 「サービスジョブの制限」 を参照してください。

ジョブコントローラファイル job_controller.cnf では、以下のチャネル処理情報を指定します。

  • さまざまなプールを定義する

  • すべてのチャネルに対し、マスタープログラム名とスレーブプログラム名を指定する (該当する場合)

imta.cnf ファイル では、pool キーワードを使ってプロセスプール (job_controller.cnf で定義) の名前を指定できます。たとえば、次のサンプルファイル job_controller.cnf の要素は、プール MY_POOL を定義します。

[POOL=MY_POOL]
job_limit = 12

次のサンプルファイル imta.cnf の要素は、チャネルブロック内でプール MY_POOL を指定します。

channel_x pool MY_POOL
channel_x-daemon

デフォルトのプール設定に関連付けられたパラメータを変更したり、プールを追加する場合は、job_controller.cnf ファイルを編集し、ジョブコントローラをいったん終了してから再起動してください。

新しい設定を使用して新規のジョブコントローラプロセスが作成され、それ以降の要求を受信するようになります。古いジョブコントローラプロセスは、キューに残っている要求をすべて処理してから終了します。

ジョブコントローラ設定ファイルの最初のプールは、プール名が指定されていないすべての要求に使用されます。MTA 設定ファイル (imta.cnf) で定義されている MTA チャネルは、後ろにプール名が続く pool チャネルキーワードを使って、特定のプールに処理要求を送ることができます。このプール名は、ジョブコントローラ設定のプール名と一致しなければなりません。ジョブコントローラが要求されたプール名を認識できない場合、その要求は無視されます。

最初の設定で、次のプールを定義します。DEFAULT, LOCAL_POOL, IMS_POOL, SMTP_POOL.


使用例

通常、特定のチャネルの処理を別のチャネルの処理と区別する場合は、ジョブコントローラ設定に付加的なプール定義を追加します。また、特性が異なるプールを使用することもできます。たとえば、チャネルが処理できる同時要求の数を制御する必要があるとします。これを行うには、ジョブ範囲を設定した新規プールを作成し、pool チャネルキーワードを使ってチャネルをより適切なプールに割り当てます。

プール定義のほかに、ジョブコントローラ設定ファイルには、各チャネルの要求を処理するのに必要な MTA チャネルとコマンドのテーブルが含まれています。要求には「マスター」と「スレーブ」の 2 種類があります。通常、チャネルの MTA メッセージキューにメッセージがあると、チャネルマスタープログラムが起動します。マスタープログラムは、メッセージをキューから取り出します。

スレーブプログラムは、チャネルをポーリングし、そのチャンネル内の受信メッセージを取り込むために呼び出されます。マスタープログラムはほぼすべての MTA チャネルにありますが、スレーブプログラムは MTA チャネルにはほとんどなく、必要とされません。たとえば、TCP/IP を介して SMTP を処理するチャネルではスレーブプログラムを使用しません。これは、すべての SMTP サーバからの要求に対して、ネットワークサービスである SMTP サーバが受信 SMTP メッセージを受け取るためです。SMTP チャネルのマスタープログラムは、MTA の SMTP クライアントです。

チャネルに関連付けられた宛先システムが一度に複数のメッセージを処理できない場合は、ジョブ範囲が 1 である新しいタイプのプールを作成する必要があります。

[POOL=single_job]
job_limit=1

一方、宛先システムで並行処理が可能な場合は、ジョブ範囲の値を増やすことができます。

コード例 6-1 に、ジョブコントローラ設定ファイルの例を示します。表 6-8 に使用できるオプションを示します。

コード例 6-1    ジョブコントローラ設定ファイルの例 (UNIX)
!MTA Job Controller configuration file
!
!Global defaults
tcp_port=27442         (1)
secret=never mind
return_job=server_root/bin/msg/imta/bin/return.sh
return_time=00:30/24:00
purge_job=server_root/bin/msg/imta/bin/purge
purge_argv=-num=5
slave_command=NULL     (2)
max_life_age=3600      (3)
!
!
!Pool definitions
!
[POOL=DEFAULT]        (4)
job_limit=10          (5)
!
[POOL=LOCAL_POOL]
job_limit=10
!
[POOL=IMS_POOL]
job_limit=1
!
[POOL=SMTP_POOL]
job_limit=1
!
!Channel definitions
!
!
[CHANNEL=l]           (6)
master_command=server_root/bin/msg/imta/bin/l_master
!
[CHANNEL=ims-ms]
master_command=server_root/bin/msg/imta/bin/ims_master
!
[CHANNEL=tcp_*]       (7)
anon_host=0
master_command=server_root/bin/msg/imta/bin/tcp_smtp_client

以下に、上の例の主な項目 (太字の丸括弧付きの数字がある部分) について説明します。

  1. このグルーバルオプションは、ジョブコントローラが要求を待機する TCP ポート番号を定義します。

  2. そのあとの [CHANNEL] セクションのデフォルト SLAVE_COMMAND を設定します。

  3. そのあとの [CHANNEL] セクションのデフォルト MAX_LIFE_AGE を設定します。

  4. この [POOL] セクションは、DEFAULT という名前のプールを定義します。

  5. このプールの JOB_LIMIT を 10 に設定します。

  6. この [CHANNEL] セクションは、l という名前のチャネル (UNIX ローカルチャネル) に適用されます。このセクションに必要な定義は、ジョブコントローラがこのチャネルを実行するために発行する master_command だけです。このチャネル名にはワイルドカードが含まれていないため、チャネル名は完全に一致しなければなりません。

  7. この [CHANNEL] セクションは、tcp_* で始まるすべてのチャネル名に適用されます。このチャネル名にはワイルドカードが含まれているため、tcp_ で始まるすべてのチャネルに一致します。


追加プールの例
ジョブコントローラは、メッセージを配信するためのチャネルジョブを作成および管理します。これらのチャネルジョブは、ジョブコントローラ内の処理プール内で実行されます。プールは、チャネルジョブが実行される「場所」であると考えることができます。プールは、プール外のジョブとリソースを奪い合うことなく処理できる計算領域です。ジョブ範囲は、job_controller にプールごとに設定されます。たとえば、SMTP_POOL の job_limit を 10 と定義すれば、このプールで実行できる tcp_smtp クライアントプロセスは常に 10 個だけです。

tcp_* チャネルを追加する必要があることもあります。たとえば、メール処理が非常に遅いサイト用の tcp チャネルなどです。このようなチャネルは別のプールで実行することをお勧めします。理由は、tcp_* チャネルを 10 個作成し、SMTP_POOL ですべてを実行する場合は、tcp_* チャネルごとに常に 1 つの tcp_smtp だけを実行することが可能であるからです (ただし、メールの宛先がすべて tcp_* チャネルであり、SMTP_POOL が 10 個の job_limit で定義されている場合)。システムに大きな負荷があり、どのキューにも複数の tcp_* チャネル宛の待機メッセージがある場合は、十分ではありません。スロットが競合しないように、新しい tcp_* チャネルに別のプールを定義することも考えられます。

たとえば、次の tcp_* チャネルを設定する場合を考えてみます。
tcp_yahoo smtp mx pool yahoo_pool keyword keyword keyword
tcp-yahoo-daemon

tcp_aol smtp mx keyword keyword keyword pool aol_pool
tcp-aol-daemon

tcp_hotmail smtp mx pool hotmail_pool keyword keyword keyword tcp-hotmail-daemon

...

tcp_sun smtp mx pool sun_pool keyword keyword keyword
tcp-sun-daemon

新規チャネルごとに 10 個の tcp_smtp_client 処理を追加するには、job_controller.cnf ファイルに次のように追加します。
[POOL=yahoo_pool]
job_limit=10

[POOL=aol_pool]
job_limit=10

[POOL=hotmail_pool]
job_limit=10

...

[POOL=sun_pool]
job_limit=10

プールについては、「チャネル実行ジョブのプールを処理する」を参照してください。ジョブコントローラファイルのシンタックスの詳細については、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。


表 6-8    ジョブコントローラ設定ファイルのオプション 

オプション

説明

一般的なオプション  

説明  

INTERFACE_ADDRESS=adapter  

ジョブコントローラがバインドする IP アドレスインタフェースを指定する。値 (アダプタ) には、ANY、ALL、LOCALHOST、または IP アドレスのいずれかを指定できる。デフォルトでは、ジョブコントローラはすべてのアドレスにバインドする (ALL または ANY の指定に相当)。INTERFACE_ADDRESS=LOCALHOST を指定すると、ジョブコントローラは、ローカルマシンからの接続しか受け付けない。これは、ジョブコントローラではマシン間の操作はサポートされていないため、通常の操作には影響はない。ただし、HA エージェントがジョブコントローラの応答をチェックする HA 環境では、不適切な場合がある。Messaging Server の実行しているマシンが HA 環境にあり、「内部ネットワーク」アダプタと「外部ネットワーク」アダプタがある場合で、大きなポート番号への接続をブロックするファイアウォール機能の信頼性が低い場合は、「内部ネットワーク」アダプタの IP アドレスを指定することを推奨  

MAX_MESSAGES=integer  

ジョブコントローラは、メモリ内構造でメッセージに関する情報を保持する。バックログが大きくなった場合は、この構造のサイズを制限する必要がある。バックログのメッセージ数がこのパラメータ値を超えると、その後のメッセージに関する情報はメモリに保存されない。メールメッセージは常にディスクに書き込まれるため、失われることはないが、ジョブコントローラが認識するメッセージ数の半数になるまで配信されない。この時点では、ジョブコントローラが、imsimta cache -sync コマンドと同じように、キューディレクトリをスキャンする

デフォルトは 100000 です。  

SECRET=file_spec  

ジョブコントローラに送信される要求を保護するための共有の秘密情報  

SYNCH_TIME=time_spec  

ジョブコントローラは定期的にディスク上のキューファイルをスキャンしてファイルが不足していないかどうかをチェックする。デフォルトでは 4 時間ごとにスキャンする (ジョブコントローラの起動後 4 時間たってから開始)。time_spec の形式は、HH:MM/hh:mm または /hh:mm である。hh.mm 変数は、イベントの間隔を時間数 (h) と分数 (m) で示す。HH:MM 変数は、1 日の中でイベントが最初に発生する時間である。たとえば 15:45/7:15 と指定すると、15:45 にイベントが開始され、その後 7 時間 15 分ごとにイベントが実行される  

TCP_PORT=integer  

ジョブコントローラが要求パケットを待機する TCP ポートを指定する。このオプションは、デフォルト値がシステム内の別の TCP アプリケーションと競合しない限り変更してはならない。このオプションを変更する必要がある場合は、対応する MTA テイラーファイル (server_root/msg-instance/imta/config/imta_tailor) の IMTA_JBC_SERVICE オプションも同じように変更する必要がある。TCP_PORT オプションはグローバルに適用され、[CHANNEL] セクションまたは [POOL] セクション内にある場合は無視される  

TIME=time_spec  

[PERIODIC_JOB] セクションの定期ジョブを実行する時間と頻度を指定する。デフォルト設定は /4:00 で、ジョブが 4 時間ごとに実行される。time_spec の形式は HH:MM/hh:mm または /hh:mm である。hh.mm はイベントの間隔の時間数 (h) と分数 (m)。HH:MM は、1 日の中でジョブが発生する最初の時間。たとえば 15:45/7:15 と指定すると、15:45 にイベントが開始され、その後 7 時間 15 分ごとにイベントが実行される  

プールオプション  

説明  

JOB_LIMIT=integer  

プールが同時に使用できるプロセスの最大数を指定する。JOB_LIMIT は各プールに個別に適用される。ジョブの最大合計数は、すべてのプールの JOB_LIMIT パラメータの合計数である。この値をセクションの外に設定すると、JOB_LIMIT が指定されていない [POOL] セクションにより、デフォルトとして使用される。[CHANNEL] セクション内では、このオプションは無視される  

チャネルオプション  

説明  

MASTER_COMMAND=file_spec  

チャネルを実行し、そのチャネルからメッセージを取り出すために、ジョブコントローラによって作成された UNIX システムプロセスが実行するコマンドのフルパスを指定する。このオプションをセクションの外に設定すると、MASTER_COMMAND が指定されていない [CHANNEL] セクションによりデフォルトとして使用される。[POOL] セクション内では、このオプションは無視される  

MAX_LIFE_AGE=integer  

チャネルマスタージョブに対する最大のライフタイムを秒数で指定する。このパラメータがチャネルに指定されていない場合は、グローバルなデフォルト値が使用される。デフォルト値が指定されていない場合は、1800 (30 分) が使用される  

MAX_LIFE_CONNS=integer  

マスターチャネルの寿命は、最長使用期間パラメータのほか、メッセージがあるかどうかをジョブコントローラに確認する回数によっても制限される。このパラメータがチャネルに指定されていない場合は、グローバルなデフォルト値が使用される。デフォルト値が指定されていない場合は 300 が使用される  

SLAVE_COMMAND=file_spec  

チャネルを実行し、そのチャネルで受信するすべてのメッセージをポーリングするために、ジョブコントローラによって作成された UNIX システムプロセスが実行するコマンドのフルパスを指定する。ほとんどの場合、MTA チャネルには SLAVE_COMMAND がない。その場合は、予約値である NULL を指定する。このオプションをセクションの外に設定すると、SLAVE_COMMAND が指定されていない [CHANNEL] セクションによりデフォルトとして使用される。[POOL] セクション内では、このオプションは無視される  



エイリアス


MTA には、ローカルシステムに関連付けられたメールボックス名をサポートする機能である「エイリアス」があります。これは、必ずしも実際のユーザに対応するとは限りません。エイリアスは、メーリングリストの作成、メールの転送、およびユーザの別名の設定に役立ちます。
注

この節では、主に dirsync モードでのエイリアス処理について説明します。ダイレクト LDAP モードでのエイリアス解決については、「ダイレクト LDAP 書き換え規則 ($V) でアドレスを解決する」を参照してください。


エイリアスを適用できるのは、l チャネルまたは aliaslocal キーワードの付いたすべてのチャネルに一致するアドレスだけです。MTA のメッセージ送信ロジックが l チャネルまたは aliaslocal キーワードの付いたすべてのチャネルに一致するアドレスを識別するたびに、アドレスに指定されているメールボックス (ユーザ名など) がエイリアスデータベースまたはエイリアスファイル内の各エントリと照合されます。一致するエントリが見つかると、エイリアスアドレスは変換値またはエイリアスで指定された値に置き換えられます。エイリアスは、追加エイリアスまたは実際のアドレスによる任意の組み合わせに変換できます。実際のアドレスが l チャネルまたは aliaslocal キーワードの付いたすべてのチャネルに一致する必要はありません。したがって、エイリアスは、リモートシステムにメールを転送するのに使用することができます。

本当にチャネルに一致するとみなされるアドレスは Envelope To アドレスのみであるため、エイリアスは Envelope To アドレスにしか適用されません。MTA は、アドレスの書き換えが完了したあとにのみエイリアスの変換および拡張を行います。エイリアスによって生成された変換値は、完全に新しいアドレスとして扱われ、最初から処理されます。


エイリアスデータベース

MTA はディレクトリ内の情報を使用し、エイリアスデータベースを作成します。このエイリアスデータベースは、標準のエイリアスファイルが参照されるたびに参照されます。ただし、エイリアスデータベースのエントリが調べられるのは、標準のエイリアスファイルが使用される前です。すなわち、デーベースは、エイリアスファイルが使用される前に実行される、一種のアドレス書き換え機能として動作します。エイリアスデータベースにユーザおよび配布リストのエントリを作成するためのディレクトリ属性については、『iPlanet Messaging Server プロビジョニングガイド』を参照してください。

注

データベースの形式は固有のものです。直接データベースを編集するのではなく、必要な変更はディレクトリ内で行うようにしてください。



エイリアスファイル

aliases ファイルは、ディレクトリで設定されていないエイリアスを設定するのに使用します。例としては、ポストマスターエイリアスがあります。このファイルで設定したエイリアスがディレクトリにもある場合、このファイルの設定は無視されます。変更を有効にするには、MTA を再起動する必要があります。感嘆符 (!) で始まる行は、コメント行として解釈されるため、無視されます。また、空白行も無視されます。

注

Messaging Server には、アドレスリバースデータベースや特殊化されたマッピングテーブルなど、アドレス操作のためのその他の機能もあります。ただし、アドレス操作を実行する可能性がある場合には、常に書き換え規則を使用するようにしてください。それにより、最高のパフォーマンスを得ることができます。第 7 章「書き換え規則を設定する」を参照してください。


このファイルでは、1 行に入力できる文字数が 1024 バイトに制限されています。円記号 (¥) を継続文字として使用すれば、1 つの論理行を複数の行に分割することができます。

ファイル形式は以下のとおりです。
user@domain: <address> (ホストドメイン内のユーザ用)

user@domain: <address> (ホストドメイン内のユーザ用。例 : デフォルトドメイン)

たとえば、以下のようになります。
! A /var/mail/ user
inetmail@siroe.com: inetmail@native-daemon

! A message store user
ms_testuser@siroe.com: mstestuser@ims-ms-daemon


エイリアスファイルにほかのファイルを含める

プライマリ aliases ファイルには、ほかのファイルを含めることができます。次の行は、MTA にfile-spec ファイルを読み込むように指示するためのものです。

<file-spec

ファイル仕様は、完全なパスを指定したものでなければなりません。また、そのファイルには、プライマリ aliases ファイルと同じ保護が設定されている必要があります (たとえば、だれでも読み込み可能であることなど)。

含まれているファイルの内容は、aliases ファイル内の参照ポイントに挿入されます。含まれているファイルへの参照をそのファイルの実際の内容に置き換えることによっても、同様の効果が得られます。含まれているファイルの形式は、プライマリ aliases ファイルとまったく同じになります。さらに、含まれているファイルにほかのファイルを含めることも可能です。ファイルは、3 階層までネストすることができます。



コマンドラインユーティリティ


iPlanet Messaging Server には、MTA のさまざまな保守、テスト、管理などのタスクを行うためのコマンドラインユーティリティが備わっています。たとえば、MTA の設定、エイリアス、マッピング、セキュリティ、システム全体のフィルタファイル、およびオプションファイルをコンパイルするには、imsimta cnbuild コマンドを使用します。また、MTA ディレクトリキャッシュを再作成または更新するには、imsimta dirsync コマンドを使用します。MTA コマンドラインユーティリティの詳細については、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。



SMTP セキュリティとアクセス制御


SMTP セキュリティとアクセス制御については、第 10 章「メールのフィルタリングとアクセス制御」および第 12 章「セキュリティとアクセス制御を設定する」を参照してください。



ログファイル


MTA 専用のログファイルはすべて、MTA ログディレクトリ (ServerInstance/log/imta/) に保存されます。このディレクトリには、MTA を介したメッセージトラフィックのログファイル、および特定のマスタープログラムまたはスレーブプログラムの情報を記述したログファイルがあります。

MTA ログファイルの詳細については、第 13 章「ログ記録とログ解析」を参照してください。



内部形式から公的な形式にアドレスを変換するには


アドレスは、アドレスリバースデータベースと REVERSE マッピングテーブルを使用して内部形式から公的なアドバタイズ形式に変換することができます。たとえば、 uid@mailhost.siroe.com は、siroe.com ドメイン内では有効なアドレスであっても、外部に公開するには適切なアドレスではない場合があります。この場合は、firstname.lastname@siroe.com のような公式アドレスを使用することをお勧めします。


注

Messaging Server には、aliases ファイルや特殊化されたマッピングテーブルなど、アドレス操作のためのその他の機能もあります。ただし、アドレス操作を実行する可能性がある場合には、常に書き換え規則を使用するようにしてください。それにより、最高のパフォーマンスを得ることができます。第 7 章「書き換え規則を設定する」を参照してください。


リバースデータベースでは、各ユーザの公式アドレスはディレクトリ内のユーザエントリの mail 属性で指定されています。プライベートアドレスや内部アドレスは、mailAlternativeAddress 属性で指定されています。配布リストについても同様です。

リバースデータベースには、有効なアドレスと公式アドレスとの間のマッピングが含まれています。リバースデータベースは、imsimta dirsync コマンドを実行するたびに更新および作成されます。ダイレクト MTA LDAP 操作 (付録 B「MTA ダイレクト LDAP 操作」を参照) を有効にした場合、アドレスリバースデータベースは使われません。

通常、リバースデータベースは MTA データベースディレクトリにあります。このデータベースは、server_root/msg-instance/imta/config/imta_tailor ファイルの IMTA_REVERSE_DATABASE オプションで名前が指定されているファイルで構成されます。特に設定を変更しないかぎり、これらのファイルは server_root/msg-instance/imta/db/reversedb.* です。

データベース内でアドレスが見つかった場合は、そのデータベースの対応する右側部分がアドレスとして置き換えられます。アドレスが見つからなかった場合は、マッピングファイルで REVERSE という名前のマッピングテーブルが検索されます。このマッピングテーブルが存在しない場合、またはマッピングテーブル内に一致するエントリがない場合には、置換は行われず、書き換えは通常どおりに終了します。

REVERSE マッピングテーブルがマッピングファイル内にあり、アドレスがマッピングエントリと一致すると、そのエントリが $Y を指定している場合は、結果の文字列によってアドレスが置き換えられます。$N を指定している場合は、マッピングの結果が破棄されます。マッピングエントリが $Y のほかに $D を指定している場合は、結果の文字列を使ってもう一度リバースデータベースがスキャンされます。一致するエントリが見つかった場合は、データベースのテンプレートによってマッピングの結果 (つまりアドレス) が置き換えられます。一般的な REVERSE マッピングテーブルエントリ (すべてのチャネルに適用されるエントリ) の形式は、以下のとおりです。フラグは、新しいアドレスの前または後ろに指定できます。
REVERSE

  OldAddress        $Y[Flags]NewAddress

チャネル固有のエントリ (特定のチャネルから渡されるメッセージ上でのみ発生するマッピング) の形式は、以下のとおりです。チャネル固有のエントリを機能させるには、option.dat で use_reverse_database を 13 に設定する必要があります。
REVERSE

  source-channel|destination-channel|OldAddress  $Y[Flags]NewAddresS

REVERSE マッピングテーブルフラグを表 6-9 に示します。


表 6-9    REVERSE マッピングテーブルのフラグ 

フラグ

説明

$Y  

出力文字列を新規アドレスとして使用する  

$N  

アドレスは変更されない  

$D  

出力文字列を使ってリバースデータベースをスキャンする  

$A  

パターンをリバースデータベースエントリとして追加する  

$F  

パターンを転送データベースエントリとして追加する  

フラグの比較  

説明  

$:B  

ヘッダー (本文) のアドレスのみを照合する  

$:E  

エンベロープアドレスのみを照合する  

$:F  

前方を探すアドレスのみを照合する  

$:R  

後方を探すアドレスのみを照合する  

$:I  

メッセージ ID のみを照合する  


アドレスリバース制御を設定するには

reverse チャネルキーワードと noreverse チャネルキーワード、および MTA の USE_REVERSE_DATABASE オプションと REVERSE_ENVELOPE オプションを使用して、アドレスリバースを適用する時期や方法などの指定を制御できます。デフォルトでは、アドレスリバース操作は、後方を探すアドレスだけではなく、すべてのアドレスに適用されます。

アドレスリバースは、REVERSE_ENVELOPE システムオプションの値を設定することによって (デフォルト : 1-on、0-off)、有効または無効にすることができます。

宛先チャネル上の noreverse は、アドレスリバースがメッセージ内のアドレスに適用されないことを指定します。reverse は、アドレスリバースが適用されることを指定します。詳細は、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。

USE_REVERSE_DATABASE は、MTA が置換アドレスとしてアドレスリバースデータベースと REVERSE マッピングを使用するかどうかを制御します。値 0 は、アドレスリバースがどのチャネルでも使われないことを示します。値 5 (デフォルト) は、アドレスリバースが、MTA アドレス書き換えプロセスによる書き換え後に、後方を探すアドレスだけではなく、すべてのアドレスに適用されることを指定します。値 13 は、アドレスリバースが、MTA アドレス書き換えプロセスによる書き換え後に、後方を探すアドレスだけではなく、reverse チャネルキーワードを含むアドレスに適用されることを指定します。また、USE_REVERSE_DATABASE オプションのビット値を設定して、アドレスリバース操作の単位を指定することもできます。詳細は、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。

REVERSE_ENVELOPE オプションは、メッセージヘッダーアドレスとともにエンベロープ From アドレスにもアドレスリバースを適用するかどうか制御します。

これらの効果の詳細については、iPlanet Messaging Server リファレンスマニュアル の各オプションおよびキーワードの説明を参照してください。


一般的なリバースマッピングの例

一般的なリバースマッピングの例を以下に示します。この例では、siroe.com の内部アドレスの形式が user@mailhost.siroe.com であると仮定しています。ただし、ユーザのネームスペースでは、user@host1.siroe.com と user@host2.siroe.com が siroe.com のすべてのホストで同じユーザを指定しています。以下の REVERSE マッピングは、アドレスリバースデータベースとともに使用できます。
REVERSE

  *@*.siroe.com        $0@siroe.com$Y$D

この例では、name@anyhost.siroe.com という形式のアドレスが name@siroe.com に変更されています。$D メタ文字では、アドレスリバースデータベースが参照されるようになります。アドレスリバースデータベースには、以下の形式のエントリが含まれています。
user@mailhost.siroe.com    first.last@siroe.com


チャネル固有のリバースマッピングの例

デフォルトでは、ルーティングの範囲がメールサーバドメインに設定されている場合に、アドレスリバースデータベースが使用されます。チャネル固有の REVERSE マッピングテーブルエントリの例を以下に示します。
REVERSE

  tcp_*|tcp_local|binky@macho.siroe.com    $D$YRebecca.Woods@siroe.com

このエントリは、MTA に対して、ソースチャネル tcp_* から宛先チャネル tcp_local に送信されるすべてのメールのアドレスの形式を、binky@macho.siroe.com から Rebecca.Woods@siroe.com に変更するように指示します。

注

チャネル固有のリバースマッピングを有効にするは、option.dat の USE_REVERSE_DATABASE オプションを 13 に設定する必要があります (デフォルト =5)。



FORWARD アドレスマッピング

アドレスリバースは、エンベロープ To アドレスには適用されません。これらのアドレスは、メッセージがメールシステム内で処理される際に常に書き換えられ、変更されます。ルーティングの目的は、エンベロープ To アドレスをシステム固有またはメールボックス固有のフォーマットに変換していくことです。アドレスリバースの公認機能は、エンベロープ To アドレスに対して適当ではありません。

エンベロープ To アドレスのさまざまな代替機構によって、リバースデータベースと同等の機能が提供されますが、リバースマッピングと同じ機能はありません。エンベロープ To アドレスのマッピング機能が有用で、望ましい場合もあります。

この不足している機能は、FORWARD マッピングテーブルによって補われます。マッピングファイル内に FORWARD マッピングテーブルがある場合、それは各エンベロープ To アドレスに適用されます。このマッピングテーブルがない場合や一致するエントリがマッピングテーブルにない場合、変更は行われません。

アドレスに一致するマッピングエントリがある場合は、マッピングの結果がテストされます。エントリが $Y を指定している場合は、結果の文字列によってエンベロープ To: アドレスが置き換えられ、エントリが $N を指定している場合は、マッピングの結果が破棄されます。


転送データベースを使用してメールを転送する

転送データベースを使用して、エイリアスファイルやエイリアスデータベースを使用した場合と同様の転送を行うことができます。ただし、エイリアスファイルやエイリアスデータベースを使用できる場合は、転送データベースよりも効率がよいため、それらの使用をお勧めします。

一般に、転送するメッセージのソースによって異なる種類の転送が必要な場合は、転送データベースによるメール転送が適しています。転送データベースによる転送は、USE_FORWARD_DATABASE オプションを使用して、ソース固有の設定を行うことができます。詳細については、iPlanet Messaging Server リファレンスマニュアルを参照してください。



配信ステータス通知メッセージを制御する


配信ステータス通知、すなわち通知メッセージは、MTA が差出人に送信する電子メールステータスメッセージで、ポストマスターに送信することもできます。Messaging Server では、通知メッセージの内容や言語をカスタマイズすることができます。また、配信ステータス (たとえば、FAILED、BOUNCED、TIMEDOUT など) の種類ごとに異なるメッセージを作成することもできます。さらに、特定のチャネルから送信されたメッセージに関して通知メッセージを作成することもできます。

デフォルトでは、通知メッセージは、server_root/msg-instance/imta/config/locale/C/LC_MESSAGES/ ディレクトリのファイルに保存されています (/server_root/msg-instance/imta/config/imta_tailor ファイルの IMTA_LANG 設定で指定)。次のような種類があります。

return_bounced.txt, return_delivered.txt, return_header.opt, return_timedout.txt, return_deferred.txt, return_failed.txt, return_prefix.txt, return_delayed.txt, return_forwarded.txt, return_suffix.txt.

これらのファイルには直接変更を加えないでください。これらのファイルは、iPlanet Messaging Server の更新時に上書きされます。ファイルを変更して独自の通知メッセージテンプレートファイル (return_*.txt) として使用する場合は、新しいディレクトリにファイルをコピーし、そちらを編集してください。次に imta_tailor ファイルに IMTA_LANG オプションを設定し、このテンプレートがある新しいディレクトリを指定します。通知ファイルのセットを複数作成する場合は (言語別のセットを作成する場合など)、NOTIFICATION_LANGUAGE マッピングテーブルを設定する必要があります。


通知メッセージを作成および変更するには

通知メッセージは、return_prefix.txt、return_ActionStatus.txt、return_suffix.txt の 3 ファイルのセットで構成されています。

通知をカスタマイズまたはローカライズするには、ロケールやカスタマイズごとに return_*.txt ファイルのセットを作成し、別のディレクトリに保存します。たとえば、あるディレクトリにはフランス語の通知ファイルを保存し、別のディレクトリにはスペイン語の通知ファイルを保存し、さらに別のディレクトリには特別な不特定多数宛てメールのチャネル用の通知ファイルを保存することができます。

注

このリリースには、フランス語、ドイツ語、およびスペイン語のサンプルファイルが含まれています。 これらのファイルは、必要に応じて変更できます。


通知メッセージの形式と構造は次のとおりです。

  1. return_prefix.txt には、該当するヘッダーテキストと本文の導入部分が含まれます。米国英語のロケールのデフォルトは以下のとおりです。

    Content-type: text/plain; charset=us-asci
    Content-language: EN-US

    This report relates to a message you sent with the following
    header fields: %H

    US-ASCII 以外の通知メッセージの場合は、charset パラメータと Content-Language ヘッダーを適切な値に変更する必要があります (たとえばフランス語用のファイルでは ISO-8859-1 と fr になります)。%H は、表 6-10 で定義されているヘッダー置換シーケンスです。

  2. return_<ActionStatus>.txt にはステータス専用のテキストが含まれています。ActionStatus は、メッセージの MTA ステータスの種類です。たとえば、デフォルトでは return_failed.txt のテキストは次のようになります。

    Your message cannot be delivered to the following recipients:
    %R

    return_bounced.txt のデフォルトのテキストは次のようになります。

    Your message is being returned. It was forced to return by
    the postmaster.

    The recipient list for this message was:
    %R

  3. return_suffix.txt には結びのテキストが含まれます。デフォルトでは、このファイルは空白です。


表 6-10    通知メッセージの置換シーケンス

置換

定義

%H  

メッセージのヘッダーに展開する  

%C  

メッセージがキューに入っていた時間の単位1に展開する  

%L  

返送されるまでメッセージがキューに置かれていた時間の単位1に展開する  

%F  

メッセージがキュー内に留まることができる時間の単位1に展開する  

%S [%s]  

以前展開した数値が 1 以外の場合は、S または s に展開する。たとえば、"%C 日%s" は、メッセージがキューに入っていた日数によって「1 日」または「2 日」などに展開できる  

%U [%u]  

使用する時間の単位1 (時間または日) に展開する。たとえば、「%C %U%s」は、メッセージがキューに入っていた時間と MTA オプションの値 RETURN_UNITS によって「2 日」や「1 時間」などに展開できる。RETURN_UNITS=1 (時間) を設定し、サイトでローカライズした英語以外の通知メッセージを使用している場合は、return_delayed.txt と return_timedout.txt を編集し、「日」に相当する単語を時間を表す単語と置き換える必要がある。たとえば、フランス語では、jour(s) を heure(s) と置き換える。ドイツ語では、Tag(e) を Stunde(n) と置き換える。スペイン語では、d誕(s) を hora(s) と置き換える  

%R  

メッセージの受取人のリストに展開する  

%%  

% (テキストの置換シーケンスは、文字セットに関係なくバイト単位でスキャンされる。2 バイトの文字セットを使用する場合は、意図しない % 記号を確認する必要がある)  
1 単位は時間または日 (デフォルト) で、MTA オプションファイルの RETURN_UNITS オプションで定義される


通知メッセージをカスタマイズおよびローカライズするには

通知メッセージをローカライズして、言語別に異なるユーザにメッセージを返すことができます。たとえば、フランス語を使用しているユーザにフランス語の通知を返すことができます。

通知メッセージのローカライズまたはカスタマイズは、次の 2 つの手順で行います。

  1. ローカライズまたはカスタマイズされた return_*.txt メッセージファイルのセットを作成し、別々のディレクトリに保存します。手順については、「通知メッセージを作成および変更するには」を参照してください。

  2. NOTIFICATION_LANGUAGE マッピングテーブルを設定します。

NOTIFICATION_LANGUAGE マッピングテーブル (server_root/msg-instance/imta/config/mappings) は、送信元メッセージ (通知を送信するメッセージ) の属性 (言語、国、ドメイン、アドレスなど) に基づいて、ローカライズまたはカスタマイズされた通知メッセージファイルのセットを指定します。

元の差出人のメッセージが解析され、ステータス通知の種類、ソースチャネル、優先言語、返信アドレス、および最初の受取人が決定されます。テーブルの構築方法によって異なりますが、通知ファイルのセットは 1 つ以上の属性によって選択されます。

NOTIFICATION_LANGUAGE マッピングテーブルの形式は次のとおりです。

NOTIFICATION_LANGUAGE

 dsn-type-list|source-channel|preferred-language|return-address|first-recipient ¥
$Idirectory-spec

dsn-type-list は、配信ステータス通知の種類のカンマ区切りリストです。数の種類を指定する場合はカンマで区切ります。スペースでは区切りません。スペースを使用すると、マッピングテーブルエントリのパターンが終了します。次のような種類があります。

failed - 一般的な、永続的失敗を示すメッセージ (「そのようなユーザはありません」など)。 return_failed.txt ファイルが使用される

bounced - ポストマスターが手動で「バウンス」した場合に使用される通知メッセージ。 return_bounced.txt ファイルが使用される

timedout - MTA が、指定された配信期間内にメッセージを配信できなかったことを示す。メッセージは送り返される。return_timedout.txt ファイルが使用される

delayed - MTA が、メッセージを配信できなかったが、引き続き配信を試みていることを示す。return_delayed.txt ファイルが使用される

deferred - 「delayed」に類似した配信不能通知。ただし、MTA が配信を試みる期間は表示されない。return_deferred.txt ファイルが使用される

forwarded - このメッセージに対して配信受理が要求されていたが、このメッセージは配信受理がサポートされていないシステムに転送されたことを示す。return_forwarded.txt ファイルが使用される

source-channel は通知メッセージを生成するチャネル、つまり現在メッセージがキューに入っているチャネルです。たとえば、メッセージストアの配信キューの ims-ms、送信用 SMTP キューの tcp_local などがあります。

preferred-language は、処理中のメッセージ (通知を生成中のメッセージ) で使用される言語です。この情報のソースは、第 1 に accept_language フィールドです。このフィールドにない場合は、Preferred-language: ヘッダーフィールドと X-Accept-Language: ヘッダーフィールドが使用されます。標準の言語コード値のリストは、server_root/bin/msg/install/templates/msg-inst/msg/imta/config/languages.txt ファイルを参照してください。

このフィールドには、空の場合を除き、メッセージの発信者が Preferred-language: ヘッダー行または X-Accept-language: ヘッダー行で指定したものが使用されます。このため、意味のない文字が使用されることもあります。

return-address は、送信元メッセージのエンベロープ From: address です。これは、通知メッセージの送信先となるエンベロープアドレスであり、使用言語の手掛かりになることがあります。

first-recipient はエンベロープ To: アドレス (メッセージが複数の受取人に届かない場合の最初の受取人のアドレス) で、元のメッセージの宛先です。たとえば、「dan@siroe.com へのメッセージは配信されませんでした」という通知では、dan@siroe.com が、報告を受ける、エンベロープ To: アドレスです。

directory-spec は、マッピングテーブルのプローブに一致する場合に使用する return_*.txt ファイルを含むディレクトリです。$I の後ろにディレクトリの指定が続きます。

たとえば、フランス語の通知ファイル (return_*.txt) が /lc_messages/table/notify_french/ ディレクトリにあり、スペイン語の通知ファイル (return_*.txt) が /lc_messages/table/notify_spanish/ ディレクトリにあるサイトでは、次のようなテーブルを使用できます。各エントリは 1 つまたは複数のスペースで始まり、エントリ間には空白行はありません。

NOTIFICATION_LANGUAGE

! Preferred-language: header value specified
!
   *|*|fr|*|*     $I/lc_messages/table/notify_french/
   *|*|es|*|*     $IIMTA_TABLE/notify_spanish/
   *|*|en|*|*     $I/imta/lang/
!
! If no Preferred-language value, then select notification based on the
! country code in the domain name.EX:PF=French Polynesia; BO=Bolivia
!
   *|*|*|*.fr|*   $I/imta/table/notify_french/
   *|*|*|*.fx|*   $I/imta/table/notify_french/
   *|*|*|*.pf|*   $I/imta/table/notify_french/
   *|*|*|*.tf|*   $I/imta/table/notify_french/
   *|*|*|*.ar|*   $I/imta/table/notify_spanish/
   *|*|*|*.bo|*   $I/imta/table/notify_spanish/
   *|*|*|*.cl|*   $I/imta/table/notify_spanish/
   *|*|*|*.co|*   $I/imta/table/notify_spanish/
   *|*|*|*.cr|*   $I/imta/table/notify_spanish/
   *|*|*|*.cu|*   $I/imta/table/notify_spanish/
   *|*|*|*.ec|*   $I/imta/table/notify_spanish/
   *|*|*|*.es|*   $I/imta/table/notify_spanish/
   *|*|*|*.gp|*   $I/imta/table/notify_spanish/
   *|*|*|*.gt|*   $I/imta/table/notify_spanish/
   *|*|*|*.gy|*   $I/imta/table/notify_spanish/
   *|*|*|*.mx|*   $I/imta/table/notify_spanish/
   *|*|*|*.ni|*   $I/imta/table/notify_spanish/
   *|*|*|*.pa|*   $I/imta/table/notify_spanish/
   *|*|*|*.ve|*   $I/imta/table/notify_spanish/

注

デフォルトの mappings.locale ファイルはインストールによって組み込まれます。これは、通知言語マッピングを有効にするために mappings ファイルに組み込まれます。通知言語マッピングを無効にするには、インクルード行を以下のようにコメントアウトします。

! <IMTA_TABLE: mappings.locale

(ファイル内のコメントを読み、必要に応じて変更してください。)



通知メッセージの追加機能

通知メッセージの設定に必要な手順は前の節で説明したとおりです。ここでは、追加機能について説明します。


サイズの大きいメッセージの内容が戻るのをブロックするには

通常、メッセージがバウンスまたはブロックされる場合は、差出人とローカルドメインのポストマスターに通知メッセージでメッセージの内容が戻されます。サイズの大きいメッセージが何通もそのまま戻されると、リソースに負担がかかります。一定のサイズを超えるメッセージの内容が戻るのをブロックするには、MTA オプションファイルで CONTENT_RETURN_BLOCK_LIMIT オプションを設定します。


通知メッセージのヘッダーから US-ASCII 以外の文字を削除するには

インターネットメッセージヘッダーの本来の形式では US-ASCII 以外の文字は使用できません。メッセージヘッダーに使用されている US-ASCII 以外の文字は「MIME ヘッダーエンコーディング」でエンコードされたものです。「MIME ヘッダーエンコーディング」については RFC 2047 に記述されています。したがって、電子メールメッセージの「件名」行は、実際には次のように表されています。

Subject: =?big5?Q?=A4j=AB=AC=A8=B1=AD=B1=B0=D3=F5=A5X=AF=B2?=

電子メールクライアントは、ヘッダーを表示する際にエンコーディングを削除する必要があります。

%H テンプレートは通知メッセージの本文にヘッダーをコピーするので、通常はエンコードされたヘッダーが表示されます。ただし、Messaging Server では、件名の文字セット (この場合は big5) が return_prefix.txt の Content-Type ヘッダー文字セットパラメータの文字セットと一致する場合は、エンコーディングが削除されます。一致しない場合は、Messaging Server のエンコーディングはそのまま残ります。


通知メッセージの配信間隔を設定するには

キーワード : notices, nonurgentnotices, normalnotices, urgentnotices

配信不能メッセージは、指定したチャネルキューに一定期間保存したあとで差出人に戻されます。また、Messaging Server が配信を試みている期間に、一連のステータスメッセージや警告メッセージを差出人に戻すこともできます。その期間とメッセージの配信間隔は、notices、nonurgentnotices、normalnotices、urgentnotices のキーワードで指定できます。次に例を示します。

notices 1 2 3

この例では、すべてのメッセージについて、一時的な失敗の通知メッセージが 1 日目と 2 日目に送信されます。メッセージが 3 日たってもまだ配信されない場合は、差出人に返されます。

urgentnotices 2,4,6,8

この例では、優先度の高いメッセージについて、一時的な失敗の通知が 2、4、6 日目に送信されます。メッセージが 8 日たってもまだ配信されない場合は、差出人に返されます。

MTA オプションファイルの RETURN_UNITS オプションでは、時間 (1) または日 (0) で単位を指定することができます。デフォルトは日 (0) です。

notices キーワードが指定されていない場合は、デフォルトでは、ローカルの l チャネル用の notices 設定が使用されます。ローカルチャネル用の設定がない場合は、デフォルトでは、notices 3, 6, 9, 12 が使用されます。


通知メッセージに代替アドレスを含めるには

キーワード : includefinal, suppressfinal, useintermediate

MTA により通知メッセージ (バウンスメッセージ、配信受理メッセージなど) が生成される場合、元の形式の受取人アドレスと、変更された最終的な形式の受取人アドレスの両方が MTA に提示されることがあります。元の形式の方が通知メッセージの受取人 (通知メッセージの場合は元のメッセージの差出人) によって認識される可能性が高いため、MTA は、常に元の形式を通知メッセージに含めます。

includefinal および suppressfinal チャネルキーワードは、MTA が最終的な形式のアドレスを含めるかどうかを制御するためのものです。外部に対して内部のメールボックス名を隠しているサイトでは、最終的な形式のアドレスを含めずに、元の外部用アドレスだけを通知メッセージに含めることをお勧めします。includefinal はデフォルトで、最終的な形式の受取人アドレスを含めます。suppressfinal は、元の形式のアドレスが存在する場合に、通知メッセージに最終形式のアドレスを含めないようにします。

useintermediate キーワードでは、リストのエクスパンド後、ユーザメールボックス名を生成するまでの間に作成された中間形式のアドレスを使用します。この情報を入手できない場合は、最終形式を使用します。


ポストマスターへの通知メッセージを送信、ブロック、指定するには

デフォルトでは、エラーが返された場合や Errors-to: ヘッダー行またはエンベロープ From: アドレスが空白であるために警告をまったく送信できない場合を除いて、失敗と警告の通知メッセージのコピーがポストマスターに送信されます。ポストマスターへの通知メッセージの詳細は、以後の節および 表 6-11 で説明する多数のチャネルキーワードで制御できます。


返送された配信不能メッセージ
キーワード : sendpost, nosendpost, copysendpost, errsendpost

長期間にわたってサービスが支障をきたしている場合や、アドレスが不正確な場合は、チャネルプログラムがメッセージを配信できないことがあります。このような場合、MTA チャネルプログラムは、配信不能の理由を説明する文と一緒にメッセージを差出人に返送します。さらに、配信できないメッセージのコピーをすべてローカルポストマスターに送るように設定することも可能です。これはメッセージ配信障害を監視するのに便利ですが、ポストマスターにとっては大量のメールを処理しなければならないことにもなります (表 6-11 を参照)。


警告メッセージ
キーワード : warnpost, nowarnpost, copywarnpost, errwarnpost

メッセージの返送に加えて、MTA では、配信できないメッセージに関する詳細な情報を記載した警告を送信することができます。通常、この警告メッセージは notices チャネルキーワードが指定するタイムアウトに基づいて送られますが、配信試行に失敗したときに送られることもあります。警告には、問題点の説明と配信試行を継続する時間枠が記載されます。また、多くの場合、該当するメッセージのヘッダーと最初の数行も含まれます。

さらに、警告メッセージのコピーをすべてローカルポストマスターに送るように設定することも可能です。これはメッセージ配信障害を監視するのに便利ですが、ポストマスターにとっては大量のメールを処理しなければならないことにもなります。ポストマスターへの警告メッセージの送信を制御するには、warnpost、copywarnpost、errwarnpost、nowarnpost の各キーワードを使用します (表 6-11 を参照)。


空白のエンベロープ返信アドレス
キーワード : returnenvelope

returnenvelope キーワードは 1 つの整数値をとり、これはビットフラグのセットとして解釈されるビット 0 (値 = 1) は、MTA によって生成された返送通知のエンベロープアドレスを空白にするか、ローカルポストマスターのアドレスを入れるかを指定するものです。このビットを設定した場合は、ローカルポストマスターのアドレスを使用することになり、ビットをクリアすると空白アドレスを使用することになります。

注

RFC 1123 では空白アドレスの使用が義務付けられています。ただし、一部のシステムでは空白エンベロープ From: アドレスを適切に処理できないため、このオプションが必要な場合があります。


ビット 1 (値 = 2) は、MTA がすべての空白のエンベロープアドレスをローカルポストマスターのアドレスに置き換えるかどうかを指定します。これは、RFC 821、RFC 822、あるいは RFC 1123 に準拠しないシステムを扱うために使用されます。

ビット 2 (値 = 4) は構文的に不正な返信アドレスを禁止します。

ビット 3 (値 = 8) は mailfromdnsverify キーワードと同じです。


ポストマスター返送メッセージの内容
キーワード : postheadonly, postheadbody

チャネルプログラムまたは定期的なメッセージ返送ジョブがメッセージをポストマスターと差出人の両方に返送する場合は、ポストマスターへのコピーには、メッセージ全体を含めることも、ヘッダーだけを含めることもできます。ポストマスターへのコピーをヘッダーに限定することで、ユーザメールのプライバシーのレベルを高めることができます。ただし、ポストマスターやシステム管理者は一般に root システム権限を使用してメッセージの内容を読むことができるため、このキーワードを使用してもメッセージのセキュリティを完全に保証することにはなりません (表 6-11 を参照)。


チャネルポストマスターアドレスの設定
キーワード : aliaspostmaster, returnaddress, noreturnaddress, returnpersonal, noreturnpersonal

デフォルトでは、MTA がバウンスメッセージや通知メッセージを作成する際に使用するポストマスターの返信アドレスは、postmaster@local-host です。local-host は、ローカルホストの正式な名前 (ローカルチャネル名) で、ポストマスターの個人名は「MTA e-Mail Interconnect」になります。ポストマスターのアドレスは慎重に選択してください。不正な名前を選択すると、すぐにメッセージのループが発生し、大量のエラーメッセージが発生することがあります。

RETURN_ADDRESS オプションと RETURN_PERSONAL オプションを使用すると、MTA システムでポストマスターのアドレスと個人名をデフォルトに設定できます。また、チャネルごとに制御する必要がある場合は、returnaddress および returnpersonal の各チャネルキーワードを使用できます。returnaddress と returnpersonal は、それぞれポストマスターのアドレスと個人名を指定する引数をとります。noreturnaddress と noreturnpersonal がデフォルトであり、デフォルト値が使用されます。デフォルトは、RETURN_ADDRESS オプションと RETURN_PERSONAL オプションで設定します。これらのオプションが設定されていない場合は、通常のデフォルト値が使用されます。

aliaspostmaster キーワードがチャネルに指定されている場合は、正式なチャネル名におけるユーザ名 postmaster (大文字のみ、小文字のみ、またはその両方) 宛てのすべてのメッセージは、postmaster@local-host にリダイレクトされます。local-host には、正式なローカルホスト名 (ローカルチャネルの名前) が入ります。インターネット標準規格では、メールを受け付ける DNS のすべてのドメインに、メールを受信する有効なポストマスターアカウントを設定する必要があります。このため、各ドメインに個別のポストマスターアカウントを設定するのではなく、ポストマスターの責務を一元化する場合はこのキーワードが便利です。つまり、returnaddress は、MTA がポストマスターからの通知メッセージを生成する際に使用するポストマスターの返信アドレスを制御し、aliaspostmaster は、MTA がポストマスター宛てのメッセージを処理する方法を制御します。


表 6-11    ポストマスターに送信された通知メッセージと差出人キーワード 

キーワード

説明

返送メッセージの内容  

通知のアドレスを指定する  

notices  

通知の送信とメッセージの返送を行うまでの時間を指定する  

nonurgentnotices  

優先度が低いメッセージを配信できない場合に通知を送り、そのメッセージを返送するまでの時間を指定する  

normalnotices  

優先度が標準のメッセージを配信できない場合に通知を送り、そのメッセージを返送するまでの時間を指定する  

urgentnotices  

優先度が高いメッセージを配信できない場合に通知を送り、そのメッセージを返送するまでの時間を指定する  

返送メッセージ  

配信不能な返送メッセージの処理方法  

sendpost  

配信不能メッセージのコピーをすべてポストマスターに送信する  

copysendpost  

配信不能メッセージの差出人アドレスが空白の場合を除き、配信不能通知のコピーをポストマスターに送信する。この場合、ポストマスターは、バウンスメッセージや通知メッセージ以外のすべての配信不能メッセージのコピーを受け取る  

errsendpost  

通知を差出人に返すことができない場合に、配信不能通知のコピーをポストマスターに送信する。nosendpost が指定されている場合は、配信不能メッセージがポストマスターに送信されることはない  

nosendpost  

配信不能メッセージのコピーをポストマスターには一切送信しない  

警告メッセージ  

警告メッセージの処理方法  

warnpost  

警告メッセージのコピーをすべてポストマスターに送信する。デフォルトでは、Warnings-to: ヘッダーやエンベロープ From: アドレスが空白であるために警告をまったく送信できない場合を除いて、警告のコピーがポストマスターに送信される  

copywarnpost  

配信不能メッセージの差出人アドレスが空白になっている場合を除き、警告メッセージのコピーがポストマスターに送信される  

errwarnpost  

通知を差出人に返すことができない場合に、警告メッセージのコピーをポストマスターに送信する  

nowarnpost  

警告メッセージのコピーをポストマスターには一切送信しない  

返送メッセージの内容  

ポストマスターにメッセージの内容をすべて送信するか、ヘッダーだけを送信するかを指定する  

postheadonly  

ポストマスターにヘッダーだけを返送する。ポストマスターへのコピーをヘッダーに限定することで、ユーザメールのプライバシーのレベルを高めることができる。ただし、ポストマスターやシステム管理者は root システム権限を使用してメッセージの内容を読むことができるため、このキーワードを選択してもメッセージのセキュリティを完全に保証することにはならない  

postheadbody  

ヘッダーとメッセージの内容の両方を返送する  

返送メッセージの内容  

通知のアドレスを指定する  

includefinal  

配信通知の中にアドレスの最終的な形式を含める (受取人アドレス)  

returnenvelope  

空白のエンベロープ返信アドレスの使用を制御する。returnenvelope キーワードは 1 つの整数値をとり、これはビットフラグのセットとして解釈される

ビット 0 (値 = 1) は、MTA によって生成された返送通知のエンベロープアドレスを空白にするか、ローカルポストマスターのアドレスを入れるかを指定する。このビットを設定した場合は、ローカルポストマスターのアドレスを使用することになり、ビットをクリアすると空白アドレスを使用することになる

ビット 1 (値 = 2) は、MTA がすべての空白のエンベロープアドレスをローカルポストマスターのアドレスに置き換えるかどうかを指定する。これは、RFC 821、RFC 822、あるいは RFC 1123 に準拠しないシステムを扱うために使用される

ビット 2 (値 = 4) は構文的に不正な返信アドレスを禁止する

ビット 3 (値 = 8) は mailfromdnsverify キーワードと同じである  

suppressfinal  

元の形式のアドレスが存在する場合は、通知メッセージに最終形式のアドレスを含めない  

useintermediate  

リストのエクスパンド後、ユーザメールボックス名の設定前に作成された中間形式のアドレスを使用する。この情報を入手できない場合は、最終形式を使用する  

返送メッセージの内容  

通知のアドレスを指定する  

aliaspostmaster  

正式なチャネル名でのユーザ名ポストマスター宛てのメッセージは postmaster@local-host にリダイレクトされる。local-host には、ローカルホスト名 (ローカルチャネルの名前) が入る  

returnaddress  

ローカルポストマスターの返信アドレスを設定する  

noreturnaddress  

ポストマスターアドレス名に RETURN_ADDRESS オプション値を使用する  

returnpersonal  

ローカルのポストマスターに対する個人名を設定する  

noreturnpersonal  

ポストマスター個人名に RETURN_PERSONAL オプション値を使用する  


前へ     目次     索引     DocHome     次へ     
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.

最新更新日 2002 年 2 月 27 日