第 1 章   SIMS 4.0 および Netscape Messaging Server 4.x の変更、サポート中止および iPlanet Messaging Server への移行


iPlanet Messaging Server は、Netscape Messaging Server と Sun Internet Messaging Server (SIMS) を組み合わせた、まさに「最高品質の」統合です。両製品のもっとも堅牢で、もっともパフォーマンスの高いコンポーネントが結合され、iPlanet Messaging Server が開発されました。このような理由により、ユーザにとって、iPlanet Messaging Server の多くのプロセスおよび手続きが、Netscape Messaging Server および SIMS とは異なっています。

この章では、Netscape Messaging Server、SIMS システム、および iPlanet Messaging Server 間の主な違い、および iPlanet Messaging Server への移行に影響を与えるその他の要素を説明します。この章は、次の節で構成されています。

• 「メッセージングコンポーネントの進化」

• 「ディレクトリサポートの変更」

• 「SIMS 4.0 のサポート中止/変更/移行」

• 「Netscape Messaging Server 4.x のサポート中止/変更/移行」

• 「高可用性クラスタでの SIMS および Netscape Messaging Server の移行」

メッセージングコンポーネントの進化

---

iPlanet Messaging Server は、Netscape Messaging Server および SIMS 製品を拡張したものです。次の iPlanet Messaging Server コンポーネントは、Netscape Messaging Server 4.x のコンポーネントに基づいているため、同じデータ形式および構成情報が使用されます。

• Mail アクセス (IMAP および POP) サーバ

• Web ブラウザメールアクセス (Messenger Express)

• ディレクトリサービス (Netscape Directory Server)

• Netscape Console を使用した GUI 管理

次の iPlanet Messaging Server コンポーネントは、Sun Internet Mail Server 4.0 の同じコンポーネントに基づいています。

• メール転送エージェント (MTA)

• ホストドメインの代行管理用の基本的な管理方法 (iPlanet Delegated Administrator for Messaging のアーキテクチャおよび実装を追加)

• ホストドメインの Directory Architecture

iPlanet Messaging Server には、以前の製品と同等のコンポーネントが含まれていますが、管理手順およびデータは、完全には上位互換性がありません。表 1-1 に、SIMS、Netscape Messaging Server および iPlanet Messaging Server 間の主な違いを示します。

表 1-1    SIMS 5.0 および Netscape Messaging Server 4.x と iPlanet Messaging Server 5.0 との相違

メッセージング コンポーネント	SIMS 4.0 から 5.0 への変更	Netscape Messaging Server 4.x から 5.0 への変更
MTA	SIMS MTA の更新バージョンを使用。管理、構成、およびカスタマイズ プロセスはほとんど同じ。新規オプションについては、管理用マニュアルを参照	Netscape Messaging Server MTA は、新規 MTA に置き換え。管理、構成、およびカスタマイズプロセスは異なる
メッセージストア	異なるメッセージストア。管理コマンドはいくつか保持される	Netscape Messaging Server メッセージストアを使用。ユーティリティが追加
プロビジョニング1	CLI をプロビジョニングする SIMS の使用。新規 Delegated Administrator により GUI 作成が提供される。新規プロビジョニングガイドを参照	新規 CLI の提供。新規 Delegated Administrator により GUI プロビジョニングが提供される。新規プロビジョニングガイドを参照
System Admin CLI	いくつかのコマンドは同じだが、ほとんどのコマンドが異なる	いくつかのコマンドは同じだが、多くのコマンドが異なる。configutil は引き続き使用される
System Admin GUI	古い GUI は Netscape Admin Console で置き換えられる	変更なし。Netscape Admin GUI を使用
LDAP Directory	Sun Internet Directory Server は Netscape Directory Server に置き換えられる	変更なし。Netscape Directory を使用
スキーマ	異なるスキーマが使用されるが、古いスキーマはサポートされる	異なるスキーマが使用されるが、古いスキーマはサポートされる

1 アカウント管理システムにより提供されるデータに基づいて、ユーザおよびグループディレクトリエントリを作成および修正するカスタム作成ツールがある場合、エントリを新規ディレクトリ スキーマに移行する前にこれらのツールを修正する必要があります。詳細については、『iPlanet Messaging Server プロビジョニングガイド』を参照してください。

ディレクトリサポートの変更

---

この節では、iPlanet Messaging Server のディレクトリサポートの変更について説明します。

ディレクトリサーバ

表 1-2 に、iPlanet Messaging Server およびその前のバージョンでサポートされるディレクトリサーバを示します。少なくとも、Sun Directory Server または以前のバージョンの Netscape Directory Server を使用したインストールを、iPlanet Messaging Server に移行する前に Netscape Directory Server 4.12 にアップグレードする必要があります。

表 1-2    ディレクトリサーバ のサポート

Messaging Server	Sun Directory Server 3.1 のサポート	Netscape Directory Server 4.12 のサポート
Netscape Messaging Server 4.x	なし	あり
Sun Internet Mail Server 4.0	あり	あり
iPlanet Messaging Server	なし	あり

ディレクトリ情報ツリー (DIT)

iPlanet Messaging Server のデフォルトの DIT は、Netscape Messaging Server および SIMS のディレクトリ DIT とは異なります。3 つの DIT を以下に示します。

図 1-1    ディレクトリ情報ツリー (DIT) の例

インストールされた、iPlanet Messaging Server ネームスペースは、組識ツリーおよびドメインコンポーネント ツリー (DC ツリー) の 2 種類のディレクトリ ツリーで構成されます。組識ツリー (別の 組識ツリーを追加してシステムをサポートすることもできます) には、ユーザおよびグループエントリが含まれます。DC ツリーは、ローカル DNS ストラクチャをミラー化し、データエントリのインデックスとしてシステムで使用されます (図 1-1 を参照)。DC ツリーは、スマートホスト、ルーティング、ホスト、ドメインディスク制限値などさまざまなドメインのオペレーティングパラメータも指定します。

iPlanet Messaging Server では、SIMS 形式のネームスペースが完全にサポートされています。Netscape Messaging Server への移行は、この時点でいくらか制限されます。これらについては、次の節で説明します。

Netscape Messaging Server 4.x Directory のネームスペース制限

iPlanet Messaging Server で Netscape Messaging Server ディレクトリネームスペースを使用するには、Netscape Messaging Server の Directory Information Tree (DIT) を iPlanet Messaging Server の DC ツリーにマッピングする必要があります。この作業の手順は、現在のシステムで仮想ドメインがサポートされているか、および UID がどのように指定されているかにより異なります。UID 指定は、iPlanet Messaging Server への移行を制限できます。また、UID 指定は、おおまかに 4 つのカテゴリに分けることができます。

• 仮想ドメインなし。書式 <LocalPart> の UID (ドメインが 1 つだけ)。例:

  uid:wallyc
  uid:ofanning

• 仮想ドメインを含む。UID に @ セパレータを使用。@ の右側は完全修飾のドメイン名 (FQDN)。書式 <LocalPart>@<FQDN> の UID。例:

  uid:wallyc@varrius.org
  uid:ofanning@siroe.com

• 仮想ドメインを含む。@ セパレータを使用。@ の右側は、FQDN ではない。例:

  ofanning@siroe
  havlicek@sesta
  barkley@florizel

  この書式の UID を使用するシステムは、この時点では移行できません。

• UID が @ 以外のセパレータを使用する仮想ドメインを含む。例:

  ofanning#siroe
  eddie#sesta
  barkley#florizel.com

  imsdirmig では、この時点では、このスタイルの UID はサポートされていません。しかし、ドメインレベルの管理がサポートされないという制限はありますが、バニティ ドメインを使用して、このタイプの導入を iPlanet Messaging Server に移行することもできます (Delegated Administrator なし)。

  このスタイルの UID をサポートするには、次のようにします。

  • すべてのユーザ / グループをデフォルトドメインに含めます。これは、DC ツリーのデフォルトドメインノードの inetDomainBaseDN 属性を、組織ツリーのルートサフィックスに設定することで行います。dc=siroe、dc=com、o=internet の場合、inetDomainBaseDN を、ルートサフィックス o=siroe.com に設定します。これには、デフォルトドメインのすべての仮想ドメインのユーザ / グループが含まれます。

  • オブジェクトクラス msgVanityDomainUser をすべてのユーザエントリに追加して、属性 msgVanityDomain を、ユーザの仮想ドメインの完全修飾ドメイン名に設定します。ユーザの仮想ドメインは、ユーザのメールアドレスのドメイン部分です。たとえば、uid=eddie#sesta エントリの場合、メールアドレス eddie@sesta.com のドメイン部分は sesta.com なので、msgVanityDomain の値は sesta.com になります(図 1-2を参照)。

  inetDomainBaseDN のルートサフィックスへの設定については、『iPlanet Messaging Server プロビジョニングガイド』を参照してください。Netscape Messaging Server ネームスペースの iPlanet Messaging Server ネームスペースへのマッピングについては、「iPlanet Messaging Server での既存のディレクトリ情報ツリーの使用」を参照してください。

図 1-2    バニティドメインを使用した仮想ドメインのサポート

iPlanet Messaging Serverスキーマ

ホストドメインや iPlanet Delegated Administrator などのさまざまな機能をサポートするため、iPlanet Messaging Server ではいくつかの拡張が導入され、ディレクトリスキーマが変更されました。しかし、これらの変更はオプションであり、iPlanet Messaging Server では Netscape Messaging Server および SIMS スキーマの両方がサポートされています。

ただし、新しい iPlanet Messaging Server 機能をすべて利用するには、ディレクトリ オブジェクトを新規スキーマにアップグレードする必要があります。新規機能を利用するには、データ全体を iPlanet Messaging Server スキーマにアップグレードすることをお勧めします。iPlanet Messaging Server スキーマを必要とする機能は次のとおりです。

• iPlanet Delegated Administrator for Messaging コマンド行ユーティリティ

• iPlanet Delegated Administrator for Messaging GUI ツール

• サーバ側のフィルタリング規則

• Vacation 属性

• ホストドメインのサポート

新規スキーマへの移行は、サービスを中継せず徐々に行うことができます。しかし、一度新規スキーマに移行したグループまたはユーザを、古いメッセージングサーバを実行するホストに戻すことは困難です。移行は、古いサーバに戻す必要がなくなった場合だけ行なってください。スキーマの完全な説明については、『iPlanet Messaging Server Schema Reference Manual』を参照してください。

iPlanet Messaging Server スキーマへのアップグレードは、imsdirmig ユーティリティで行われます。また、このアップグレードは、各移行シナリオで説明されています。imsdirmig は、移行ツールキットで利用できます。

SIMS 4.0 のサポート中止/変更/移行

---

SIMS 4.0 MTA のサポート中止および変更

iPlanet Messaging Server では、SIMS で使用されていた MTA と同じ MTA が使用されますが、これは、より高度なバージョンです。また、新規バージョンでの変更箇所がいくつかありますので、この節で説明します。

Vacation 機能

Vacation (不在) 属性は、iPlanet Messaging Server では異なります。ユーザ LDAP エントリを iPlanet Messaging Server スキーマに変換しない限り、Vacation 機能は有効になりません。

imta startup

imsimta startup および imsimta restart コマンドを使用しても、構成のコンパイルは自動的には行われません。iPlanet Messaging Server では、コンパイル済みの構成を使用するか、しないかを選択できます。パフォーマンス向上のため、コンパイル済みの構成を使用することをお勧めします。また、これは、dirsync が正常に機能するために必要です。しかし、たとえば、システムテストのときなど、コンパイル済みの構成を使用せずに実行する方が、便利なこともあります。構成をコンパイルする場合、imsimta cnbuild コマンドを明示的に発行するか、imsimta cnbuild および imsimta restart を使用した場合と同じ効果がある imsimta refresh コマンドを使用する必要があります。

メーリングリストへのアクセスの許可またはブロック

mgrpAllowedBroadcaster または mgrpDisallowedBroadcaster を iPlanet Messaging Server の静的グループのアドレスに設定することはできません。その代わり、mgrpAllowedBroadcaster および mgrpDisallowedBroadcaster 属性は、特定の許可ポスターのアドレスに設定するか、動的グループ (URL 条件を使用した LDAP 検索) として指定する必要があります。

SMTP リレーの追加

iPlanet Messaging Server は、デフォルトでは、SMTP リレーをブロックするように構成されています。つまり、権限のない外部ソースからの外部アドレスへのメッセージ転送が拒否されます (外部システムとは、サーバ自体が常駐するホスト以外のシステムです)。このデフォルトの構成は、ほかのすべてのシステムが外部システムと見なされるという点で、SMTP リレーのブロックにおいて非常に強固なものです。

外部アドレスに指定された iPlanet Messaging Server システムの SMTP サーバを介してメッセージを送信しようとした IMAP および POP クライアントが、SMTP AUTH (SASL) を使用して認証しない場合、メッセージの送信は拒否されます。そのため、リレーが常に受け入れられる独自の内部システムおよびサブネットが認識されるように、構成を修正することがあります。

どのシステムおよびサブネットが内部として認識されているかは、通常、<InstanceRoot>/imta/config/mappings ファイルにある INTERNAL_IP マッピングテーブルにより制御されます。

たとえば、IP アドレスが 123.45.67.89 の iPlanet Messaging Server システムでは、デフォルトの INTERNAL_IP マッピングテーブルは次のようになります。

INTERNAL_IP    $(123.45.67.89/32)   $Y    127.0.0.1   $Y    *   $N

ここで、最初のエントリは、$(IP-pattern/signicant-prefix-bits) 構文を使用しており、123.45.67.89 のすべての 32 ビットと一致する任意の IP アドレスが、内部で一致し、内部として扱われることを示しています。2 番目のエントリは、ループバック IP アドレス 127.0.0.1 を内部として認識します。最後のエントリは、ほかのすべての IP アドレスが、内部として認識されないことを指定します。すべてのエントリの前には、空白を少なくとも 1 つ入れる必要があるので注意してください。

最後の $N エントリの前に追加の IP アドレスまたはサブネットを指定して、別のエントリを追加することもできます。これらのエントリは、左側の IP アドレスまたはサブネット (サブネットの指定には $(.../...) 構文を使用) および右側の $Y を指定する必要があります。また、既存の $(.../...) エントリを修正して、より一般的なサブネットを使用することもできます。

たとえば、この例と同じサイトに、クラス C ネットワークがある場合、つまり、123.45.67.0 サブネットのすべてが所有されている場合、アドレスのマッチングで使用されるビット数を変更することで、このサイトの初期エントリを修正する必要があります。以下のマッピングテーブルでは、32 ビットから 24 ビットに変更します。これにより、クラス C ネットワークのすべてのクライアントは、この SMTP リレーサーバを介してメールをリレーできます。

INTERNAL_IP    $(123.45.67.89/24)   $Y    127.0.0.1   $Y    *   $N

また、このサイトで、範囲 123.45.67.80-123.45.67.99 の IP アドレスだけが所有されている場合、このサイトでは、以下を使用する必要があります。

INTERNAL_IP ! Match IP addresses in the range 123.45.67.80-123.45.67.95    $(123.45.670,80/28)   $Y ! Match IP addresses in the range 123.45.670.96-123.45.670.99    $(123.45.670.96/30)   $Y    127.0.0.1   $Y    *   $N

<InstanceRoot>/imsimta test -match ユーティリティは、IP アドレスが特定の $(.../...) テスト条件に一致するかどうか検査するときに使用できます。また、通常、<InstanceRoot>/imsimta test -mapping ユーティリティは、INTERNAL_IP マッピングテーブルがさまざまな IP アドレス入力に対して目的の結果を返すか検査するときに使用するとより役立ちます。

INTERNAL_IP マッピングテーブルを修正したら、変更内容が有効になるように、必ず <InstanceRoot>/imsimta restart コマンド (コンパイル構成で実行していない場合) または <InstanceRoot>/imsimta refresh コマンド (コンパイル構成で実行している場合) を発行します。

マッピングファイルや一般的なマッピング テーブルフォーマット、および imsimta コマンドライン ユーティリティの詳細については、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。

SIMS 4.0 メッセージストアのサポート中止/変更

既存の SIMS 4.0 メッセージストアは、新しい iPlanet Messaging Server フォーマットとの互換性がありません。SIMS 4.0 メッセージストアを新しいメッセージストアフォーマットに変換する必要があります。これについては、以降の章で説明します。

SIMS でのメッセージストア構成および管理は、SIMS Admin Console を使用して構成ファイルを修正するか、いくつかのコマンド行ユーティリティを実行することで行われていました。iPlanet Messaging Server では、構成ファイルは使用されませんが、その構成パラメータはディレクトリに保存されます。これらのパラメータは、Administration Console および configutil コマンドを使用して修正されます。また、メッセージストア コマンド行 ユーティリティの多くは、iPlanet Messaging Server で引き続き使用できます。SIMS からの移行における変更箇所を、以下にいくつか示します。詳細については、『iPlanet Messaging Server 管理者ガイド』および『iPlanet Messaging Server リファレンスマニュアル』を参照してください。

• iPlanet Messaging Server には、imexpire および impurge で事前に処理される機能を自動的に実行するメッセージストア デーモンがあります。このデーモンは、メッセージストア ロックおよびトランザクション ログを自動的に管理します。このデーモンは、常に実行している必要があります。

• バックアップおよび復元は、SIMS 4.0 と同じです。

• /var/mail メッセージ アクセスはありません。

• imsrestore の対話型モードはありません。

• imcheck は、reconstruct に変わりました。

• IMAP IDLE コマンドはありません。

• imdeluser は、mboxutil -d に変わりました。

• imexpire、iminitquota、および impurge は不要になりサポートされていません。

• imquotacheck は、quotacheck になりました。

• POP beofre SMTP はありません (この機能は、ディレクトリを使用して、UID の解釈方法を制御するときに利用できます)。

• AUTH API はありません。

Netscape Messaging Server 4.x のサポート中止/変更/移行

---

Netscape Messaging Server 4.x MTA のサポート中止/変更

iPlanet Messaging Server では、Netscape Messaging Server と完全に異なる MTA が使用されるので、変更箇所がたくさんあります。これらの変更のいくつかを以下に示します。詳細については、『iPlanet Messaging Server 管理者ガイド』および『iPlanet Messaging Server リファレンスマニュアル』を参照してください。

プラグイン

一般的なプラグイン機能の多くは、iPlanet Messaging Server MTA においても同じですが、iPlanet Messaging Server では、メッセージプラグインはサポートされていません。しかし、一部の Netscape Messaging Server オプションおよびカスタマイズについては、iPlanet Messaging Server で直接替わりになるものがありません。これらの機能やカスタムプラグインについては特にマニュアルに記載されていません。iPlanet Messaging Server チャネルプログラムは、Netscape Messaging Server プラグイン API とは互換性がないので、iPlanet Messaging Server のカスタム チャネルプログラムとして Netscape Messaging Server プラグインを再コーディングする必要があります。このような新規プログラムは、移行を始める前に、開発およびテストする必要があります。

メーリングリストの無効な ErrorsTo アドレスに関してポストマスターへ通知する

Netscape Messaging Server では、メールリストに無効なメンバーおよび無効な ErrorsTo アドレスが含まれている場合、グループにメッセージを送信すると、無効なグループメンバーについてのエラーメッセージおよび無効な ErrorsTo アドレスについてのエラーメッセージの 2 種類のエラーメッセージがポストマスターに送信されます。iPlanet Messaging Server では、デフォルトでは、ポストマスターは無効なグループメンバーについてのメッセージだけを受け取ります。また、デフォルトでは、ポストマスターは無効な ErrorsTo アドレスのインスタンス通知についてなど、通知メッセージの返送に関する通知を受け取りません。

その代わり、ポストマスターが通知メッセージの返送のコピー (たとえば、ErrorsTo アドレスの通知の返送などのような、返送の返送) も受け取るようにしたいサイトでは、sendpost キーワードを使用できます。

グループ属性の移行について

次のグループ属性および値は、サポートされていません。

グループ属性 mgrpMsgRejectAction はサポートされていない
グループ属性 mgrpMsgRejectAction および mgrpMsgRejectText は、この時点ではサポートされていません。これらの属性では、グループへのメッセージが拒否された場合に実行するアクションを指定できました。これらの属性は使用できますが、将来のバージョンまでサポートされません。

グループ属性 mgrpAllowedBroadcaster では、グループも有効な値として扱わない
グループ名を、mgrpAllowedBroadcaster の値として指定することはできません。対策としては、各グループ メンバーの電子メールを追加します。この問題は、次のリリース (5.1) で修正される予定です。

グループ属性値「mgrpBroadcasterPolicy=PASSWD_REQUIRED」はサポートされない
グループ属性 mgrpBroadcasterPolicy は、PASSWD_REQUIRED に指定しても意味を持ちません。これは、今後のリリースで実装されます。

グループ属性 mgrpErrorsTo は、グループが LDAP 値として指定されている場合、機能しない
値は、mailto アドレスとして指定できます。例:

mgrpErrorsTo:mailto:baseball@siroe.com

LDAP 値は指定できません。例:

mgrpErrorsTo:ldap:///cn=baseball,ou=Groups,o=siroe.com,o=siroe.com

この問題は修正されません。

SMTP リレー機能

Netscape Messaging Server では、「アンチリレー」機能 (外部ドメインから送信されたメールは別の外部ドメインにリレーされない) は、プラグインにより提供されていました。iPlanet Messaging Server では、この機能は、MTA により提供されます。iPlanet Messaging Server の初期デフォルト構成は、SMTP リレーをブロックするように構成されています。つまり、権限のない外部ソースから外部アドレスへのメッセージ転送が拒否されます (外部システムとは、サーバ自体が常駐するホスト以外のシステムです)。このデフォルトの構成は、ほかのすべてのシステムが外部システムと見なされるという点で、SMTP リレーのブロックにおいて非常に強固です。

外部アドレスに指定された iPlanet Messaging Server システムの SMTP サーバを介してメッセージを送信しようとした IMAP および POP クライアントが、SMTP AUTH (SASL) を使用して認証しない場合、メッセージの送信は拒否されます。そのため、リレーが常に受け入れられる独自の内部システムおよびサブネットを認識するように、構成を修正することがあります。

どのシステムおよびサブネットが内部として認識するかは、通常、<server-instance>/imta/config/mappings ファイルにある INTERNAL_IP マッピング テーブルにより制御されます。

たとえば、IP アドレスが 123.45.67.89 の iPlanet Messaging Server システムでは、デフォルトの INTERNAL_IP マッピング テーブルは次のようになります。

INTERNAL_IP    $(123.45.67.89/32)   $Y    127.0.0.1   $Y    *   $N

ここで、最初のエントリは、$(IP-pattern/signicant-prefix-bits) 構文を使用し、123.45.67.89 のすべての 32 ビットと一致する任意の IP アドレスが、内部で一致し、内部として扱われることを示しています。2 番目のエントリは、ループバック IP アドレス 127.0.0.1 を内部として認識します。最後のエントリは、すべてのその他の IP アドレスが、内部として認識されないことを指定します。すべてのエントリの前には、空白を少なくとも 1 つ入れる必要があるので注意してください。

最後の $N エントリの前に追加の IP アドレスまたはサブネットを指定して、別のエントリを追加することもできます。これらのエントリは、左側の IP アドレスまたはサブネット (サブネットの指定には $(.../...) 構文を使用) および右側の $Y を指定する必要があります。また、既存の $(.../...) エントリを修正して、さらに一般的なサブネットを使用することもできます。

たとえば、この例と同じサイトに、クラス C ネットワークがある場合、つまり、123.45.67.0 サブネットのすべてが所有されている場合、アドレスのマッチングで使用されるビット数を変更することで、このサイトの初期エントリを修正する必要があります。以下のマッピングテーブルでは、32 ビットから 24 ビットに変更します。これにより、クラス C ネットワークのすべてのクライアントは、この SMTP リレーサーバを介してメールをリレーできます。

INTERNAL_IP    $(123.45.67.89/24)   $Y    127.0.0.1   $Y    *   $N

また、このサイトで、範囲 123.45.67.80-123.45.67.99 の IP アドレスだけが所有されている場合、このサイトでは、以下を使用する必要があります。

INTERNAL_IP ! Match IP addresses in the range 123.45.67.80-123.45.67.95    $(123.45.670.80/28)   $Y ! Match IP addresses in the range 123.45.670.96-123.45.670.99    $(123.45.670.96/30)   $Y    127.0.0.1   $Y    *   $N

<InstanceRoot>/imsimta test -match ユーティリティは、IP アドレスが特定の $(.../...) テスト条件に一致するかどうか検査するときに使用できます。また、通常、<InstanceRoot>/imsimta test -mapping ユーティリティは、INTERNAL_IP マッピング テーブルによりさまざまな IP アドレス入力に対して目的の結果が返されるかどうかを検査するときに使用するとより役立ちます。

INTERNAL_IP マッピング テーブルを修正したら、変更内容が有効になるように、必ず、<InstanceRoot>/imsimta restart コマンド (コンパイル構成で実行していない場合) または <InstanceRoot>/imsimta refresh コマンド (コンパイル構成で実行している場合) を発行します。

マッピング ファイルや一般的なマッピング テーブル フォーマット、および imsimta コマンド行ユーティリティの詳細については、『iPlanet Messaging Server リファレンスマニュアル』を参照してください。

外部サイトでの SMTP リレーの使用
すべての内部 IP アドレスは、上記で説明したように、INTERNAL_IP マッピング テーブルに追加する必要があります。SMTP リレーを使用する使いやすいシステムおよびサイトがある場合、実際の IP アドレスとともにこれらをINTERNAL_IP マッピング テーブルに追加するのがもっとも簡単な方法です。

これらを実際の内部システムまたはサイトとして扱いたくない場合 (たとえば、ログ記録やその他の制御の目的で、実際の内部システムと、リレー特権を持つ使いやすいが内部ではないシステムを区別したい場合)、システムを構成する他の方法があります。

1 つには、このような使いやすいシステムからのメッセージ受信に特別なチャネルを設定する方法があります。この設定を行うには、公式ホスト名 tcp_friendly-daemon で、既存の tcp_internal チャネルと同種の tcp_friendly チャネルを作成し、使いやすいシステムの IP アドレスをリストする INTERNAL_IP マッピングテーブルと同種の FRIENDLY_IP マッピングテーブルを作成します。次に、以下に示す現在の再指定規則のすぐ後に、

! Do mapping lookup for internal IP addresses []
$E$R${INTERNAL_IP,$L}$U%[$L]@tcp_intranet-daemon

以下に示す新しい再指定規則を追加します。

! Do mapping lookup for "friendly", non-internal IP addresses []
$E$R${FRIENDLY_IP,$L}$U%[$L]@tcp_friendly-daemon

別の方法としては、ORIG_SEND_ACCESS マッピング テーブルを、新規のエントリの書式で最後の $N エントリの上に追加します。

  tcp_local|*@siroe.com|tcp_local|*    $Y

ここで、siroe.com は、使いやすいドメインの名前です。また、以下の書式で、ORIG_MAIL_ACCESS マッピングテーブルを追加します。

ORIG_MAIL_ACCESS

   TCP|*|25|$(match-siroe.com-IP-addresses)|*|SMTP|MAIL|    \
tcp_local|*@siroe.com|tcp_local|*     $Y
   TCP|*|*|*|*|SMTP|MAIL|tcp_local|*|tcp_local|*    $N

ここで、$(...) IP アドレス構文は、以前の節で説明した構文と同じです。ORIG_SEND_ACCESS 検査は、アドレスが有効な限り成功するので、先に進み、より厳しい ORIG_MAIL_ACCESS 検査を行います。これが成功するのは、IP アドレスが siroe.com の IP アドレスに対応する場合だけです。

RBL 検査を含む DNS 検索

Netscape Messaging Server ですべてのメールが確実に配送または転送を受け入れられるかどうかは、管理者が、フィルタ ALL: UNKNOWN で MTA 構成パラメータ service.smtp.domainnotallowed を使用した有効な DNS 名を持つアドレスを使用するかどうかに依存します。

iPlanet Messaging Server では、この機能を別の方法で実行できます。そのもっとも簡単な方法は、mailfromdnsverify チャネル キーワードを tcp_local チャネルに置くことです。

また、iPlanet Messaging Server では、dns_verify プログラムが提供されるので、ORIG_MAIL_ACCESS で次の規則を使用して同じ機能を実行することができます。

ORIG_MAIL_ACCESS   TCP|*|*|*|*|SMTP|MAIL|*|*@*|*|*    \      $[<server-root>/bin/msg/imta/lib/dns_verify,     \ dns_verify,$6|$$y|$$NInvalid$ host:$ $$6$ -$ %e]

上記の例の改行は、このようなエントリのマッピングにおいて構文的に重要です。バックスラッシュ文字は、次の行に続ける有効な方法です。

また、dns_verify イメージを使用して、UBE を保護する別の方法として、RBL、MAPS、DUL または ORBS リストのようなものに対する入力接続を検査できます。新しい mailfromdnsverify キーワードについても、dns_verify コールアウトを行うほかに、同様の検査に使用する別の「より簡単な構成」方法があります。より簡単な方法は、dispatcher.cnf ファイルで DNS_VERIFY_DOMAIN オプションを使用することです。たとえば、[SERVICE=SMTP] 節において、オプションのインスタンスを、検査の対象にするさまざまなリストに設定します。

[SERVICE=SMTP]
PORT=25
! ...rest of normal options...
DNS_VERIFY_DOMAIN=rbl.maps.vix.com
DNS_VERIFY_DOMAIN=dul.maps.vix.com
!...etc...

より簡単なこの方法における短所は、内部ユーザからのメッセージを含む、すべての通常の着信 SMTP メッセージが検査されるということです。これは、インターネットの接続性がダウンした場合に、効率が下がり、問題が発生する可能性があります。別の方法としては、PORT_ACCESS マッピングテーブルまたは ORIG_MAIL_ACCESS マッピングテーブルから dns_verify にコールアウトする方法があります。PORT_ACCESS マッピングテーブルには、ローカルな内部 IP アドレスやメッセージ送信者を検査しない初期エントリ、およびすべてのユーザに対して目的の検査をする後期のエントリがあります。または、ORIG_MAIL_ACCESS マッピングテーブルでは、tcp_local チャネルへの着信メッセージの検査を適用する場合だけ、内部システムまたはクライアントからの着信メッセージに対する検査を省略します。dns_verify へのエントリポイントを使用する例を以下に示します。

PORT_ACCESS

! Allow internal connections in unconditionally
  *|*|*|*|* $C$|INTERNAL_IP;$3|$Y$E
! Check other connections against RBL list
  TCP|*|25|*|*    \
      $C$[<server-root>/bin/msg/imta/lib/dns_verify,  \
dns_verify_domain_port,$1,rbl.maps.vix.com]EXTERNAL$E

ORIG_MAIL_ACCESS

  TCP|*|25|*|*|SMTP|*|tcp_local|*@*|*|*    \
      $C$[<server-root>/bin/msg/imta/lib/dns_verif,    \
      dns_verify_domain,$1,rbl.maps.vix.com]$E

許可のない大量電子メール (UBE) フィルタリング

アンチリレーについては、前の節を参照してください。サーバ側のメールボックスフィルタの手順については、『iPlanet Messaging Server 管理者ガイド』を参照してください。メッセージヘッダに基づいた着信メッセージのフィルタリングは、iPlanet Delegated Administrator for Messaging を使用して行うことができます。

Netscape Messaging Server 4.x メッセージストアのサポート中止/変更

iPlanet Messaging Server で使用されるメッセージストアデータ書式は、Netscape Messaging Server 4.x のものに基づいています。既存の Netscape Messaging Server メッセージストアは、新しい iPlanet Messaging Server に自動的に変換されます。ただし、簡単な変換手順が必要です。これについては、次の章で説明します。

高可用性クラスタでの SIMS および Netscape Messaging Server の移行

---

本書で説明するシナリオは、高可用性クラスタでの電子メールシステムのアップグレードで使用できます。クラスタソフトウェア自体のアップグレードおよびクラスタノードの分割方法などの詳細は、本書では扱いません。クラスタベンダーが提供するマニュアルを参照してください。