第 20 章 メッセージストアを管理する

この章では、メッセージストアとその管理インタフェースについて説明します。この章の内容は次のとおりです。

• 「20.1 概要」

• 「20.2 メッセージストアのディレクトリレイアウト」

• 「20.3 メッセージストアによるメッセージの削除方法」

• 「20.4 ストアへの管理者によるアクセスを指定する」

• 「20.5 共有フォルダについて」

• 「20.6 共有フォルダに関するタスク」

• 「20.7 メッセージタイプの管理」

• 「20.8 メッセージストアの制限容量について」

• 「20.9 自動メッセージ削除 (有効期限および消去) 機能を設定する」

• 「20.10 メッセージストアのパーティションを構成する」

• 「20.11 メッセージストアの保守手順を実行する」

• 「20.12 メッセージストアのバックアップと復元を行う」

• 「20.13 ユーザーアクセスを監視する」

• 「20.14 メッセージストアをトラブルシューティングする」

• 「20.15 新しいシステムへのメールボックスの移行または移動」

20.1 概要

メッセージストアには、特定の Messaging Server インスタンス用のユーザーメールボックスが格納されています。メッセージストアのサイズは、メールボックス、フォルダ、およびログファイルの数が増えるに従って増大していきます。ストアのサイズを制御するには、メールボックスのサイズ制限 (ディスク制限容量) を指定するか、許可するメッセージ総数を制限指定するか、ストア内のメッセージに関する存続期間決定ポリシーを設定します。

システムにユーザーを追加していくに従い、ディスクストレージ要件も増えていきます。サーバーがサポートするユーザー数によって、メッセージストアに必要な物理ディスクが 1 つであるか、複数であるかが決まります。この追加ディスク容量をシステムに統合するには、2 種類の方法が存在します。もっとも簡単な方法は、別のメッセージストアパーティションを追加することです (「20.10 メッセージストアのパーティションを構成する」を参照)。

また、複数のホストしているドメインをサポートしている場合は、1 つのサーバーインスタンスを単一の大規模ドメイン専用にした方がよい可能性があります。この構成を行えば、特定のドメインに対するストア管理を指定することができます。また、パーティションをさらに追加することで、メッセージストアを拡張することもできます。

Messaging Server では、メッセージストアの管理のために、表 20–1 で説明するコマンド行ユーティリティーのセットを提供しています。これらのユーティリティーの使用に関する詳細については、「20.11 メッセージストアの保守手順を実行する」および 『Sun Java System Messaging Server 6.3 Administration Reference』を参照してください。

20.2 メッセージストアのディレクトリレイアウト

図 20–1 は、サーバーインスタンスに対するメッセージストアのディレクトリレイアウトを示しています。メッセージストアはメールボックスの内容に高速でアクセスできるように設計されています。ストアディレクトリについては、表 20–2 を参照してください。

図 20–1 メッセージストアのディレクトリレイアウト

メッセージストアは、いくつかのメールボックスデータベースとユーザーメールボックスで構成されています。メールボックスデータベースは、ユーザー、メールボックス、パーティション、制限容量、およびその他のメッセージストア関連のデータで構成されています。ユーザーメールボックスには、ユーザーのメッセージとフォルダがあります。メールボックスは「メッセージストアパーティション」に格納されます。メッセージストアパーティションとは、「ディスク」パーティション上の、メッセージストアを格納するための専用エリアです。詳細については、「20.10 メッセージストアのパーティションを構成する」を参照してください。メッセージストアパーティションはディスクパーティションと同じではありませんが、管理の便宜をはかるために、各メッセージストアパーティション用に 1 つのディスクパーティションを使用することをお勧めします。

INBOX などのメールボックスは、store_root にあります。たとえば、ディレクトリパスの例は次のようになります。

store_root/partition/primary/=user/53/53/=mack1

次の表で、メッセージストアディレクトリについて説明します。

.../userid/nn/
または
.../userid/folder/nn/

20.2.1 有効なフォルダ名と無効なフォルダ名

IMAP フォルダとして有効な文字と無効な文字は、次のとおりです。

IMAP フォルダとして有効な文字: (空白文字) ! " # $ & ' ( ) + , - . / 0-9 : ; < = > @ A-Z [ \ ] ^ _ ` a-z { | } ~

IMAP フォルダとして無効な文字: % * ?

フォルダ名の public/ など、使用できない文字の並びがあります。また、これらの制限は英語ロケールを使用する場合に適用されます。日本語などのほかの言語では、エンコードされた文字セットを使用します。

20.3 メッセージストアによるメッセージの削除方法

メッセージは、次の 3 段階の手順でメッセージストアから削除されます。

1. メッセージフラグを「削除」に設定: クライアントがメッセージフラグを「削除」に設定します。この時点では、メッセージには削除のマークが付けられますが、クライアントは削除フラグを外せばメッセージを復元できます。第 2 のクライアントが存在する場合、そのクライアントからは削除されたフラグがただちには認識できない可能性があります。configutil パラメータの local.imap.immediateflagupdate を設定すると、フラグの更新がただちに行われるようになります。

2. メールボックスから削除: メッセージはメールボックスから削除されます。厳密には、メッセージはメッセージストアのインデックスファイルである store.idx から削除されます。メッセージ自体はディスクに残っていますが、メッセージの消去後、クライアントはメッセージを復元できなくなります。

   有効期限切れは、消去の特殊なケースです。メッセージのサイズや存続期間など、管理者が定義した一連の削除条件に適合するメッセージが消去されます。詳細については、「20.9 自動メッセージ削除 (有効期限および消去) 機能を設定する」を参照してください。

3. ディスクから消去: imexpire ユーティリティーにより、消去されたメッセージをすべてディスクから消去します。デフォルトの場合は、毎日午後 11 時に実行されます。この設定は、メッセージの有効スケジュールを制御する local.schedule.expire および消去までの猶予期間 (メッセージが消去されずに保持される期間) を制御する store.cleanupage を使用して変更できます。これは、MTA ログファイルの古いバージョンを消去する imsimta purge コマンドや configutil パラメータ local.schedule.purge とは異なることに注意してください。

20.4 ストアへの管理者によるアクセスを指定する

メッセージストアの管理者は、ユーザーのメールボックスを表示して監視したり、メッセージストアに対するアクセス制御を指定することができます。ストア管理者は、すべてのサービス (POP、IMAP、HTTP、または SMTP) に対するプロキシ認証権限を持っているので、任意のユーザーの権限を使用して任意のサービスを認証することができます。これらの権限により、ストア管理者は特定のユーティリティーを実行してストアを管理することができます。たとえば、MoveUser を使用して、ストア管理者はあるシステムから別のシステムへユーザーアカウントやメールボックスを移動させることができます。

この節では、Messaging Server のメッセージストアに対してストア権限を付与する方法を説明します。

ほかのユーザーもそのストアに対する管理者権限を持っている可能性があります。たとえば、ほかの管理者がこれらの権限を持っている場合があります。

次の項で説明する管理者のタスクを実行することができます。

• 「管理者エントリを追加する」

• 「管理者エントリを変更する」

• 「管理者エントリを削除する」

• 「20.4.1 メールボックスを保護して管理者以外による削除や名前の変更を防止する」

管理者エントリを追加する

1. コマンド行: コマンド行で管理者のエントリを追加する場合は、次のようになります。

   configutil -o store.admins -v "adminlist"

   この adminlist は、スペースで区切られた管理者 ID のリストです。複数の管理者を指定する場合は、引用符でリストを囲んでください。また、管理者は、サービス管理者グループのメンバーである必要があります (LDAP ユーザーエントリ: memberOf: cn=Service Administrators,ou=Groups,o=usergroup)。

管理者エントリを変更する

1. コマンド行: コマンド行でメッセージストアの管理者 UID リストにある既存のエントリを変更する場合は、次のようになります。

   configutil -o store.admins -v "adminlist"

   この adminlist は、スペースで区切られた管理者 ID のリストです。複数の管理者を指定する場合は、引用符でリストを囲んでください。また、管理者は、サービス管理者グループのメンバーである必要があります (LDAP ユーザーエントリ: memberOf: cn=Service Administrators,ou=Groups,o=usergroup)。

管理者エントリを削除する

1. コマンド行: コマンド行でストア管理者を削除する場合は、次のように管理者リストを編集することができます。

   configutil -o store.admins -v "adminlist"

   この adminlist は、スペースで区切られた管理者 ID のリストです。複数の管理者を指定する場合は、引用符でリストを囲んでください。また、管理者は、サービス管理者グループのメンバーである必要があります (LDAP ユーザーエントリ: memberOf: cn=Service Administrators,ou=Groups,o=usergroup)。

20.4.1 メールボックスを保護して管理者以外による削除や名前の変更を防止する

一部のメールボックスを保護して、管理者以外による削除や名前の変更を防止することもできます。次に、この手順を説明します。管理者以外のユーザーが保護されたメールボックスの削除、変更、または名前の変更を試みると、「mailbox is pinned」というエラーメッセージが表示されます。

local.store.pin configutil 変数を設定します。次の形式を使用してください。

configutil -o local.store.pin -v "mailbox1"%"mailbox2"%"mailbox 3"

ここで、mailbox1、mailbox2、および mailbox 3 は保護するメールボックスで (メールボックス名にはスペースも使用可)、% は各メールボックス間の区切り文字です。

20.5 共有フォルダについて

「グループフォルダ」または「共有フォルダ」は、ほかのメールフォルダと同様です。ただし、ほかのユーザーやグループも、与えられている権限に応じて、そのメッセージの読み取り、削除、追加を行うことができます。共有フォルダにメッセージを追加するには、通常のドラッグ＆ドロップを使用する方法、Sieve フィルタを使用する方法、または uid+folder@domain という形式を使用して直接送信する方法があります。次に例を示します。

carol.fanning+crafts_club@siroe.com

共有フォルダは、ある話題についてのリアルタイムの電子メール会話を開始、共有、アーカイブする場合に便利です。たとえば、ソフトウェア開発者のグループは、mosaic_voices という特定のプロジェクトの進行状況について話し合うための共有フォルダを作成できます。メッセージが共有フォルダ mosaic_voices に送信またはドロップされると、その共有フォルダに対して権限を持っているユーザーは誰でもそのメールボックスを開いてメッセージを読むことができます (権限は個々のアドレスでもグループアドレスでも追加できる)。

ユーザーの共有フォルダは、ユーザーの Shared Folders/Users というメールフォルダに保存されます。ユーザーはこのメールフォルダ内に共有フォルダを作成しアクセスします。「20.5 共有フォルダについて」に例を示します。

図 20–2 Ed の共有メールフォルダリストのメールクライアントの例

共有フォルダには 2 種類あります。

• 非公開共有フォルダ - 特定のユーザーが作成し所有する共有フォルダです。共有フォルダの作成をサポートしている Communications Express などのメールクライアントを使用します。詳細については、Communications Express のヘルプ画面を参照してください。

• 公開共有フォルダ - 公開共有フォルダは、メール管理者によって作成されますが、所有者はいません。公開フォルダの電子メールアドレスは次のようになります。

  public+foldername@domain
  

  たとえば、社内の何らかの会についての情報を送信するために public+software_dev@siroe.com などのフォルダを作成します。興味のある従業員に対して、この公開フォルダへのアクセス権を付与します。

通常、共有フォルダは特定のメッセージストア上のユーザーのみが使用できます。ただし、Messaging Server では、複数のメッセージストアからアクセスできる特殊な共有フォルダを作成できます。このようなフォルダは、「分散共有フォルダ」と呼ばれます。詳細については、「20.6.4 分散共有フォルダを設定する」を参照してください。

20.6 共有フォルダに関するタスク

この節では、共有フォルダ管理者のタスクについて説明します。

• 「公開フォルダを作成する」

• 「20.6.2 共有フォルダのアクセス制御の権限を設定または変更する」

• 「20.6.3 共有フォルダの一覧表示を有効化または無効化する」

• 「20.6.4 分散共有フォルダを設定する」

• 「20.6.5 共有フォルダのデータを監視および保守する」

公開フォルダを作成する

公開フォルダの場合は、LDAP データベースおよび readership コマンドへのアクセスが必要であるため、システム管理者が作成する必要があります。

1. すべての公開フォルダのコンテナとして機能する public という LDAP ユーザーエントリを追加します (「20.5 共有フォルダについて」を参照)。

   例:

   dn: cn=public,ou=people,o=sesta.com,o=ISP objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: inetUser objectClass: ipUser objectClass: inetMailUser objectClass: inetLocalMailRecipient objectClass: nsManagedPerson objectClass: userPresenceProfile cn: public mail: public@sesta.com mailDeliveryOption: mailbox mailHost: manatee.siroe.com uid: public inetUserStatus: active mailUserStatus: active mailQuota: -1 mailMsgQuota: 100

2. mboxutil コマンド行ユーティリティーを使用して、public アカウント内にフォルダを作成します。

   たとえば、gardening という公開フォルダを作成します。

   mboxutil -c user/public/gardening

3. 共有フォルダに対するユーザーのアクセス権を指定します。

   ユーザーとそのアクセス権を指定するには、readership コマンドを使用します。たとえば、次のコマンドは、sesta.com の全員に公開フォルダ gardening の検索、読み取り、および送信のアクセス権を付与します。

   readership -s user/public/gardening anyone@sesta.com lrp

   readership の使用方法の詳細については、「20.6.2 共有フォルダのアクセス制御の権限を設定または変更する」を参照してください。

20.6.1 電子メールグループの共有フォルダを追加する

共有フォルダを作成するには、通常、Communications Express を使用して共有フォルダリストにユーザーを追加するか、前述の方法で公開共有フォルダを作成します。ただし、共有フォルダリストに電子メールグループ (メール配布リスト) を追加して、グループの全員が共有フォルダにアクセスできるようにすることもできます。たとえば、tennis@sesta.com というグループに 25 人のメンバーがいる場合に、このグループアドレス宛のすべての電子メールを保存する共有フォルダを作成できます。

共有フォルダに電子メールグループを追加する

共有フォルダに電子メールグループを追加するには、システム管理者の権限が必要です。

1. フォルダを作成します。(これをすでに完了している場合、この手順は省略する。)

   通常、グループのいずれかのメンバーがこの作業を行う必要があります。グループメンバーの代わりに、管理者が次のコマンドを使用して作成することもできます。

   mboxutil -c user/gregk/gardening

   gregk は、共有フォルダの所有者の uid です。gardening は、共有フォルダの名前です。

2. グループ共有フォルダへのアクセス権を与える各メンバーについて、そのユーザーエントリに属性と値のペア aclGroupAddr group_name@domain を追加します。

   上の例を使用すると、共有フォルダへのアクセス権を与える各ユーザーエントリに、次の属性と値のペアを追加します。

   aclGroupAddr: tennis@sesta.com

   グループエントリで memberURL 属性を使用して動的に作成されたグループの場合、そのメンバーにはすでにこの属性が設定されています。この属性の URL 値は次のようになります。

   memberURL: ldap:///o=sesta.com??sub?(&(aclGroupAddr=tennis@sesta.com) (objectclass=inetmailuser))

   (この例のエントリ行は印刷上の理由で折り返されているが、実際のエントリは、1 行で記述する必要があります。)

3. 共有フォルダに対するグループのアクセス権を指定します。

   これには readership コマンドを使用します。上の例を使用すると、次のコマンドは、tennis@sesta.com のメンバーに公開フォルダ gardening の検索、読み取り、および送信のアクセス権を付与します。

   readership -s user/gregk/tennis tennis@sesta.com lrp

   readership の使用方法の詳細については、「20.6.2 共有フォルダのアクセス制御の権限を設定または変更する」を参照してください。

20.6.2 共有フォルダのアクセス制御の権限を設定または変更する

ユーザーは Communications Express インタフェースを使用して、共有フォルダに対するアクセス制御を設定したり変更したりできます。管理者は readership コマンド行ユーティリティーを使用して、共有フォルダに対するアクセス制御を設定したり変更したりできます。このコマンドの形式は、次のとおりです。

readership -s foldername identifier rights_chars

ここで、foldername は権限を設定する公開フォルダの名前、identifier は権限を割り当てるユーザーまたはグループ、rights_chars は割り当てる権限です。各文字の意味については、表 20–3 を参照してください。

anyone は特別な識別子です。anyone のアクセス権は、すべてのユーザーに適用されます。同様に、anyone@domain のアクセス権は、同一ドメイン内のすべてのユーザーに適用されます。

20.6.2.1 例

sesta ドメインの全員に公開フォルダ golftournament の検索、読み取り、電子メールのマーク付けができる (ただし、送信は除く) アクセス権を付与する場合は、次のようにコマンドを発行します。

readership -s User/public/golftournament anyone@sesta lwr

メッセージストアの全員に同じアクセス権を割り当てるには、次のコマンドを発行します。

readership -s User/public/golftournament anyone lwr

検索、読み取り、電子メールのマーク付け、および送信する権限をグループに割り当てる場合は、次のようにコマンドを発行します。

readership -s User/public/golftournament group=golf@sesta.com lwrp

このフォルダの管理者権限と送信権限を jdoe という個人に割り当てる場合は、次のようにコマンドを発行します。

readership -s User/public/golftournament jdoe@sesta.com lwrpa

公開フォルダへの個人またはグループのアクセスを拒否するには、ダッシュを userid の前に付けます。たとえば、jsmith の検索、読み取り、書き込み権限を拒否するには、次のようにコマンドを発行します。

readership -s User/public/golftournament -jsmith@sesta.com lwr

個人またはグループのアクセス権を拒否するには、ACL 権限を示す文字の前にダッシュを付けます。たとえば、jsmith の送信権限を拒否するには、次のようにコマンドを発行します。

readership -s User/public/golftournament jsmith@sesta.com -p

uid+folder@domain アドレスを使用して共有フォルダにメッセージを送信するには、readership コマンドに p (送信) アクセス権を使用する必要があります。詳細については、「20.6.2 共有フォルダのアクセス制御の権限を設定または変更する」を参照してください。

20.6.3 共有フォルダの一覧表示を有効化または無効化する

設定オプション local.store.sharedfolders の設定によって、サーバーは LIST コマンドに対する応答として共有フォルダを返す場合と返さない場合があります。このオプションを off に設定すると、オプションは無効になります。デフォルトでは、この設定は有効 (on) になっています。

SELECT および LSUB コマンドは、このオプションの影響を受けません。LSUB コマンドは、すべての購読されているフォルダを返します。これには共有フォルダが含まれます。ユーザーは SELECT を使用して所有するフォルダや購読しているフォルダを選択できます。

20.6.4 分散共有フォルダを設定する

通常、共有フォルダは特定のメッセージストア上のユーザーのみが使用できます。ただし、Messaging Server では、複数のメッセージストアからアクセスできる「分散共有フォルダ」を作成できます。つまり、分散共有フォルダへのアクセス権は、メッセージストアグループ内の任意のユーザーに付与できます。ただし、Web メールクライアント (Messenger Express などの HTTP アクセスクライアント) では、リモートでの共有フォルダアクセスがサポートされていないことに注意してください。ユーザーは共有フォルダを一覧表示および購読できますが、内容を表示したり変更したりすることはできません。

分散共有フォルダでは、次の条件を満たす必要があります。

• メッセージストア userid は、メッセージストアグループ全体で一意である。

• 配備全体で、ディレクトリデータが同一である。

リモートのメッセージストア (つまり、共有フォルダを保持していないメッセージストア) は、表 20–4 に示されている設定変数を使用してプロキシサーバーとして設定されている必要があります。

20.6.4.1 分散共有フォルダの設定例

図 20–3 に、StoreServer1、StoreServer2、および StoreServer3 という 3 つのメッセージストアサーバーで共有する分散フォルダの例を示します。

図 20–3 分散共有フォルダの例

これらのサーバーは、表 20–4 で示されている変数を設定することによって、ピアプロキシメッセージストアとして互いに接続しています。各サーバーには、golf (Han が所有)、tennis (Kat が所有)、および hurling (Luke が所有) という非公開共有フォルダがあります。さらに、press_releases および Announcements という 2 つの公開共有フォルダもあります。これら 3 つのサーバーのいずれかに存在するユーザーは、これら 3 つの共有フォルダすべてにアクセスできます。図 20–2 に、Ed の共有フォルダリストが示されています。次に、この構成における各サーバーの ACL の例を示します。

$ StoreServer1 :> imcheck -d lright.db
Ed: user/Han/golf 
Ian: user/Han/golf 
anyone: user/public/press_releases

            

$ StoreServer2 :> imcheck -d lright.db
Jan: user/Kat/tennis
Ann: user/Kat/tennis
anyone: user/public+Announcements user/public+press_releases

            

$ StoreServer3 :> imcheck -d lright.db
Tuck: user/Ian/hurling
Ed: user/Ian/hurling 
Jac: user/Ian/hurling 
anyone: user/public/Announcements

            

20.6.5 共有フォルダのデータを監視および保守する

readership コマンド行ユーティリティーを使用すると、folder.db、peruser.db、および lright.db の各ファイルに保存されている共有フォルダデータを監視および保守できます。folder.db には、ACL のコピーが格納された各フォルダの記録があります。peruser.db には、ユーザーおよびメールボックスごとのエントリがあり、このエントリには、各種フラグ設定およびユーザーが任意のフォルダに前回アクセスした日付が示されています。lright.db には、全ユーザーの一覧があり、ユーザーが検索権限を持つ共有フォルダも示されています。

readership コマンド行ユーティリティーでは次のオプションが使用できます。

さまざまなオプションを使用して、次の機能を実行できます。

• 「20.6.5.1 共有フォルダ使用状況を監視する」

• 「20.6.5.2 ユーザーとその共有フォルダを一覧表示する」

• 「20.6.5.3 非アクティブなユーザーを削除する」

• 「20.6.5.4 アクセス権を設定する」

20.6.5.1 共有フォルダ使用状況を監視する

共有フォルダに積極的にアクセスしているユーザーの数を調べるには、次のコマンドを発行します。

readership -d days

days は、チェック対象とする日数です。このオプションではアクティブなユーザーの数が返されるのであって、アクティブなユーザーの一覧が返されるのではないことに注意してください。

例: 過去 30 日以内に共有フォルダを選択したユーザーの数を調べるには、次のようにコマンドを発行します。

readership -d 30

20.6.5.2 ユーザーとその共有フォルダを一覧表示する

ユーザーおよびユーザーがアクセスした共有フォルダを一覧表示するには、次のコマンドを発行します。

imcheck -d lright.db

出力例:

$ imcheck -d lright.db
group=lee-staff@siroe.com: user/user2/lee-staff
richb: user/golf user/user10/Drafts user/user2/lee-staff user/user10/Trash
han1: user/public+hurling@siroe.com user/golf
gregk: user/public+hurling@siroe.com user/heaving user/tennis

20.6.5.3 非アクティブなユーザーを削除する

非アクティブなユーザー (指定の期間内に共有フォルダにアクセスしなかったユーザー) を削除するには、次のコマンドを発行します。

readership -p months

months は、チェックに使用する月数です。

例: 過去 6 か月間に共有フォルダにアクセスしなかったユーザーを削除します。

readership -p 6

20.6.5.4 アクセス権を設定する

新規の公開フォルダにアクセス権を割り当てたり、現在の公開フォルダのアクセス権を変更したりできます。

このコマンドを使用したアクセス権の設定方法の例については、「20.6.2 共有フォルダのアクセス制御の権限を設定または変更する」を参照してください。

20.7 メッセージタイプの管理

この節では、次の内容について説明します。

• 「20.7.1 メッセージタイプの概要」

• 「メッセージタイプを設定する」

• 「20.7.2 IMAP コマンドでのメッセージタイプ」

• 「20.7.3 メッセージタイプに関する通知メッセージの送信」

• 「20.7.4 メッセージタイプごとの制限容量の管理」

• 「20.7.5 メッセージタイプごとのメッセージの有効期限切れ」

20.7.1 メッセージタイプの概要

統合されたメッセージングアプリケーションでは、テキストメッセージ、ボイスメール、FAX メール、イメージデータ、その他のデータ形式など、多くの種類のメッセージの受信、送信、格納、および管理を行うことができます。メッセージストアでは、最大 63 種類のメッセージタイプを定義できます。

メッセージをタイプ別に操作する 1 つの方法は、メッセージをタイプごとのフォルダに振り分けることです。

メッセージタイプの機能を導入しても、異なるメッセージタイプを個別のメールボックスフォルダで管理する必要はありません。メッセージタイプを設定すると、メッセージストアはそのメッセージタイプを格納場所に関係なく識別できます。したがって、同じフォルダ内に異なるタイプのメッセージを格納できます。また、次のような作業も行えます。

• メッセージタイプの使用量を追跡する

• メッセージタイプごとにグループ化した通知を送信する

• 格納場所が同じフォルダか異なるフォルダかに関係なく、メッセージタイプごとに制限容量を設定して管理する

• メッセージタイプごとに一意に設定した条件に従って、フォルダ間でメッセージを移動する

• メッセージタイプごとに設定した条件に従って、メッセージを有効期限切れにする

20.7.1.1 メッセージタイプ設定の計画

統合されたメッセージングアプリケーションでは、Messaging Server がデータを格納して管理できるように、標準のインターネットメッセージヘッダーに異なる形式のデータが指定されます。たとえば、ボイスメールがエンドユーザーの電話に送信された場合、電話フロントエンドシステムは着信したボイスメールにメッセージヘッダーを追加し、それをメッセージストアに配信します。

タイプの異なるメッセージを認識して管理するには、統合メッセージングシステムのすべてのコンポーネントが同じメッセージタイプ定義と同じヘッダーフィールドを使用してメッセージを識別する必要があります。

メッセージタイプをサポートするようにメッセージストアを設定する前に、次の作業を実行してください。

• 使用するメッセージストアを計画する

• 各メッセージストアの定義を決定する

• 使用するヘッダーフィールドを決定する

たとえば、アプリケーションに電話メッセージが含まれる場合は、そのメッセージタイプを「multipart/voice-message」として定義し、Content-Type ヘッダーを使用してメッセージタイプを識別することができます。

その場合は、メッセージストアに配信される各電話メッセージに次のヘッダー情報を追加するように電話フロントエンドシステムを設定します。

Content-Type: multipart/voice-message

次に、次の各節の説明に従って、multipart/voice-message メッセージタイプを認識するようにメッセージストアを設定します。

20.7.1.2 メッセージタイプの定義と使用

メッセージタイプを定義するには、そのメッセージタイプに対して multipart/voice-message などの一意の定義を指定します。デフォルトでは、メッセージストアは Content-Type ヘッダーフィールドを読み取ってメッセージタイプを判定します。必要に応じて、メッセージタイプを識別するための別のヘッダーフィールドを設定できます。

メッセージストアは、Content-Type (または指定されたほかの) ヘッダーフィールドを読み取ります。値の大文字と小文字は区別されません。つまり、ヘッダーの大文字と小文字の組み合わせが予想される組み合わせと異なっても、メッセージストアはヘッダーフィールドを有効なものとして受け入れます。

メッセージストアは、ヘッダーフィールド内のメッセージタイプ名のみを読み取ります。ほかの引数やパラメータは無視されます。

メッセージタイプを定義するには、configutil ユーティリティーを使用して store.messagetype パラメータの値を設定します。手順については、「メッセージタイプを設定する」を参照してください。

メッセージタイプを設定することにより、メッセージストアは指定されたタイプのメッセージを識別して操作できるようになります。これは、統合メッセージングアプリケーションでメッセージタイプを管理するための最初の重要な手順です。

メッセージストアによって提供されるメッセージタイプの機能を十分に利用するには、次の作業の一部またはすべてを実行するようにしてください。

• JMQ 通知プラグインを設定し、メッセージタイプのステータスを追跡する通知を取得するための Message Queue クライアントを記述する

• 各メッセージタイプに適用される制限容量を指定したルートを設定する

• 有効期限ルールを記述し、メッセージタイプに応じてメッセージの有効期限切れと消去を行うための LDAP 属性値を設定する

これらの作業については、次の各節で説明します。

• 「20.7.3 メッセージタイプに関する通知メッセージの送信」

• 「20.7.4 メッセージタイプごとの制限容量の管理」

• 「20.7.5 メッセージタイプごとのメッセージの有効期限切れ」

メッセージタイプを設定する

メッセージタイプを設定するには、configutil ユーティリティーを使用して、メッセージタイプを定義および識別する store.messagetype パラメータの値を設定します。

1. store.messagetype.enable パラメータを on に設定することにより、メッセージタイプを有効にします。

   この configutil パラメータにより、メッセージストアはメッセージタイプを識別して操作できるようになります。個々のメッセージタイプを設定する前に、このパラメータを設定してください。

   たとえば、次のコマンドを入力します。

   configutil -o store.messagetype.enable -v 1

2. store.messagetype.x パラメータを設定することにより、メッセージタイプを定義および識別します。

   変数 x によって、このメッセージタイプがメッセージストア内で識別されます。変数 x は 1 〜 63 の整数である必要があります。一意の整数を使用してこのパラメータを繰り返し設定することにより、最大 63 件のメッセージタイプを定義できます。

   メッセージタイプの値は、そのタイプを記述するテキスト文字列を使用して定義します。

   たとえば、テキストメッセージタイプを定義するには、次のコマンドを入力します。

   configutil -o store.messagetype.1 -v text/plain

   ボイスメッセージタイプを定義するには、次のコマンドを入力します。

   configutil -o store.messagetype.2 -v multipart/voice-message

3. store.messagetype.x.flagname パラメータを設定することにより、メッセージタイプのフラグ名を指定します。

   このパラメータによって、メッセージタイプを識別する一意のフラグが作成されます。このフラグは、このタイプのメッセージがメッセージストアに最初に到着したときに自動的に設定され、メッセージが消去されるまでそのメッセージに関連付けられています。フラグ名の値は、メッセージタイプを記述するテキスト文字列です。これは、store.messagetype.x パラメータに設定された値と同じである必要はありません。

   変数 x は、store.messagetype.x パラメータで定義されたメッセージタイプを示す整数の ID です。

   たとえば、前述の手順で設定されたメッセージタイプのフラグ名を定義するには、次のコマンドを入力します。

   configutil -o store.messagetype.1.flagname -v text configutil -o store.messagetype.2.flagname -v voice_message

4. store.messagetype.x.quotaroot パラメータを設定することにより、メッセージタイプの制限容量を指定したルートを設定します。

   このパラメータにより、このメッセージタイプの制限容量を指定したルートを識別して管理するための制限容量機能が有効になります。このパラメータの値は、名前 (メッセージタイプを記述するテキスト文字列) です。これは、store.messagetype.x パラメータに設定された値と同じである必要はありません。

   変数 x は、store.messagetype.x パラメータで定義されたメッセージタイプを示す整数の ID です。

   このパラメータを設定すると、指定したメッセージタイプに適用される制限容量を設定できます。詳細は、「20.7.4 メッセージタイプごとの制限容量の管理」を参照してください。

   たとえば、前述の手順で設定されたメッセージタイプの制限容量を指定したルートの使用を有効にするには、次のコマンドを入力します。

   configutil -o store.messagetype.1.quotaroot -v text configutil -o store.messagetype.2.quotaroot -v voice

5. メッセージタイプを識別するための代替ヘッダーフィールドを設定するには、store.messagetype.header パラメータを設定します。

   デフォルトでは、メッセージストアは Content-Type ヘッダーフィールドを読み取ってメッセージタイプを判定します。store.messagetype.header パラメータは、別のヘッダーフィールドを使用してメッセージタイプを識別する場合にのみ設定してください。このパラメータの値はテキスト文字列です。

   たとえば、X-Message-Type という名前のフィールドを使用するには、次のコマンドを入力します。

   configutil -o store.messagetype.header -v X-Message-Type

20.7.2 IMAP コマンドでのメッセージタイプ

メッセージタイプの store.messagetype.x.flagname パラメータを設定すると、そのメッセージタイプを識別する一意のフラグが作成されます。エンドユーザーはこのフラグを変更できません。

Messaging Server は、このメッセージタイプフラグをユーザーフラグとして IMAP クライアントに提示します。メッセージタイプをユーザーフラグに対応付けることにより、メールクライアントは簡単な IMAP コマンドを使用して、メッセージをメッセージタイプ別に操作できるようになります。

たとえば、次の操作を実行できます。

• IMAP FETCH FLAGS コマンドを使用して、メッセージタイプフラグ名をユーザー定義フラグとしてクライアントに表示します。

  IMAP FETCH FLAGS コマンドの使用例については、次に示す例 20–1 を参照してください。

• メッセージタイプフラグを IMAP SEARCH コマンド内のキーワードとして使用します。

  IMAP SEARCH コマンドの使用例については、次に示す例 20–1 を参照してください。

メッセージタイプユーザーフラグは読み取り専用です。IMAP コマンドを使用して変更することはできません。

次に示す例では、メッセージタイプの configutil パラメータが次の値で設定されていることを想定します。

store.messagetype.enable = yes

store.messagetype.1 = text/plain
store.messagetype.1.flagname = text
store.messagetype.1.quotaroot = text

store.messagetype.2 = multipart/voice-message
store.messagetype.2.flagname = voice_message
store.messagetype.2.quotaroot = voice

例 20–1 メッセージタイプの configutil 設定に基づく IMAP FETCH セッション

次の IMAP セッションでは、現在選択されているメールボックスに対応するメッセージを取得しています。

2 fetch 1:2 (flags rfc822)
* 1 FETCH (FLAGS (\Seen text) RFC822 {164}

Date: Wed, 8 July 2006 03:39:57 -0700 (PDT)
From: bob.smith@siroe.com
To: john.doe@siroe.com
Subject:  Hello
Content-Type: TEXT/plain; charset=us-ascii


* 2 FETCH (FLAGS (\Seen voice_message) RFC822 {164}

Date: Wed, 8 July 2006 04:17:22 -0700 (PDT)
From: sally.lee@siroe.com
To: john.doe@siroe.com
Subject:  Our Meeting
Content-Type: MULTIPART/voice-message; ver=2.0

2 OK COMPLETED

前の例では、1 つのテキストメッセージと 1 つのボイスメールの計 2 つのメッセージが取得されています。

メッセージタイプフラグは、store.messagetype.*.flagname パラメータで設定された形式で表示されます。

メッセージタイプは、Content-Type ヘッダーフィールドによって識別されます。メッセージタイプ名は、受信メッセージ内で受信されたときに表示されます。メッセージタイプ名には、大文字と小文字が混在し、charset=us-ascii などのメッセージタイプ引数が含まれています。

例 20–2 メッセージタイプの configutil 設定に基づく IMAP SEARCH セッション

次の IMAP セッションでは、現在選択されているメールボックスに対応するボイスメッセージを検索しています。

3 search keyword voice_message
* SEARCH 2 4 6 
3 OK COMPLETED

前の例では、2、4、および 6 がボイスメッセージです。検索に使用されたキーワードは、store.messagetype.2.flagname パラメータの値である voice_message です。

20.7.3 メッセージタイプに関する通知メッセージの送信

通知により、テキストメッセージ、ボイスメール、イメージデータなどのさまざまなタイプのメッセージに関するステータス情報を配信できます。Messaging Server は、Sun Java System Message Queue を使用してメッセージタイプに関する通知情報を送信します。Message Queue 用の JMQ 通知プラグインの設定については、第 22 章「Message Queue のためのメッセージを生成する JMQ 通知プラグインの設定」を参照してください。

JMQ 通知プラグインを有効にして特定のメッセージタイプを認識するには、store.messagetype.x.flagname パラメータを含む store.messagetype パラメータを設定する必要があります。詳細は、「メッセージタイプを設定する」を参照してください。

メッセージタイプを設定すると、JMQ 通知メッセージによって特定のメッセージタイプを識別できるようになります。メッセージタイプごとに通知メッセージを解釈し、各タイプに関するステータス情報をメールクライアントに配信するように Message Queue クライアントを記述できます。

JMQ 通知機能では、メールボックスに現在含まれているメッセージの個数がメッセージタイプごとに取得されます。全体の個数ではなく、メッセージタイプごとの個数を指定した配列が通知メッセージによって送信されます。

たとえば、NewMsg 通知メッセージに、7 個の新しいボイスメールメッセージと 4 個の新規テキストメッセージがユーザーの受信箱にあることをユーザーに知らせるデータを格納することができます。

メッセージタイプごとに通知を送信する方法の詳細については、「22.3.3 特定のメッセージタイプに対する通知」を参照してください。

20.7.4 メッセージタイプごとの制限容量の管理

メッセージタイプの制限容量を設定するときは、制限容量を設定したルートにその値を追加します。制限容量を設定したルートには、1 人のユーザーに対する制限容量を指定します。特定のメッセージタイプやメールボックスフォルダに対して異なる制限容量を指定し、タイプによって定義されないほかのすべてのメッセージタイプ、フォルダ、およびメッセージに適用されるデフォルトの制限容量を指定することができます。

制限容量の設定と管理の詳細については、「20.8.2 制限容量の動作方式」を参照してください。

20.7.4.1 メッセージタイプの制限容量を設定する前に

メッセージタイプの制限容量を設定する前に、次のパラメータを設定してください。

• 各メッセージタイプの store.messagetype.x.quotaroot パラメータを設定します。詳細は、「メッセージタイプを設定する」を参照してください。

• store.typequota.enable パラメータを on に設定します。

  たとえば、次のコマンドを入力します。

  configutil -o store.typequota.enable -v 1

20.7.4.2 メッセージタイプの制限容量の設定方法

メッセージタイプの制限容量を設定するには、次のいずれかの方法を使用します。

• LDAP 属性 mailQuota または mailMsgQuota、あるいはその両方を使用して、1 人のユーザーに対するメッセージタイプの制限容量を設定します。

  これらの属性を使用して制限容量を設定したルートを設定する方法については、『Sun Java Communications Suite 5 Schema Reference』の第 3 章「Messaging Server and Calendar Server Attributes」の mailQuota エントリと mailMsgQuota エントリを参照してください。

• mailQuota 属性および mailMsgQuota 属性を設定しない場合は、すべての個別ユーザーに適用されるデフォルトのメッセージタイプの制限容量を設定します。

  デフォルトの制限容量を設定するには、store.defaultmessagequota パラメータまたは store.defaultmailboxquota パラメータ、あるいはその両方を使用します。

  これらのパラメータを使用して制限容量を設定したルートを設定する方法については、「20.8.4 メッセージストアの制限容量を設定する」を参照してください。

前述の configutil パラメータまたは LDAP 属性を使用してメッセージタイプの制限容量を設定するときは、store.messagetype.x.quotaroot パラメータに指定した制限容量を設定したルートを使用してください。

20.7.4.3 メッセージタイプの制限容量を設定したルートの例

この節に示す例では、ユーザー joe に対して次の制限容量を設定します。

• デフォルトのメールボックス保存制限容量は 40M

• デフォルトのメールボックスメッセージ制限容量は 5000

• アーカイブフォルダの保存制限容量は 100M

• テキストメッセージタイプの保存制限容量は 10M

• テキストメッセージタイプのメッセージ制限容量は 2000

• ボイスメッセージタイプの保存制限容量は 10M

• ボイスメッセージタイプのメッセージ制限容量は 200

この制限容量を設定したルートは、ほかのすべてのフォルダおよびメッセージタイプの合計 (60M) より大きい保存容量 (100M) をアーカイブフォルダに許可します。また、アーカイブフォルダに対するメッセージ制限容量は設定されていません。この例では、アーカイブに関しては保存容量の制限のみが問題になります。

メッセージタイプには、保存容量とメッセージ数の両方の制限が設定されます。

メッセージタイプの制限容量は、メッセージがアーカイブフォルダ、またはほかのフォルダのどちらに保存されるかに関係なく、該当するタイプのメッセージすべての合計に対して適用されます。

デフォルトのメールボックス制限容量は、メッセージタイプがテキストでもボイスでもなく、アーカイブフォルダに保存されないすべてのメッセージに対して適用されます。つまり、メッセージタイプの制限容量とアーカイブの制限容量は、デフォルトのメールボックス制限容量の一部として数えられません。

この例の制限容量を設定したルートを設定するには、次の手順を実行します。

1. store.messagetype.x.quotaroot パラメータを次のように設定します。

   store.messagetype.1.quotaroot = text store.messagetype.2.quotaroot = voice

2. ユーザー joe に対する mailQuota 属性を次のように設定します。

   mailQuota: 20M;#text%10M;#voice%10M;Archive%100M

3. ユーザー joe に対する mailMsgQuota 属性を次のように設定します。

   mailMsgQuota: 5000;#text%2000;#voice%200

getquotaroot IMAP コマンドを実行すると、ユーザー joe のメールボックスに関するすべての制限容量を設定したルートが、実行結果の IMAP セッションに次のように表示されます。

1 getquotaroot INBOX
* QUOTAROOT INBOX user/joe user/joe/#text user/joe/#voice
* QUOTA user/joe (STORAGE 12340 20480 MESSAGE 148 5000)
* QUOTA user/joe/#text (STORAGE 1966 10240 MESSAGE 92 2000)
* QUOTA user/joe/#voice (STORAGE 7050 10240 MESSAGE 24 200)

2 getquotaroot Archive
* QUOTAROOT user/joe/Archive user/joe/#text user/joe/#voice
* QUOTA user/joe/Archive (STORAGE 35424 102400)
* QUOTA user/joe/#text (STORAGE 1966 10240 MESSAGE 92 2000)

* QUOTA user/joe/#voice (STORAGE 7050 10240 MESSAGE 24 200)

20.7.5 メッセージタイプごとのメッセージの有効期限切れ

有効期限および消去機能により、有効期限ルールで定義した条件に従って、メッセージのフォルダ間移動、メッセージのアーカイブ、およびメッセージストアからのメッセージの消去を実行できます。これらの作業は、imexpire ユーティリティーを使用して実行します。

imexpire ユーティリティーは管理者によって実行されるため、制限容量の適用は省略されます。

有効期限ルールの作成方法と imexpire ユーティリティーの使用方法については、「20.9 自動メッセージ削除 (有効期限および消去) 機能を設定する」を参照してください。

有効期限ルールを作成することにより、異なるタイプのメッセージを異なる条件に従って有効期限切れにすることができます。

有効期限機能は柔軟性がきわめて高く、さまざまなオプションを使用して有効期限切れの条件を設定できます。この節では、テキストメッセージとボイスメッセージが異なる条件に従って有効期限切れになる例を示します。

この例では、テキストメッセージタイプとボイスメッセージタイプが次のように設定されていることを想定します。

store.messagetype.1 = text/plain

store.messagetype.2 = multipart/voice-message

また、メッセージストアが Content-Type ヘッダーフィールドを読み取ってメッセージタイプを判定するように設定されていることを想定します。

例 20–3 異なるメッセージタイプを有効期限切れにするためのルール例

TextInbox.folderpattern: user/%/INBOX
TextInbox.messageheader.Content-Type: text/plain
TextInbox.messagedays: 365
TextInbox.action: fileinto:Archive


VoiceInbox.folderpattern: user/%/INBOX
VoiceInbox.messageheader.Content-Type: multipart/voice-message
VoiceInbox.savedays: 14
VoiceInbox.action: fileinto:OldMail

VoiceOldMail.folderpattern: user/%/OldMail
VoiceOldMail.messageheader.Content-Type: multipart/voice-message
VoiceOldMail.savedays: 30
VoiceOldMail.action: fileinto:Trash

Trash.folderpattern: user/%/Trash
Trash.savedays: 7
Trash.action: discard

この例では、テキストメッセージとボイスメールが次のように異なる方法で有効期限切れになり、異なるスケジュールに従います。

• テキストメッセージは、メッセージストアに到着してから 1 年後にユーザーの受信箱からユーザーのアーカイブフォルダに移動します。

• ボイスメールは、2 週間後に受信箱から OldMail フォルダに移動します。ユーザーがボイスメッセージを保存すると、保存日がリセットされ、新しい保存日から 2 週間後にメッセージが移動します。

• ボイスメールは、30 日後に OldMail フォルダからごみ箱フォルダに移動します。ユーザーは、OldMail フォルダ内のボイスメッセージを保存することもできます。その場合、メッセージの削除は新しい保存日から 30 日後に延期されます。

• すべてのタイプのメッセージは、ごみ箱フォルダに移動してから 7 日後に破棄されます。

  ボイスメールは、有効期限ルールによって自動的にごみ箱に移動します。テキストメッセージは、ユーザーがメッセージを削除したときにごみ箱に移動します。

注意: savedays ルールにより、メッセージを保存してから指定された日数が経過すると、そのメッセージは有効期限切れになります。一般的なボイスメールシステムでは、ユーザーはボイスメールメニューでボイスメールを保存できます。テキストメッセージの場合は、ほかのフォルダに移動したときにメッセージが保存されます。messagedays ルールにより、メッセージがメッセージストアに最初に到着してから指定された日数が経過すると、メッセージが保存されたフォルダやメッセージの移動回数に関係なく、そのメッセージは有効期限切れになります。

20.8 メッセージストアの制限容量について

電子メールやボイスメールを大量に受信すると、IMAP のメールボックスが非常に大きくなる可能性があります。メッセージストアの制限容量は、ユーザーまたはドメインが保持できるディスク容量またはメッセージ数を制限するもので、特定のフォルダまたは特定のメッセージタイプに対して設定されます。制限容量は、メッセージストアの使用量を制限または軽減するために使用されます。この節では、次の情報について説明します。

詳細については、「20.11.4 制限容量を監視する」を参照してください。

• 「20.8.1 制限容量の概要」

• 「20.8.2 制限容量の動作方式」

• 「20.8.3 メッセージストアの制限容量の属性およびパラメータ」

• 「20.8.4 メッセージストアの制限容量を設定する」

20.8.1 制限容量の概要

制限容量は、特定のユーザーまたはドメインを対象とし、メッセージ数またはバイト数に関して設定できます。特定のフォルダやメッセージタイプを対象として設定することもできます。メッセージタイプの制限容量では、ボイスメールや電子メールなどのメッセージタイプごとに制限容量を指定できます。フォルダの制限容量は、ユーザーのフォルダ (バイト単位) またはメッセージのサイズに制限を設定します。たとえば、ごみ箱フォルダの制限容量を設定できます。Messaging Server では、ドメインおよびユーザーに対して、デフォルトおよびカスタムの制限容量を設定することができます。

制限容量を設定すると、制限容量を超えた、または制限容量に近づいているユーザーやドメインに対するシステムの対応方法を設定することもできます。1 つの対応方法は、制限容量超過通知をユーザーに送信することです。もう 1 つの対応方法は、制限容量を超過したときにメッセージストアへのメッセージ配信を停止することです。これは、制限容量の適用と呼ばれ、指定された猶予期間が経過したあとで行われます。猶予期間とは、メールボックスが制限容量を超過してから制限容量が適用されるまでの期間です。制限容量を超過したためにメッセージ配信が停止された場合、次のどちらかの状態になるまで、着信メッセージは MTA キューに残ったままとなります。

• ユーザーのメッセージのサイズまたは数が制限容量を超えない状態になったとき。この時点で MTA によってメッセージが配信されます。

• 未配信のメッセージの MTA キューに残留している期間が、メッセージが差出人に返されるよう指定された猶予期間を超えてしまったとき。(「20.8.4.5 猶予期間を設定する」を参照)。

• メッセージがメッセージキューの最大時間を過ぎてもメッセージキューに残っているとき。これは、notices MTA チャネルキーワードによって制御されます (「10.10.4.3 通知メッセージの配信間隔を設定する」を参照)。

  たとえば、猶予期間が 2 日間に設定されているときに 1 日分の制限容量を超えた場合、新しいメッセージは引き続き受信され、メッセージキュー内に保持され、配信試行は続行します。2 日目を過ぎると、メッセージは差出人に戻されます。

ユーザーがメッセージを削除するか、サーバーが設定された有効期限ポリシーに従ってメッセージを削除すると、ディスク容量が使用可能になります (「20.9 自動メッセージ削除 (有効期限および消去) 機能を設定する」を参照)。

20.8.1.1 Telephony Application Server に関する例外

統一されたメッセージング要件をサポートするために、Messaging Server ではメッセージストアによって課された制限容量を無効にする機能を提供しています。これにより、特定のエージェント、つまり Telephony Application Servers (TAS) が受け取ったメッセージが確実に配信されます。TAS によって受け入れられたメッセージは特別な MTA チャネルを通るようにルーティングされ、メッセージは制限容量に関係なくストアに配信されるようになります。これは、かなり難解な使用法ですが、テレフォニーアプリケーションに使用できます。TAS チャネルの設定の詳細については、Sun のメッセージング担当者にお問い合わせください。

統合されたメッセージングを使用するテレフォニーアプリケーションでは、メッセージタイプごとの制限容量が役に立ちます。たとえば、テキストやボイスメールなどの混在したメッセージがユーザーのメールボックスに保存されている場合、管理者はメッセージのタイプごとに異なる制限容量を設定できます。ユーザーの電子メールに特定の制限容量を設定し、ユーザーのボイスメールに別の制限容量を設定できます。

20.8.2 制限容量の動作方式

カスタマイズされたユーザーおよびドメイン制限容量は、LDAP のユーザーおよびドメインエントリに制限容量の属性を追加することによって指定します。制限容量のデフォルト、通知ポリシー、実施、および猶予期間は、configutil パラメータに指定するか、または『Sun Java System Messaging Server 6.3 Administration Reference』の「imquotacheck」コマンドを使用して指定します。

ユーザーが制限容量を超えているかどうかを判別するために、Messaging Server は、まず個々のユーザーに対する制限容量が設定されているかどうかを確認します。個別の制限容量が設定されていない場合、Messaging Server はすべてのユーザーに対して設定されているデフォルトの制限容量を確認します。ユーザーの場合、この制限容量は、ユーザーのすべてのフォルダに含まれるメッセージすべての累積バイト数またはメッセージ数に対するものです。ドメインの場合、この制限容量は、特定のドメインに属するすべてのユーザーのメッセージすべての累積バイト数またはメッセージ数に対するものです。メッセージタイプの場合、この制限容量は、そのメッセージタイプのメッセージすべての累積バイト数またはメッセージ数に対するものです。フォルダの場合、この制限容量は、ユーザーのフォルダに含まれるメッセージすべての累積バイト数またはメッセージ数に対するものです。

ユーザーのメールボックスツリーに対して、次の制限容量値を指定できます。

• ユーザーのメールボックス内にある特定のフォルダに対する制限容量値。

• ボイスメールやテキストメッセージなどの特定のメッセージタイプに対する制限容量値。メッセージタイプの制限容量は、ユーザーのメールボックス内のすべてのフォルダに含まれるそのタイプのメッセージに対して適用されます。

• ユーザーのメールボックス内の、制限容量が明示的に割り当てられていないすべてのフォルダおよびメッセージタイプに適用されるデフォルトの制限容量。

1 人のユーザーに複数の制限容量値を割り当てる場合は、次のガイドラインが適用されます。

• 制限容量は重複しません。たとえば、特定のメッセージタイプまたはフォルダに対する制限容量がある場合、そのタイプのメッセージまたはそのフォルダ内のメッセージは、デフォルトの制限容量の対象にはなりません。各メッセージは、必ずただ 1 つの制限容量の対象になります。

• ユーザーのメールボックス全体の制限容量は、デフォルト、タイプ別、およびフォルダ別で指定された制限容量すべての合計値と一致します。

• メッセージタイプの制限容量は、フォルダの制限容量より優先されます。たとえば、ユーザーの memos フォルダに対して制限容量が指定され、ボイスメッセージに対して別の制限容量が指定されたとします。ユーザーが memos フォルダに 8 個のボイスメッセージを保存するとします。この 8 件のメッセージは、ボイスメッセージの制限容量の対象になりますが、memos フォルダの制限容量の対象にはなりません。

制限容量の属性および configutil パラメータに対する変更は自動的に有効になりますが、これはキャッシュに情報が保存された直後ではなく、変更が完全に有効になるまでにやや時間がかかります。Messaging Server には、変更をただちに更新する『Sun Java System Messaging Server 6.3 Administration Reference』の「iminitquota」コマンドが用意されています。

また、『Sun Java System Messaging Server 6.3 Administration Reference』の「imquotacheck」ユーティリティーを使用すると、割り当てられた制限容量に対するメッセージストアの使用量を確認できます。

20.8.3 メッセージストアの制限容量の属性およびパラメータ

この節では、メッセージストアの主要な制限容量の属性および configutil パラメータについて説明します。ここでの目的は、機能的インタフェースの概要を示すことです。これらの属性およびパラメータの詳細については、該当するリファレンスマニュアルを参照してください。

次の表は、制限容量の属性について説明したものです。『Sun Java Communications Suite 5 Schema Reference』を参照してください。

次の表は、制限容量のパラメータについて説明したものです。最新の詳細情報については、『Sun Java System Messaging Server 6.3 Administration Reference』の第 3 章「Messaging Server Configuration」を参照してください。

メッセージストアの制限容量機能には、いくつかのユーティリティーも含まれています。『Sun Java System Messaging Server 6.3 Administration Reference』の「iminitquota」は、制限容量の設定を初期化します。つまり、制限容量の属性および configutil パラメータは、このコマンドの実行後に有効になります。このコマンドを実行しなくても変更は有効になりますが、これはキャッシュに情報が保存された直後ではなく、変更が有効になるまでにやや時間がかかります。

また、『Sun Java System Messaging Server 6.3 Administration Reference』の「imquotacheck」ユーティリティーを使用すると、割り当てられた制限容量に対するメッセージストアの使用量を確認できます。

20.8.4 メッセージストアの制限容量を設定する

この節では、次の作業について説明します。

20.8.4.1 デフォルトのユーザー制限容量を指定する

デフォルトの制限容量は、該当する LDAP エントリに個別の制限容量が設定されていないユーザーに適用されます。この処理は、1) デフォルトのユーザー制限容量の指定、2) デフォルトの制限容量にバインドされるユーザーの指定、の 2 つの手順で構成されます。次の例は、デフォルトのユーザー制限容量の設定方法を示したものです。パラメータの詳細については、『Sun Java System Messaging Server 6.3 Administration Reference』の第 3 章「Messaging Server Configuration」を参照してください。

メッセージのサイズ (バイト単位) に関するデフォルトのユーザーディスク制限容量を指定する場合は、次のようになります。

configutil -ostore.defaultmailboxquota -v [ -1 | number ]

ここで -1 は制限容量がない (メッセージの使用量に制限がない) ことを示し、number はバイト数を示します。

メッセージの合計数についてのデフォルトのユーザー制限容量を指定する場合は、次のようになります。

configutil -o store.defaultmessagequota -v [ -1 | number ]

ここで -1 は制限容量がない (メッセージ数に制限がない) ことを示し、number はメッセージ数を示します。

特定のユーザーについて、デフォルトの制限容量を指定する場合は、次のようになります。

デフォルトのメッセージストアの制限容量を使用する場合は、ユーザーエントリで、mailQuota 属性を -2 に設定します。mailQuota が指定されていない場合は、システムのデフォルトの制限容量が使用されます。

20.8.4.2 個々のユーザー制限容量を指定する

各ユーザーには、制限容量を個別に設定できます。ユーザー固有の制限容量を設定するには、ユーザーの LDAP エントリ内の『Sun Java Communications Suite 5 Schema Reference』の「mailQuota」属性または 『Sun Java Communications Suite 5 Schema Reference』の「mailMsgQuota」属性を設定します (詳細は『Sun Java System Messaging Server 6.3 Administration Reference』の「configutil Parameters」を参照)。次の例は、ユーザー制限容量の設定方法を示したものです。

システムのデフォルトの制限容量を指定するには、LDAP エントリに mailQuota を追加しないようにするか、または mailQuota を –2 に設定します。

制限容量を 1,000 メッセージに設定するには、mailMsgQuota を 1000 に設定します。

制限容量を 2M バイトに設定するには、mailQuota を 2M または 2000000 に設定します。

制限容量を 2G バイトに設定するには、mailQuota を 2G、2000000000、または 2000M に設定します。

制限容量を 2G バイト、ボイスメールの制限容量を 20M バイト、アーカイブフォルダの制限容量を 100M バイトにぞれぞれ指定する場合は、次のようになります。

mailQuota: 2G;#voice%20M;Archive%100M

2G バイトの制限容量は、ユーザーのメールボックス内の、制限容量が明示的に割り当てられていないすべてのフォルダに対応します。この例では、Archive フォルダ内のメッセージと voice タイプのメッセージは除外されます。100M バイトの制限容量には、Archive フォルダ内のすべてのフォルダが含まれます。

20.8.4.3 ドメイン制限容量を指定する

ドメインには、ディスク容量またはメッセージの制限容量を設定できます。これらの制限容量は、特定のドメイン内のすべてのユーザーの、累積されたバイトまたはメッセージすべてに対するものです。ドメイン制限容量を設定するには、該当する LDAP ドメインエントリで『Sun Java Communications Suite 5 Schema Reference』の「mailDomainDiskQuota」属性または 『Sun Java Communications Suite 5 Schema Reference』の「mailDomainMsgQuota」属性を設定します。

制限容量を 1,000 メッセージに設定するには、mailDomainMsgQuota を 1000 に設定します。

制限容量を 2M バイトに設定するには、mailDomainDiskQuota を 2M または 2000000 に設定します。

制限容量を 2G バイトに設定するには、mailDomainDiskQuota を 2G、2000000000、または 2000M に設定します。

制限容量の通知を設定する

制限容量の通知とは、制限容量に近づいたときにユーザーに警告メッセージを送信する処理のことです。この機能を使用するには、3 つの手順が必要です。

1. 制限容量の通知を有効にします。

   コマンド行で次のコマンドを実行します。

   configutil -o store.quotanotification -v [ yes | no ]

   メッセージに何も設定されなかった場合、ユーザーには制限容量の警告メッセージは送信されません。

2. 制限容量の警告メッセージを定義します。

   この警告メッセージは、ディスク制限容量に近づいたユーザーに送信されるメッセージです。コマンド行で制限容量の警告メッセージを定義する場合は、次のようになります。

   configutil -o store.quotaexceededmsg -v ’message’

   メッセージは RFC 822 形式でなければなりません。メッセージには少なくとも件名行を含むヘッダーがあり、$$、メッセージ本文がそのあとに続いている必要があります。$ は、新しい行を表します。使用しているシェルによっては、$ の前に \ を追加して、$ が持つ特殊な意味をエスケープする必要があることもあります (ほとんどの場合、$ はシェルのエスケープ文字。)例:

   configutil -o store.quotaexceededmsg -v ”Subject: WARNING: User quota exceeded$$User quota threshold exceeded - reduce space used.’

   さらに、次の変数がサポートされます。

   [ID] - ユーザー ID

   [DISKUSAGE] - ディスク使用量

   [NUMMSG] - メッセージの数

   [PERCENT] - store.quotawarn パーセンテージ

   [QUOTA] - mailquota 属性

   [MSGQUOTA] - mailmsgquota 属性

   次にこれらの変数の使用例を示します。

   configutil -o store.quotaexceededmsg -v ”Subject: Overquota Warning$$[ID],$$Your mailbox size has exceeded [PERCENT] of its alloted quota.$Disk Usage: [DISKUSAGE]$Number of Messages: [NUMMSG]$Mailquota: [QUOTA]$Message Quota: [MSGQUOTA]$$-Postmaster’

3. 警告メッセージの送信頻度を指定する場合は、次のようになります。

   次のパラメータを設定します。

   configutil -o store.quotaexceededmsginterval -v number

   この number は日数を示しています。たとえば、3 が入っていれば 3 日ごとにメッセージが送信されます。

4. 制限容量のしきい値を指定します。

   制限容量のしきい値は、クライアントに警告が送信されるときの、制限容量を超えたパーセンテージです。ユーザーのディスク使用量が指定したしきい値を超えたら、サーバーからユーザーに警告メッセージが送信されます。

   ---

   注 –

   local.store.quotaoverdraft=on の場合、store.quotawarn で設定されたしきい値に関係なく、ユーザーのディスク使用量が制限容量の 100% を超えるまで電子メール通知はトリガーされません。

   ---

   クライアントが IMAP ALERT 機能をサポートしている IMAP ユーザーの場合は、ユーザーがメールボックスを選択するたびに画面にメッセージが表示され、メッセージは IMAP ログにも書き込まれます。

   コマンド行で制限容量のしきい値を指定する場合は、次のようになります。

   configutil -o store.quotawarn -v number

   この number は許可された制限容量のパーセンテージを示しています。

20.8.4.4 制限容量の適用を有効または無効にする

デフォルトでは、制限容量を超えてもユーザーまたはドメインには何の影響もなく、制限容量超過通知が設定されている場合に通知を受信するだけです。制限容量を適用すると、ディスク容量が制限容量レベルを下回るまで、それ以上メッセージを受信しないようメールボックスをロックします。

制限容量の適用を有効または無効にするには、次のようにします。

configutil -o store.quotaenforcement -v [ on | off]

制限容量を超過すると、メッセージは MTA キューに保存され、メッセージが配信されなかったが、あとで再配信が試行されることを示す通知が差出人へ送信されます。配信の再試行は、猶予期間の期限が切れて、すべてのメッセージが差出人に戻されるまで、またはディスク使用量が制限容量を下回り、メッセージを MTA キューから取り出してメッセージストアに配信できるようになるまで続行されます。制限容量を超えた場合に、メッセージをキューに入れる前にメッセージを返す場合は、次のコマンド行を使用します。

configutil -o store.overquotastatus -v on

制限容量の適用をドメインレベルで有効にする

特定のドメインの制限容量を適用するには、次のコマンドを使用します。

imquotacheck -f -d domain

すべてのドメインについて有効にするには、-d オプションを除外します。ドメインがその制限容量を超過すると、maildomainstatus 属性が overquota に設定され、このドメインへの全配信が停止します。ドメインが overquota でない場合、値は active に設定されます。

制限容量の適用を無効にする

ユーザーの制限容量が適用されているようである場合は、制限容量を無効にした場合でも、次のパラメータを確認してください。

次の configutil パラメータは、オフにするか設定しないようにする必要があります。

• store.quotaenforcement

• local.store.overquotastatus

• local.store.quotaoverdraft

store.overquotastatus が on の場合、常に store.quotaoverdraft が on であるとみなし、そうでない場合はユーザーは制限容量を超過して拒否を引き起こすことはありません。また、store.quotaoverdraft が on の場合、ユーザーは制限容量よりも小さいメッセージを 1 つだけ許可されます。すなわち、ユーザーの制限容量よりも大きいメッセージは受け入れません。

これらのパラメータを変更したあとは、必ずメッセージングサービスを再起動してください。

次のメッセージストア属性はアクティブにする必要があります。

• maildomainstatus

• mailuserstatus

メッセージがメールボックスの制限容量よりも大きい場合は、制限容量の適用設定とは無関係にバウンスされます。

20.8.4.5 猶予期間を設定する

猶予期間は、メッセージを差出人にバウンスするまでメールボックスが制限容量 (ディスク容量やメッセージの数) を超えた状態でいられる期間を指定するものです。猶予期間とは、メッセージがメッセージキュー内に保持される期間ではなく、メッセージキュー内に含まれているすべての着信メッセージがバウンスされるまでに、メールボックスが制限容量を超えた状態でいられる期間です。(詳細は 「20.1 概要」を参照。) 猶予期間は、ユーザーが制限容量のしきい値に達し、警告を受けたときに開始します。「制限容量の通知を設定する」を参照してください。

コマンド行で制限容量の猶予期間を指定する場合は、次のようになります。

configutil -o store.quotagraceperiod -v number

この number は時間数を示しています。

20.8.4.6 Netscape Messaging Server の制限容量の互換性モード

Netscape Messaging Server のディスク使用量が制限容量を超過すると、サーバーはメッセージの配信を延期またはバウンスし、制限容量超過通知を送信して、猶予期間を開始します。Messaging Server には、この動作を保持するパラメータ local.store.quotaoverdraft があります。

ON に設定すると、メッセージはディスクの使用量が制限容量を超過するまで配信されます。超過時には、メッセージが延期され (メッセージは MTA メッセージキューに保持されるが、メッセージストアに配信されない)、制限容量超過警告メッセージがユーザーに送信されて、猶予期間が開始されます。猶予期間は、制限容量超過メッセージがバウンスされるまで、メールボックスが制限容量超過である期間を決定します。デフォルトでは、メッセージストアがしきい値に達したときに、制限容量の警告メッセージが送信されます。このパラメータのデフォルトは、Off です。

20.9 自動メッセージ削除 (有効期限および消去) 機能を設定する

自動メッセージ削除 (有効期限および消去とも呼ばれる) 機能を使用すると、管理者が定義した一連の条件に基づいて、メッセージストアからメッセージが自動的に削除されます。この機能によって、古いメッセージやサイズの大きいメッセージ、開封済みまたは削除済みメッセージ、特定の Subject: 行を持つメッセージなどを自動的に削除できます。次の削除条件が設定できます。

• フォルダ (メールボックス) 別、ユーザー別、ドメイン別、メッセージストア全体、または特定のパーティション

• メールボックス内のメッセージ件数

• メールボックスの合計サイズ

• メールボックスでのメッセージの存続期間 (日数)

• メッセージのサイズと猶予期間 (サイズ超過のメッセージを消去する前にメッセージストアに残しておく日数)

• メッセージのフラグが seen か deleted かどうか

• ヘッダー文字列

この機能は、メッセージの消去や消去を行う imexpire ユーティリティーを使用して実行します。メッセージ削除プロセスの詳細については、「20.3 メッセージストアによるメッセージの削除方法」を参照してください。

サーバーによってメッセージは警告なしに削除されます。したがって、自動メッセージ削除ポリシーについてユーザーに知らせておくことは重要です。メッセージが突然削除されると、ユーザーや管理者は大変驚くことになるからです。

• 「20.9.1 imexpire の動作方式」

• 「20.9.2 自動メッセージ削除機能を配備する」

20.9.1 imexpire の動作方式

imexpire は、コマンド行から呼び出すか、imsched デーモンを使用して自動的に実行されるようにスケジュールします。管理者は、store.expirerule というファイルに一連の有効期限ルールを指定します。このファイルは、メッセージを削除する条件を指定します。ルールの範囲に関連するディレクトリごとに、複数のファイルが存在する場合があります。つまり、メッセージストア全体にグローバルに適用されるルールはあるディレクトリに置かれ、パーティションに適用されるルールは別のディレクトリ、ユーザーに適用されるルールはさらに別のディレクトリに置かれる、というようになります。

グローバル有効期限ルールは、configutil コマンドと store.expire.attribute パラメータを使用して指定することもできますが、store.expirerule を使用する方法をお勧めします。configutil を使用して多数のルールを作成すると、パフォーマンスの問題が発生することがあります。

imexpire は、起動時にすべての有効期限ルールをロードします。デフォルトでは、imexpire はパーティションごとに 1 つのスレッドを作成します。各スレッドは割り当てられたパーティションの下にあるユーザーフォルダのリストを通過し、その間にローカル有効期限ルールをロードします。この有効期限機能により、各フォルダは有効期限ルールに照らしてチェックされ、メッセージは必要に応じて消去されます。メールボックスディレクトリの内に store.exp ファイルが存在し、store.cleanupage 設定パラメータで指定した期間を過ぎていたために消去されたり期限切れになっていたりするメッセージがある場合は、消去機能によってメッセージハッシュディレクトリ内にあるメッセージファイルが完全に削除され、store.exp ファイルから UID のレコードが削除されます。

msg-svr-base/config/ 内の expire_exclude_list と呼ばれるファイルで、1 行に 1 つずつユーザー ID を追加して、指定したユーザーを有効期限ルールから除外することもできます。

20.9.2 自動メッセージ削除機能を配備する

自動メッセージ削除には 3 つの手順が必要です。

1. 自動メッセージ削除ポリシーを定義します。どのメッセージを自動的に削除するか、どのユーザー、フォルダ、ドメイン、およびパーティションのメッセージを自動的に削除するか、およびサイズ、メッセージ存続期間、ヘッダーについて特定して削除条件を定義します。削除するメッセージの範囲を定義します。詳細については、「20.9.2.1 自動メッセージ削除ポリシーを定義する」を参照してください。

2. imexpire ルールを指定してこのポリシーを実装します。詳細については、「20.9.2.2 自動メッセージ削除ポリシーを実装するルールを設定する」を参照してください。

3. imexpire スケジュールを指定します。詳細については、「20.9.2.3 自動メッセージ削除とログレベルをスケジュールする」を参照してください。

20.9.2.1 自動メッセージ削除ポリシーを定義する

削除条件を指定して独自の自動メッセージ削除ポリシーを定義します。imexpire を使用すると、次の条件を使用する削除が可能になります。

メッセージの存続期間: X 日間より存続期間が長いメッセージを自動的に削除します。属性: messagedays。

メッセージの件数: X 件を超えたフォルダ内のメッセージを自動的に削除します。属性: messagecount。

サイズ超過メッセージの存続期間: X バイトを超えるメッセージを Y 日間の猶予期間後に自動的に削除します。属性: messagesize および messagesizedays。

開封済みおよび削除済みメッセージフラグ: 「開封済み」または「削除済み」フラグが付いているメッセージを自動的に削除します。これらの条件には、「and」または「or」が設定できます。or に設定した場合、メッセージに開封済みまたは削除済みフラグが付いていると、ほかの条件にかかわらず自動削除されます。and に設定した場合、メッセージに付いている開封済みまたは削除済みフラグは、指定したほかの条件すべてを満たした場合に設定されます。属性: seen および deleted。

メッセージのヘッダーフィールド: メッセージを削除する条件としてヘッダーおよび文字列を指定できます。たとえば、「Subject: Work from Home!」というヘッダーがあるメッセージをすべて削除できます。

メッセージのフォルダ: メッセージを削除するフォルダを指定できます。属性: folderpattern。この属性だけは、modified UTF-7 形式の文字セットを使用します。

imexpire を使用して、メッセージが開封されてからの期間に基づいてメッセージを削除または保存することはできません。たとえば、200 日経過しても読まれていないメッセージを削除するという指定はできません。

自動メッセージ削除ポリシーの例

例 1: 1,000 件を超えるメッセージが存在するフォルダ内の、存続期間が 365 日のメッセージをすべて削除します。

例 2: ドメイン siroe.com 内の、存続期間が 180 日を超えるメッセージを削除します。

例 3: 「削除済み」のマークが付いているメッセージをすべて削除します。

例 4: sesta.com 内の 1,000 件を超えるメッセージが存在するフォルダから、「開封済み」マークが付いていて、存続期間が 30 日より長く、サイズが 100K バイトより大きく、X-spam というヘッダーが付いたメッセージを削除します。

20.9.2.2 自動メッセージ削除ポリシーを実装するルールを設定する

前の節で定義した自動メッセージ削除ポリシーを実装するには、imexpire ルールを設定する必要があります。ルールを設定するには、ルールを store.expirerule ファイルに追加します。2 つの store.expirerule グローバルルールの例を次に示します。

Rule1.regexp: 1
Rule1.folderpattern: user/.*/trash
Rule1.messagedays: 2
Rule2:regexp: 1
Rule2.folderpattern: user/.*
Rule2.messagedays: 14

            

この例では、Rule 1 でごみ箱フォルダ内のすべてのメッセージが 2 日後に削除されることを指定しています。Rule 2 ではメッセージストアのすべてのメッセージが 14 日後に削除されることを指定しています。

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

• 「有効期間ルールのガイドライン」

• 「imexpire ルールをテキストモードで設定する」

• 「imexpire フォルダパターンを設定する」

有効期間ルールのガイドライン

この節では、store.expirerule ファイルルールのガイドラインを示します。

以前のリリースの Messaging Server では、有効期限ルールは、configutil パラメータの store.expirerule.attribute で設定できました (『Sun Java System Messaging Server 6.3 Administration Reference』の「configutil Parameters」を参照)。このリリースでもこれは引き続き可能ですが、ヘッダーの制約を使用した有効期限ルール (特定の件名でメッセージの有効期限が切れるなど) はサポートされません。いずれの場合でも、store.expirerule を使用してすべての有効期限ルールを指定することをお勧めします。

• ルールは、store.expirerule というファイルに指定されます。

• 同一のルールで複数の有効期限条件が指定できます。(上記の例を参照。)

• ルールはメッセージストア全体に適用でき (グローバルルール)、パーティション、ユーザー、フォルダごとにも適用できます。

  • グローバルルールは msg-svr-base/config/store.expirerule に保存されます。

    ---

    注 –

    各グローバルルールがすべてのメールボックスについてチェックされるため、指定するグローバルルールの数によっては、処理のオーバーヘッドが発生することがあります。このため、グローバルルールのファイルには、パーティション、メールボックス、またはユーザーのルールを指定しないでください。一般に、このファイルには必要最小限の有効期限ルールを指定するようにしてください。

    ---

  • パーティションルールは store_root /partition/partition_name/store.expirerule に保存されます。

  • ユーザールールは、store_root/partition/partition_name/userid/store.expirerule にルールを指定するか、folderpattern ルールを user/userid/.* となるように指定して作成できます。

  • フォルダルールは、store_root/partition/partition_name/userid/folder/store.expirerule にルールを指定するか、folderpattern ルールを user/userid/folder となるように指定して作成できます。

  • rule_name を使用するグローバルでない複数のルール (ユーザー、フォルダ、パーティション) は、Messaging Server 6.2p4 リリース以降でのみ実装されたことに注意してください。

• 複数の有効期限ルールが同時に 1 つのメールボックスに適用できます。メールボックスに対する有効期限ポリシーは、グローバルルールとローカルルールで構成されます。ローカルルールは同一ディレクトリのメールボックスおよびそのサブフォルダのすべてに適用されます。

• メールボックスに排他的なルールが指定されていないかぎり、imexpire によって、そのメールボックスに適用されているすべての有効期限ルールが結合されます (表 20–8 を参照)。その結果、ルールセットには、すべての適用可能なルールの中からもっとも制約度の高い有効期限ポリシーが採用されます。たとえば、メッセージの最長存続期間がルール X によって 10 日間、ルール Y によって 5 日間と指定されている場合、結合結果は 5 日間となります。

ローカライズされたメールボックス名

IMAP プロトコルでは、メールボックス名に modified UTF-7 形式のエンコーディングを使用するように規定されています。Messaging Server は、メールボックス名をローカライズできるように、外部インタフェース上のローカライズされた文字セットをサポートします。ただし、システムの内部ではローカライズされた名前が UTF-7 に変換されるため、クライアント上でローカライズされたメールボックス名を持つフォルダには、それに対応する UTF-7 形式のメールボックスファイル名が設定されます。(IMAP のエラーメッセージでは、ローカライズされた文字セットではなく、UTF-7 形式でメールボックス名が出力されます。)

一般に、メールボックス名を必要とするほとんどのメッセージストアユーティリティーでは、ローカライズされた文字セットによるメールボックス名が想定されていますが、異なる文字セットを使用できるようにするオプションフラグが用意されている場合もあります。これらのユーティリティーには、reconstruct、mboxutil、imsbackup、imsrestore、hashdir などがあります。ただし、imexpire では、folderpattern 属性として指定するメールボックス名を UTF-7 形式にする必要があります。ローカライズされた名前を使用すると機能しません。

imexpire に使用する適切な folderpattern を取得するには、ローカライズされたメールボックス名を modified UTF-7 形式に変換する必要がある場合があります。この作業は、次のように mboxutil -E コマンドを使用して行います。

1 つ目の mboxutil では、ローカライズされたファイル名が表示されています。2 つ目の mboxutil では、modified UTF-7 形式のファイル名が表示されています。次のように、IMAP の list コマンドを使用することもできます。

imexpire ルールをテキストモードで設定する

自動メッセージ削除ルールは、store.expirerule ファイルにルールを指定することによって設定します。store.expirerule ファイルは、1 行につき 1 つの有効期限条件を含みます。グローバルルール設定ファイル (msg-svr-base/data/store/store.expirerule) の有効期限条件は、次の形式になっています。

rule_name.attribute : value

ユーザーまたはメールボックスのルール設定ファイルの有効期限ルールは、次の形式になっています。

attribute: value

例 20–4 に、msg-svr-base/config/store.expirerule の一連のグローバル有効期限ルールを示します。

Rule 1 では、グローバル有効期限ポリシー (すべてのメッセージに適用されるポリシー) を設定しています。設定内容は次のとおりです。

• UNIX 正規表現をルール作成において有効にします。

• 100,000 バイトよりも大きいメッセージを 3 日後に削除します。

• ユーザーによって削除済みとされたメッセージを削除します。

• 「Viagra Now!」または「XXX Porn!」という文字列が Subject: ヘッダーにあるメッセージをすべて削除します。

• すべてのフォルダのメッセージ数を 1,000 件までに制限します。1,000 件を超えた場合、フォルダ内でもっとも古いメッセージを削除して合計件数を 1,000 以内に維持します。

• 存続期間が 365 日よりも長いメッセージをすべて削除します。

Rule 2 では、ホストしているドメインが siroe.com のユーザーに対して自動メッセージ削除ポリシーを設定しています。メールボックスサイズを 1M バイトに制限し、削除済みメッセージを削除し、存続期間が 14 日より長いメッセージを削除します。

Rule 3 では、ユーザー f.dostoevski の inbox フォルダに対して自動メッセージ削除ポリシーを設定しています。「On-line Casino」という件名行のあるメッセージを削除します 。

例 20–4 imexpire ルールの例

Rule1.regexp: 1
Rule1.folderpattern: user/.*
Rule1.messagesize: 100000
Rule1.messagesizedays: 3
Rule1.deleted: or
Rule1.Subject: Vigara Now!
Rule1.Subject: XXX Porn!
Rule1.messagecount: 1000
Rule1.messagedays: 365
Rule2.regexp: 1
Rule2.folderpattern: user/.*@siroe.com/.*Rule2.exclusive: 1
Rule2.deleted: or
Rule2.messagedays: 14
Rule2.messagecount: 1000
Rule3.folderpattern: user/f.dostoevski/inboxRule3.Subject: *On-line Casino*
                  

imexpire フォルダパターンを設定する

フォルダパターンは POSIX 正規表現を使用して指定できます。このためには、imexpire 属性の regex を 1 に設定します。この属性を指定しないと、IMAP 表現が使用されます。この形式は user/ で始まり、そのあとにパターンが続きます。表 20–9 に、各種フォルダのフォルダパターンを示します。

20.9.2.3 自動メッセージ削除とログレベルをスケジュールする

自動メッセージ削除は、imsched スケジューリングデーモンによってアクティブになります。デフォルトでは、imsched は毎日 23:00 に imexpire を呼び出し、メッセージは消去および消去されます。このスケジュールは、configutil パラメータの local.schedule.expire および store.cleanupage を設定することによってカスタマイズできます。表 20–10 を参照してください。

有効期限および消去は、大きなメッセージストアでは完了するまでに時間のかかることがあるので、これらのプロセスの実行頻度は実験して決定することをお勧めします。たとえば、有効期限および消去の 1 サイクルに 10 時間かかる場合、有効期限および消去のデフォルトスケジュールを 1 日に 1 回とするわけにはいきません。有効期限および消去をスケジュールするには、imexpire コマンドと自動タスクスケジューリングパラメータ (「4.6 自動タスクをスケジュールする」を参照) を使用します。次に例を示します。

configutil -o local.schedule.expire -v "0 1 * * 6 /opt/SUNWmsgsr/sbin/imexpire -e"
configutil -o local.schedule.mspurge -v "0 23 * * * /opt/SUNWmsgsr/sbin/imexpire -c"

この例では、メッセージが毎週日曜日の午前 1 時に有効期限切れになり、毎日午後 11 時に消去されます。消去のスケジュールを設定しなかった場合、imexpire は有効期限切れ後に消去を実行します。

imexpire ログレベルを設定する

imexpire が完了すると、デフォルトのログファイルに要約が記録されます。有効期限をコマンド行から呼び出す場合は、-v (詳細) および -d (デバッグ) の各オプションを使用して、詳細ステータスまたはデバッグメッセージを stderr に記録するように imexpire に指示できます。imsched を使用して imexpire を呼び出す場合は、configutil パラメータの local.store.expire.loglevel を 1、2、または 3 に設定して各ログレベルを選択できます。Loglevel 1 はデフォルトで、有効期限セッション全体の要約が記録されます。Loglevel 2 では、有効期限切れのメールボックスごとに 1 つのメッセージが記録されます。Loglevel 3 では、有効期限切れのメッセージごとに 1 つのメッセージが記録されます。

自動メッセージ削除から指定されたユーザーを除外する

msg-svr-base/config/ 内の expire_exclude_list ファイルで、1 行に 1 つずつユーザー ID を追加して、指定したユーザーを有効期限ルールから除外できます。または、ユーザーのメールボックスの下に、ダミーの排他的な有効期限ルールを設定します。

20.10 メッセージストアのパーティションを構成する

メッセージストアパーティションとは、ディスクパーティション上の、メッセージストアを格納するための専用エリアです。メッセージストアパーティションはディスクパーティションと同じではありませんが、管理の便宜をはかるために、各メッセージストアパーティション用に 1 つのディスクパーティションと 1 つのファイルシステムを使用することをお勧めします。メッセージストアパーティションは、メッセージストアとして特に指定されたディレクトリです。

デフォルトでは、ユーザーメールボックスは store_root/partition/ ディレクトリに保存されています (「20.2 メッセージストアのディレクトリレイアウト」を参照)。partition ディレクトリは、単一または複数のパーティションを格納している論理的なディレクトリです。起動時には、partition ディレクトリに primary パーティションと呼ばれるサブパーティションが格納されています。

必要に応じて partition ディレクトリにパーティションを追加できます。たとえば、ユーザーを体系化するために 1 つのディスクを分割する場合、次のようになります。

store_root/partition/mkting/
store_root/partition/eng/
store_root/partition/sales/

ディスクストレージに対する要求が高まるに従い、これらのパーティションを異なる物理ディスクドライブにマッピングする必要が生じてくると考えられます。

どのディスクでもメールボックスの数を制限しなければなりません。メールボックスを複数のディスクに分散させることにより、メッセージ配信時間を短縮することができます。ただし、必ずしも SMTP の受け入れ率が変更されるわけではありません。ディスクごとに割り当てるメールボックスの数は、ディスク容量や各ユーザーに割り当てられたディスク容量によって異なります。たとえば、ユーザーごとのディスク容量の割り当て量が少ない場合は、ディスクごとに割り当てるメールボックスの数を多くできます。

メッセージストアに複数のディスクを必要とする場合、RAID (Redundant Array of Inexpensive Disks) 技術を使用すれば複数ディスクの管理を容易に行うことができます。RAID 技術によってデータを一連のディスクに分散させることができます。このときディスクは単一の論理ボリュームとして表示されるので、ディスク管理が簡単になります。また、冗長性を得るために RAID 技術を使用することもできます。つまり、障害復旧用にストアを複製する目的で使用することができるわけです。

ディスクアクセスを向上させるには、メッセージストアとメッセージキューを別のディスクに配置しておく必要があります。

20.10.1 パーティションを追加する

パーティションを追加する場合、ディスク上でパーティションが保存されている場所の絶対的な物理パスと、パーティションニックネームと呼ばれる論理名を指定します。

パーティションニックネームにより、物理パスに関係なくユーザーを論理的なパーティション名にマッピングさせることができます。ユーザーアカウントの設定時やユーザーのメッセージストアを指定するときに、パーティションニックネームを使用できます。名前の入力に使用するのは英数字で、アルファベットは小文字を使用してください。

パーティションを作成および管理するには、サーバーの実行に使用するユーザー ID が、物理パスで指定した場所への書き込み権限を持っていなければなりません。

パーティションを追加したら、構成情報を更新するためにサーバーをいったん停止してから再起動する必要があります。

メッセージストアパーティションを追加する

1. コマンド行: コマンド行でストアにパーティションを追加する場合は、次のようになります。

   configutil -o store.partition. nickname.path -v path

   ここで、nickname はパーティションの論理名、path はパーティションが保存されている場所の絶対パス名を示しています。

   デフォルトのプライマリパーティションのパスは次のように指定します。

   configutil -o store.partition.primary.path -v path

20.10.2 メールボックスを別のディスクパーティションに移動する

特に設定を変更しないかぎり、メールボックスは primary パーティション内に作成されます。このパーティションの容量が一杯になると、メッセージを保存することができなくなります。この問題を解決するには、次の方法があります。

• ユーザーのメールボックスのサイズを縮小する

• ボリューム管理ソフトウェアを使用している場合、別のディスクを追加する

• 別のパーティションを作成し (「20.10.1 パーティションを追加する」)、メールボックスを新しいパーティションに移動する

可能なかぎり、容量管理ソフトを使用して、システムにディスク容量を追加する方法をお勧めします。これは、この方法がユーザーにとってもっとも透過性が高いからです。ただし、次の手順に従って、メールボックスを別のパーティションに移動することもできます。

メールボックスを別のディスクパーティションに移動する

1. 移行プロセス中は、ユーザーがメールボックスに接続していない状態にしてください。このためには、ユーザーに通知を出して、メールボックスの移動作業を行う前にログオフし、作業期間中にログオンしないように指示します。または、ユーザーがログオフしたあと、POP、IMAP、および HTTP のサービスを使用できないように mailAllowedServiceAccess 属性を設定します。『Sun Java Communications Suite 5 Schema Reference』の「mailAllowedServiceAccess」を参照してください。

   ---

   注 –

   POP、IMAP、HTTP へのアクセスを許可しないように mailAllowedServiceAccess を設定しても、ユーザーがすでにメールボックスに接続している場合に、その接続が切断されることはありません。このため、メールボックスを移動する前に、すべての接続が切断されていることを確認してください。

   ---

2. ユーザーのメールボックスを移動するには、次のコマンドを使用します。

   mboxutil -r user/<userid>/INBOX user/< userid>/INBOX <partition_name>

   例:

   mboxutil -r user/ofanning/INBOX user/ofanning/INBOX secondary

3. 移動したユーザーの LDAP エントリで mailMessageStore 属性を新しいパーティションの名前に設定します。

   例: mailMessageStore: secondary

4. ユーザーにメッセージストアへの接続が再開されたことを通知します。必要に応じて、POP、IMAP、および HTTP サービスを使用できるように mailAllowedServiceAccess 属性を変更します。

20.10.3 デフォルトのメッセージストアパーティション定義の変更

デフォルトのパーティションとは、ユーザーが作成されたときに、ユーザーエントリに mailMessageStore LDAP 属性が指定されなかった場合に使用されるパーティションのことです。デフォルトのパーティションが必要にならないように、すべてのユーザーエントリにユーザーのメッセージストアパーティションを指定する mailMessageStore LDAP 属性を指定してください。さらに、デフォルトのパーティションを負荷分散やその他の理由で変更してはなりません。デフォルトのパーティションの定義に依存するユーザーが存在する間に、デフォルトのパーティションを変更するのは無効であり危険です。

デフォルトのパーティションをどうしても変更する必要がある場合は、configutil パラメータの store.defaultpartition でデフォルトの定義を変更する前に、古いデフォルトのパーティションのすべてのユーザー (そのままになっていたユーザー) の mailMessageStore 属性が現在のパーティション (これはデフォルトでなくなる) に設定されているようにしてください。

20.11 メッセージストアの保守手順を実行する

この節では、メッセージストアの保守タスクと回復タスクを実行するのに使用するユーティリティーについて説明します。サーバーから送信される警告のためのポストマスターメールを常に読む必要があります。また、サーバーの実行状況に関する情報を記録したログファイルを監視する必要もあります。ログファイルの詳細については、第 25 章「ログの管理」を参照してください。

この節では次の内容について説明します。

• 「20.11.1 メッセージストアへの物理ディスクの追加」

• 「20.11.2 メールボックスを管理する」

• 「20.11.3 メールボックスの最大サイズ」

• 「20.11.4 制限容量を監視する」

• 「20.11.5 ディスク容量を監視する」

• 「20.11.6 stored デーモン」

• 「20.11.7 同一メッセージのストレージが重複するためメッセージストアのサイズを小さくする」

20.11.1 メッセージストアへの物理ディスクの追加

Messaging Server メッセージストアには、特定の Messaging Server インスタンス用のユーザーメールボックスが格納されています。メッセージストアのサイズは、メールボックス、フォルダ、およびログファイルの数が増えるに従って増大していきます。

システムにユーザーを追加していくに従い、ディスクストレージ要件も増えていきます。サーバーがサポートするユーザー数によって、メッセージストアに必要な物理ディスクが 1 つであるか、複数であるかが決まります。Messaging Server では、必要に応じてストアを追加できます。ストアを追加するための 1 つの方法は、ストレージ機器を使用することです。Messaging Server で Network Appliance ストレージ機器を設定する方法については、『』を参照してください。

20.11.2 メールボックスを管理する

この節では、メールボックスの管理および監視を行う次のユーティリティーについて説明します。 mboxutil、hashdir、readership。

20.11.2.1 mboxutil ユーティリティー

メールボックスの一般的な保守タスクを実行する場合は、mboxutil コマンドを使用します。mboxutil で実行できるタスクは次のとおりです。

• メールボックスの一覧表示

• 孤立メールボックスおよび非アクティブメールボックスの一覧表示と削除

• メールボックスの作成

• メールボックスの名前変更

• パーティション間のメールボックスの移動

• メールボックスの削除

• まだ消去されていない削除済みメッセージの復元

• 個人メールボックス登録と存在しない未登録メールボックスの一覧表示

• また、mboxutil コマンドを使用して制限容量に関する情報を表示することもできます。詳細については、「20.11.4 制限容量を監視する」を参照してください。

mboxutil プロセスを実行途中で強制終了しないでください。SIGKILL (kill -9) で強制終了すると、各サーバーを再起動し、回復処理を行わなければならないことがあります。

構文の詳細と使用の要件については、『Sun Java System Messaging Server 6.3 Administration Reference』の「mboxutil」を参照してください。

例

全ユーザーの全メールボックスを一覧表示するには、次のように入力します。

mboxutil -l

すべてのメールボックスを、パスと ACL の情報とともに一覧表示するには、次のように入力します。

mboxutil -l -x

ユーザー daphne に対し、INBOX というデフォルトのメールボックスを作成するには、次のように入力します。

mboxutil -c user/daphne/INBOX

ユーザー delilah に対し、projx という名前のメールフォルダを削除するには、次のように入力します。

mboxutil -d user/delilah/projx

ユーザー druscilla について、INBOX というデフォルトのメールボックスとすべてのメールフォルダを削除するには、次のように入力します。

mboxutil -d user/druscilla/INBOX

ユーザー desdemona の memos というメールフォルダの名前を、memos-april という名前に変更するには、次のように入力します。

mboxutil -r user/desdemona/memos user/desdemona/memos-april

ユーザー dimitria のメールアカウントを新しいパーティションに移動するには、次のように入力します。

mboxutil -r user/dimitria/INBOX user/dimitria/INBOX partition

この場合、partition には新しいパーティションの名前を指定します。

ユーザー dimitria のメールフォルダ personal を新しいパーティションに移動するには、次のように入力します。

mboxutil -r user/dimitria/personal user/dimitria/personal partition

20.11.2.2 孤立アカウントを削除する

孤立アカウント (対応するエントリが LDAP にないメールボックス) を検索するには、次のコマンドを使用します。

mboxutil -o

コマンド出力が次のように続きます。

  mboxutil: Start checking for orphaned mailboxes
  user/annie/INBOX
  user/oliver/INBOX
  mboxutil: Found 2 orphaned mailbox(es)
  mboxutil: Done checking for orphaned mailboxes

次のコマンドで作成したファイルは、孤立メールボックスを削除するスクリプトファイルにすることができます。この例では、ファイル名は orphans.cmd です。

mboxutil -o -w orphans.cmd

コマンド出力は次のとおりです。

  mboxutil: Start checking for orphaned mailboxes
  mboxutil: Found 2 orphaned mailbox(es)
  mboxutil: Done checking for orphaned mailboxes

次のコマンドを使用して孤立したファイルを削除します。

mboxutil -d -f orphans.cmd

20.11.2.3 hashdir ユーティリティー

メッセージストア内のメールボックスは、高速で検索できるようにハッシュ構造で保存されています。したがって、特定のユーザーのメールボックスを格納するディレクトリを検索するには、hashdir ユーティリティーを使用します。

このユーティリティーは、特定のアカウントのメッセージストアを含むディレクトリを識別します。また、メッセージストアへの相対パス (d1/a7/ など) をレポートします。このパスは、ユーザー ID に基づくディレクトリの 1 つ上のディレクトリレベルを基準にしたものです。このユーティリティーによってパス情報が標準出力に送られます。

たとえば、ユーザー crowe のメールボックスへの相対パスを検索する場合は次のようになります。

hashdir crowe

20.11.2.4 readership ユーティリティー

readership ユーティリティーは、メールボックスの所有者以外に、何人のユーザーが共有 IMAP フォルダ内のメッセージを読んだかを報告するユーティリティーです。

IMAP フォルダの所有者は、フォルダ内のメールを読む権限をほかのユーザーに与えることができます。ほかのユーザーにアクセス権が与えられたフォルダは、「共有フォルダ」と呼ばれます。管理者は readership ユーティリティーを使用して、所有者以外に何人のユーザーが共有フォルダにアクセスしたかを表示することができます。

このユーティリティーは、すべてのメールボックスをスキャンして、各共有フォルダにつき 1 行ずつ、アクセスしたユーザー数とメールボックスの名前を表示させます。ユーザー数とメールボックスの名前の間にはスペースが挿入されます。

アクセスしたユーザーとは、過去の指定した日数内に共有フォルダを選択した、個別の認証を受けたユーザーのことです。自分の個人用メールボックスを読んだユーザーは、数には含められません。個人用メールボックスは、フォルダの所有者以外に購読者がいない場合は報告されません。

たとえば次のコマンドでは、最近の 15 日以内に共有の IMAP フォルダを選択したユーザーをすべてカウントします。

readership -d 15

20.11.3 メールボックスの最大サイズ

メールボックスの最大サイズは、およそ 100 万メッセージです。このサイズを超えると、ユーザーへのメッセージ配信が停止され、メッセージストアのパフォーマンスの問題が発生します。詳細は、「20.14.4.7 メールボックスのオーバーフローによりユーザーメールが配信されない」を参照してください。

20.11.4 制限容量を監視する

imqutoacheck ユーティリティーを使って、制限容量の使用状況と制限を監視します。このユーティリティーは、定義された制限容量を一覧表示し、制限容量の使用状況に関する情報を提供するレポートを生成します。制限容量と使用状況に関する数値は、K バイトでレポートされます。また、このユーティリティーでメールボックスのサイズとユーザーに割り当てられた制限容量を比較することもできます。オプションとして、制限容量に対し一定の割合を超えたユーザーに対し、電子メールによる通知を送信することができます。

imquotacheck のいくつかの機能が変更されました。Messaging Server 6.x では、quotacheck ユーティリティーが imquotacheck に替わりました。Messaging Server 5.x では、ユーザーのリストを取得するために quotacheck ユーティリティーを使用すると、quotacheck はローカル mboxlist データベースを検索しました。この機能は、mboxutil ユーティリティーの検索機能と重複します。

Messaging Server 6.x では、この重複機能が imquotacheck ユーティリティーから削除されました。imquotacheck でユーザーの検索を実行する場合、検索はローカルの mboxlist データベースではなく、LDAP ディレクトリに対して行われます。ローカル mboxlist データベースからユーザーのリストを取得するには、mboxutil ユーティリティーを使用します。

制限容量がルールファイルの最小しきい値を超えるすべてのユーザーの使用状況を一覧表示するには、次のように入力します。

imquotacheck

ドメイン siroe.com の制限容量に関する情報を一覧表示します。

imquotacheck -d siroe.com

デフォルトのルールファイルにしたがって、すべてのユーザーに通知を送信するには、次のように入力します。

imquotacheck -n

指定したルールファイル myrulefile と指定したメールテンプレートファイル mytemplate.file にしたがって、すべてのユーザーに通知を送信するには、次のように入力します (詳細については、『Sun Java System Messaging Server 6.3 Administration Reference』の「imquotacheck」を参照)。

imquotacheck -n -r myrulefile -t mytemplate.file

ルールファイルを無視して、すべてのユーザーの使用状況を一覧表示するには、次のように入力します。

imquotacheck -i

user1 のフォルダ使用状況別に一覧表示するには (ルールファイルを無視)、次のように入力します。

imquotacheck -u user1 -e

20.11.5 ディスク容量を監視する

システムがディスク容量やパーティションの使用状況を監視する頻度と、システムが警告を送信する環境条件を指定することができます。詳細は、「27.3.2 ディスク容量を監視する」を参照してください。

20.11.6 stored デーモン

stored デーモンは、次の保守タスクをメッセージストアに対して実行します。

• チェックポイントデータベーストランザクションの実行。

• デッドロックの検出とデッドロックしたデータベーストランザクションのロールバック。

• 起動時の一時ファイルとロックファイルのクリーンアップ。

• データベーススナップショットアーカイブの作成。

• 必要に応じたデータベース回復 (「20.14.2 メッセージストアの起動と回復」を参照)。

サーバーのいずれかのデーモンがクラッシュした場合は、すべてのデーモンを停止させ、stored を含むすべてのデーモンを再起動しなくてはなりません。

20.11.7 同一メッセージのストレージが重複するためメッセージストアのサイズを小さくする

1 つのメッセージが複数の受取人に送信されると、そのメッセージは各受取人のメールボックスに格納されます。一部のメッセージングシステムでは、同じメッセージのそれぞれのコピーを各受取人のメールボックスに格納します。それに対して、Sun Java System Messaging Server では、そのメッセージが格納されているメールボックスの数に関係なく、メッセージのコピーを 1 つだけ保持するよう努めます。このために、そのメッセージが含まれているメールボックス内にそのメッセージへのハードリンクを作成します。

ほかのメッセージングシステムが Sun Java Messaging Server に移行されると、移行プロセスによってメッセージの複数のメッセージコピーが作成されることがあります。メッセージストアが大きい場合、大量のメッセージが不必要に重複することになります。また、IMAP append 操作やほかのソースからなど、通常のサーバー操作で同じメッセージの複数のコピーが蓄積される可能性もあります。

Messaging Server には、余分のメッセージコピーを削除し、それらを 1 つのコピーへのハードリンクに置き換える relinker という新しいコマンドが用意されています。

20.11.7.1 Relinker の動作方式

再リンク機能は、コマンド行モードでもリアルタイムモードでも実行できます。relinker コマンドを実行すると、メッセージストアのパーティション全体がスキャンされ、MD5 メッセージダイジェストリポジトリがハードリンクとして作成または更新され、余分のメッセージファイルが削除されて、必要なハードリンクが作成されます。

ダイジェストリポジトリは、メッセージストアに格納されているメッセージへのハードリンクから構成されます。このリポジトリは、ディレクトリ階層 partition_path/=md5 に格納されます。このディレクトリは、ユーザーメールボックスの階層 partition_path/=user に対応しています (図 20–1 を参照)。ダイジェストリポジトリのメッセージは、その MD5 ダイジェストによって一意に識別されます。たとえば、fredb/00/1.msg のダイジェストが 4F92E5673E091B43415FFFA05D2E47 である場合、partition/=user/hashdir/hashdir/=fredb/00/1.msg は partition/=md5/hashdir/hashdir/4F92E5673E091B43415FFFA05D2E47EA.msg にリンクされます。別のメールボックスに同じメッセージ (partition_path /=user/hashdir/hashdir/gregk/00/17.msg など) があると、そのメッセージもまた partition_path/=md5/4F/92/4F92E5673E091B43415FFFA05D2E47EA.msg にハードリンクされます。図 20–4 はこのことを示しています。

図 20–4 メッセージストアのダイジェストリポジトリ

このメッセージの場合、リンクカウントは 3 になります。両方のメッセージが fredb および gregk というメールボックスから削除されると、リンクカウントは 1 になり、メッセージを消去できます。

relinker プロセスは、リアルタイムモードで実行しても同じように機能します。詳細については、「20.11.7.3 リアルタイムモードで relinker を使用する」を参照してください。

20.11.7.2 コマンド行モードで relinker を使用する

relinker は、メッセージストアのパーティション全体をスキャンし、MD5 メッセージリポジトリをハードリンクとして作成または更新して、余分のメッセージファイルを削除します。relinker がストアパーティションをスキャンし終わると、再リンク前後の一意のメッセージ数とパーティションのサイズに関する統計情報が出力されます。すでにハッシュされているストアを迅速に処理するために、relinker は =md5 にまだ存在しないメッセージのダイジェストだけを計算します。また、ダイジェストリポジトリ全体を消去することもできます (ユーザーメールボックスに影響しない場合)。

コマンドの構文は次のとおりです。

relinker [-p partitionname] [-d]

ここで、partitionname は処理されるパーティション (デフォルト: すべてのパーティション) を示し、-d はダイジェストリポジトリが削除されること示します。出力例を次に示します。

# relinker

Processing partition: primary
Scanning digest repository...
Processing user directories..............................
---------------------------------------------------------
Partition statistics           Before            After 
---------------------------------------------------------
Total messages                 4531898         4531898
Unique messages                4327531         3847029
Message digests in repository        0         3847029
Space used                       99210Mb         90481Mb
Space savings from single-copy    3911Mb         12640Mb
---------------------------------------------------------


# relinker -d 
Processing partition: primary
Purging digest repository...
---------------------------------------------------------
Partition statistics                 Before         After
---------------------------------------------------------
Message digests in repository       3847029             0
---------------------------------------------------------

relinker は、特にリポジトリにメッセージがまったく存在しない場合の最初の実行は、時間がかかることがあります。これは、すべてのメッセージのダイジェストを計算しなければならないためです (relinker 条件がすべてのメッセージを含めるように設定されている場合)。relinker 条件の設定については、「20.11.7.4 relinker を設定する」を参照してください。たとえば、100G バイトのメッセージストアを処理するのに 6 時間を要するとします。ただし、実行時再リンクが有効になっている (「20.11.7.3 リアルタイムモードで relinker を使用する」を参照) 場合は、relinker コマンドを実行する必要はありません。

relinker コマンド行モードが排他的に使用され、実行時オプションが有効でない場合は、ダイジェストリポジトリ (=md5) を消去する必要があります。そうしないと、ストア (=user) 内に消去されたメッセージがダイジェストリポジトリ内にリンクを持ち続ける (孤立する) ため、それらのディスク領域が解放されません。移行後などにストアの最適化を 1 回だけ行なっている場合は、relinker を一度実行してから、relinker -d でリポジトリ全体を削除できます。移行中に消去を何度も行なった場合は、実行するたびに期限切れや孤立したメッセージがリポジトリから消去されるので、relinker コマンドを繰り返し実行するだけで十分です。

異なるパーティションの各処理と並行して、relinker の複数のインスタンスを実行しておくと安全です (-p オプションを使用)。メッセージは同じパーティション内でのみ再リンクされます。

20.11.7.3 リアルタイムモードで relinker を使用する

リアルタイムモードで relinker 機能を有効にするには、configutil パラメータの local.store.relinker.enabled を yes に設定します。リアルタイムモードで relinker を使用すると、設定された relinker 条件 (「20.11.7.4 relinker を設定する」を参照) に一致する、配信された (または復元された、IMAP によって追加された、など) すべてメッセージのダイジェストが計算され、そのダイジェストがリポジトリにすでに存在するかどうかが確認されます。ダイジェストが存在する場合は、メッセージの新しいコピーを作成する代わりに、そのダイジェストへのリンクが宛先メールボックスに作成されます。ダイジェストが存在しない場合は、メッセージが作成され、あとでそのメッセージへのリンクがリポジトリに追加されます。

stored は、各パーティションのダイジェストリポジトリをスキャンし、リンクカウントが 1 か、relinker 条件に一致しないメッセージを消去します。スキャンは、設定可能な期間内に一度に 1 つのディレクトリで実行されます。これは、入出力負荷が均等に分散され、ほかのサーバー操作に著しい影響を及ぼさないようにするためです。デフォルトでは、消去サイクルは 24 時間です。これは、メッセージがストアから削除されるか、設定可能な最長保存期間を過ぎたあとも、24 時間までは存在するということを意味します。このタスクは、relinker のリアルタイムモードが有効になっている場合にのみ使用できます。

20.11.7.4 relinker を設定する

表 20–11 に、relinker 条件を設定するためのパラメータを示します。

20.12 メッセージストアのバックアップと復元を行う

メッセージストアのバックアップと復元は、もっとも一般的で重要な管理タスクです。メッセージストアのすべてのメッセージとフォルダのバックアップを行います。メッセージストアにバックアップと復元のポリシーを実装して、次のような問題が発生した場合でも、データが失われないようにしておかなければなりません。

• システムのクラッシュ

• ハードウェア障害

• 過失によるメッセージまたはメールボックスの削除

• システムをインストールし直したりアップグレードするときの問題

• 天災 (地震、火事、台風など)

• ユーザーの移行

コマンド行ユーティリティーの imsbackup と imsrestore を使用するか、Legato Networker^TM が採用された統合ソリューションを使用してメッセージストアのバックアップと復元を行うことができます。

Messaging Server は、単一コピーによるバックアップ手順を提供しています。特定のメッセージを格納するユーザーフォルダがいくつあるかにかかわらず、バックアップ時には、メッセージファイルは最初に見つかったメッセージファイルを使用して 1 度バックアップされるだけです。2 つ目のメッセージコピーは、1 つ目のメッセージファイルの名前へのリンクとしてバックアップされます。以降も同様です。 imsbackup は、メッセージファイルのデバイスや inode をインデックスとして使用してすべてのメッセージのハッシュテーブルを保守します。ただし、この方法を採用する場合はデータの復元時に注意が必要です。詳細については、「20.12.5 部分的な復元に関する考察」を参照してください。

メッセージストアのバックアップと復元は、すべてのメッセージファイルとディレクトリをバックアップする方法でも行うことができます。詳細については、「20.12.9 メッセージストアの災害時のバックアップと復元」を参照してください。

ここで説明する内容は、次のとおりです。

• 「20.12.1 メールボックスバックアップポリシーの作成」

• 「20.12.2 バックアップグループを作成する」

• 「20.12.3 Messaging Server のバックアップと復元のユーティリティー」

• 「20.12.4 バックアップ実行時の多数宛メールの除外」

• 「20.12.5 部分的な復元に関する考察」

• 「20.12.6 Legato Networker を使用する」

• 「20.12.7 サードパーティーのバックアップソフトウェア (Legato 以外) を使用する」

• 「20.12.8 バックアップおよび復元の問題のトラブルシューティング」

• 「20.12.9 メッセージストアの災害時のバックアップと復元」

20.12.1 メールボックスバックアップポリシーの作成

バックアップポリシーは次のようないくつかの要素に依存しています。

• 「20.12.1.1 ビジネス負荷のピーク」

• 「20.12.1.2 フルバックアップと増分バックアップ」

• 「20.12.1.3 同時バックアップと順次バックアップ」

20.12.1.1 ビジネス負荷のピーク

システムのバックアップのスケジュールを設定する場合は、ビジネス負荷のピークを考慮に入れる必要があります。システムのバックアップによってピーク時のシステム負荷が減少することがあるからです。たとえば、バックアップは午前 2 時など早朝 (深夜) の時間帯にスケジュール設定するのが最善であると考えられます。

20.12.1.2 フルバックアップと増分バックアップ

増分バックアップ (「増分バックアップ」を参照) とは、ストアをスキャンして変更データを見つけ、変更分だけをバックアップする方法です。フルバックアップとは、メッセージストア全体をバックアップすることです。システムが増分バックアップに対してどのくらいの頻度でフルバックアップを実行するのかを決定する必要があります。増分バックアップを毎日の保守手順の中で実行し、フルバックアップを週に 1 度実行することをお勧めします。

20.12.1.3 同時バックアップと順次バックアップ

ユーザーのデータが複数のディスクに保存されている場合、必要に応じて複数のユーザーグループを同時にバックアップすることができます。システムリソースによっては、同時バックアップによってバックアップ手順全体の処理速度を向上させることができます。ただし、たとえばサーバーのパフォーマンスに影響を与えたくないような場合、順次バックアップを実行することもあります。同時バックアップを行うか順次バックアップを行うかは、システム負荷、ハードウェア構成、使用可能なテープドライブの数など、多くの要素によって決まります。

20.12.2 バックアップグループを作成する

バックアップグループは、正規表現で定義されたユーザーメールボックスの任意の集まりです。ユーザーメールボックスをバックアップグループに組織化することで、より柔軟なバックアップ管理を定義することができます。

たとえば、3 つのバックアップグループを作成し、第 1 のグループには A 〜 L で始まるユーザー ID を、第 2 のグループには M 〜 Z で始まるユーザー ID のユーザーを、第 3 のグループには ID が数字で始まるユーザーを含めます。管理者はこれらのバックアップグループを使用してメールボックスを同時にバックアップできます。または、ある日に一部のグループのみバックアップし、別の日にほかのグループをバックアップすることもできます。

バックアップグループについて注意すべき事項がいくつかあります。

1. バックアップグループはメールユーザーの任意の「仮想」グループです。これらは見かけとは異なり、メッセージストアディレクトリに正確にはマッピングされません (図 20–1)。

2. バックアップグループは、UNIX 正規表現を使用して管理者によって定義されます。

3. 正規表現は、設定ファイル msg-svr-base/config/backup-groups.conf で定義されています。

4. バックアップグループが imsbackup および imsrestore で参照された場合、次のパス形式が使用されます。/partition_name/backup_group

backup-groups.conf の形式は次のとおりです。

group_name=definition
group_name=definition
.
.
.

上記の例を使用して、次の 3 つの定義によるバックアップグループを作成するとします。

groupA=[a-l].*
groupB=[m,-z].*
groupC=[0-9].*

これで imsbackup および imsrestore をいくつかのレベルでスコープすることができます。次のバックアップコマンドを使用してメッセージストア全体をバックアップおよび復元することができます。

imsbackup -f device /

groupA の全ユーザー全メールボックスをバックアップするには、次のコマンドを使用します。

imsbackup -f device /partition/groupA

デフォルトのパーティションは primary です。

20.12.2.1 事前定義のバックアップグループ

Messaging Server には backup-groups 設定ファイルを作成しなくても使用することができる、事前定義のバックアップグループが含まれています。これは user という名前のグループで、ここにはすべてのユーザーが含まれています。たとえば、次のコマンドで primary パーティションのすべてのユーザーがバックアップされます。

imsbackup -f backupfile /primary/user

20.12.3 Messaging Server のバックアップと復元のユーティリティー

データのバックアップと復元のために、Messaging Server では imsbackup および imsrestore ユーティリティーが提供されています。ただし、imsbackup および imsrestore ユーティリティーは、Legato Networker のような汎用目的ツールに見られる高度な機能は備えていません。たとえば、これらのユーティリティーでは、テープのオートチェンジャーに対するサポートは非常に限定されています。また、複数の同時実行デバイスに単一のストアを書き込むことはできません。総合的なバックアップは、Legato Networker などの一般化ツールのプラグインを使用して達成することができます。Legato Networker の使用に関する詳細については、「20.12.6 Legato Networker を使用する」を参照してください。

20.12.3.1 imsbackup ユーティリティー

imsbackup ユーティリティーを使用すると、選択したメッセージストアの内容を、シリアルデバイス (磁気テープ、UNIX パイプ、通常のファイルなど) に書き込むことができます。バックアップの全体または一部は、あとから imsrestore ユーティリティーを使って回復できます。imsbackup の出力は、imsrestore に受け渡すことができます。

次の例では、メッセージストア全体を /dev/rmt/0 にバックアップします。

imsbackup -f /dev/rmt/0 /

次の例では、ユーザー ID joe のメールボックスが/dev/rmt/0 にバックアップされます。

imsbackup -f /dev/rmt/0 /primary/user/joe
            

次の例では、バックアップグループ groupA に定義された全ユーザーの全メールボックスが backupfile にバックアップされます (「20.12.2 バックアップグループを作成する」を参照)。

imsbackup -f- /primary/groupA > backupfile
            

増分バックアップ

次の例は、2004 年 5 月 1 日の午後 1 時 10 分から現在までに保存されたメッセージをバックアップします。デフォルトでは、日付に無関係にすべてのメッセージをバックアップします。

imsbackup -f /dev/rmt/0 -d 20040501:131000 /
               

このコマンドはデフォルトのブロック係数である 20 を使用します。imsbackup コマンドの完全な構文に関する説明は、『Sun Java System Messaging Server 6.3 Administration Reference』を参照してください。

20.12.3.2 imsrestore ユーティリティー

バックアップデバイスからメッセージを復元するには、imsrestore コマンドを使用してください。たとえば、次のコマンドは backupfile から user1 のメッセージを復元します。

imsrestore -f backupfile /primary/user1

imsbackup コマンドの完全な構文に関する説明は、『Sun Java System Messaging Server 6.3 Administration Reference』を参照してください。

20.12.4 バックアップ実行時の多数宛メールの除外

バックアップ操作の実行時には、バックアップから除外するメールボックスを指定できます。重要でないメッセージが多数発生する多数宛またはごみのメールボックスを除外して、バックアップセッションを合理化し、操作完了までの時間を短縮し、バックアップデータの格納に必要なディスク容量を最小限にできます。

メールボックスを除外するには、configutil パラメータの local.store.backup.exclude の値を指定します。

1 つのメールボックス、または「%」文字で区切ったメールボックスのリストを指定できます。「%」文字は、メールボックス名には使用できません。たとえば、次の値を指定できます。

Trash

Trash%Bulk Mail%Third Class Mail

最初の例では、フォルダ Trash が除外されます。2 番目の例では、フォルダ Trash、Bulk Mail、および Third Class Mail が除外されます。

バックアップユーティリティーは、local.store.backup.exclude パラメータに指定されたフォルダ以外のユーザーメールボックスのすべてのフォルダをバックアップします。

この機能は、Messaging Server バックアップユーティリティー、Legato Networker、およびサードパーティー製のバックアップソフトウェアと使用できます。

local.store.backup.exclude の設定を無効にし、バックアップ操作時に完全な論理名を指定して除外したメールボックスをバックアップできます。ごみ箱フォルダが除外されたとします。たとえば、次のように指定することにより、引き続きごみ箱をバックアップできます。

/primary/user/user1/trash

ただし、次のように指定すると、ごみ箱フォルダは除外されます。

/primary/user/user1

the Trash folder is excluded.

20.12.5 部分的な復元に関する考察

部分的な復元は、メッセージストアの一部を復元するときにのみ行われます。完全な復元は、メッセージストア全体を復元するときに行われます。メッセージストアでは単一コピーによるメッセージシステムが使用されています。つまり、メッセージの 1 つのコピーのみが 1 つのファイルとしてストアに保存されます。コピーされたメッセージのほかのインスタンス (メッセージが複数のメールボックスに送信される場合など) は、コピーへのリンクとして保存されます。このため、メッセージを復元する場合には注意が必要です。次に例を示します。

• 完全な復元: 完全な復元では、リンクの付いたメッセージは、依然としてリンク先のメッセージファイルと同じ inode をポイントしています。

• 部分的なバックアップおよび復元: 部分的なバックアップおよび部分的な復元では、メッセージストアの単一コピーの特性は保持されないことがあります。

次の例では、部分的な復元が実行された場合に、複数のユーザーによって使用されるメッセージに発生する事柄を示します。次のように、3 人のユーザー A、B、C に属する、まったく同じ 3 つのメッセージが存在すると仮定してみてください。

A/INBOX/1
B/INBOX/1
C/INBOX/1

例 1: 最初の例では、システムは部分的なバックアップと完全な復元を次のように実行します。

1. ユーザー B および C のメールボックスをバックアップします。

2. ユーザー B および C のメールボックスを削除します。

3. 手順 1 のバックアップデータを復元します。

この例では、B/INBOX/1 および C/INBOX/1 には新しい inode 番号が割り当てられ、メッセージデータはディスク上の新しい場所に書き込まれます。メッセージは 1 件だけ復元されます。2 件目のメッセージは最初のメッセージへのハードリンクです。

例 2: この例では、システムはフルバックアップと部分的な復元を次のように実行します。

1. フルバックアップを実行します。

2. ユーザー A のメールボックスを削除します。

3. ユーザー A のメールボックスを復元します。

A/INBOX/1 には新しい inode 番号が割り当てられます。

例 3: この例では、複数回の部分的な復元が必要となる可能性があります。

1. フルバックアップを実行します。

   B/INBOX/1 と C/INBOX/1 は A/INBOX/1 へのリンクとしてバックアップされます。

2. ユーザー A と B のメールボックスを削除します。

3. ユーザー B のメールボックスを復元します。

   復元ユーティリティーが、最初に A/INBOX を復元するよう管理者に要求します。

4. ユーザー A と B のメールボックスを復元します。

5. ユーザー A のメールボックスを削除します (任意)。

   ---

   注 –

   すべてのメッセージを部分的な復元で復元できるようにするためには、-i オプションを付けて imsbackup コマンドを実行します。-i オプションは必要に応じて各メッセージを複数回バックアップします。

   ドライブやテープなど、バックアップデバイスが検索可能である場合、imsrestore は A/INBOX/1 が格納されている位置を検索し、B/INBOX/1 として復元します。UNIX パイプなど、バックアップデバイスが検索不能である場合、imsrestore はオブジェクト ID とリンクされているオブジェクトの ID をファイルに記録します。管理者は -r オプションを使用して imsrestore を再び呼び出し、欠落しているメッセージ参照を復元する必要があります。

   ---

20.12.5.1 増分バックアップされたメールボックスからのメッセージを復元する

増分バックアップされたメールボックスからメッセージを復元する際に、そのメールボックスがメッセージを復元するサーバーに存在する場合は、imesrestore を実行するだけでメッセージを復元できます。ただし、増分バックアップされたメールボックスからメッセージを復元する際に、そのメールボックスがすでに存在しない場合は、別の復元手順に従う必要があります。

メッセージストアサーバーに存在しないメールボックスを復元するには、次の手順のいずれかを使用します。

• 復元操作時に、ユーザーへのメッセージの配信を停止します。このためには、LDAP 属性の mailDeliveryOption に hold を設定します。

• mboxutil -c コマンドでメールボックスを作成してから、imesrestore を使用します。

増分バックアップを復元するためにこれらの手順に従う必要がある理由は、次のとおりです。メールボックスが削除または移行された場合、imsrestore ユーティリティーはバックアップアーカイブに保存されたメールボックスの一意の ID 有効期間およびメッセージの一意の ID (UID) を使用してメールボックスを再作成します。

以前は、imsrestore は削除または移行されたメールボックスを再作成するときに、新しい UID 有効期間をメールボックスに、新しい UID をメッセージに割り当てました。その場合、キャッシュにメッセージが入っているクライアントはメールボックスの UID 有効期間およびメッセージの UID の同期をとりなおす必要がありました。クライアントは、新しいデータを再びダウンロードする必要があり、その結果、サーバーの作業負荷が増大しました。

新しい imsrestore の処理では、クライアントのキャッシュの同期は維持され、復元処理は透過的に実行され、パフォーマンスに悪影響を及ぼすことはありません。

メールボックスが存在する場合、imsrestore は新しい UID を復元されたメッセージに割り当てるので、新しい UID は既存のメッセージにすでに割り当てられている UID と矛盾しません。UID の一貫性を保証するために、復元操作時に imsrestore でメールボックスをロックします。ただし、imsrestore は、新しい UID 値を割り当てる代わりに、バックアップアーカイブからのメールボックスの UID 有効期間とメッセージ UID を使用するようになったため、増分バックアップおよび復元を実行すると UID の一貫性が保てなくなる場合があります。

imsbackup ユーティリティーの -d 日付オプションを使用して増分バックアップを実行する場合、復元操作を完了するために imsrestore を複数回呼び出す必要がある場合があります。増分バックアップを実行する場合、最後のフルバックアップとその後のすべての増分バックアップを復元する必要があります。

復元操作間に新しいメッセージをメールボックスに配信できますが、この場合、メッセージの UID に矛盾が生じることがあります。UID の矛盾が生じないようにするには、前述の手順のいずれかを実行する必要があります。

20.12.6 Legato Networker を使用する

Messaging Server は、Legato Networker のようなサードパーティー製のバックアップツールへのインタフェースを提供する、バックアップ API を装備しています。物理的なメッセージストア構造とデータ形式は、バックアップ API の中にカプセル化されています。バックアップ API はメッセージストアと直接対話します。さらに、バックアップサービスに対してメッセージストアの論理ビューを提示します。バックアップサービスは、メッセージストアの概念表現を使用して、バックアップオブジェクトの保存や検索を行います。

Messaging Server は Application Specific Module (ASM) を提供しています。これは、Legato Networker の save および recover コマンドによって呼び出され、メッセージストアのデータのバックアップと復元を行います。さらに ASM は、Messaging Server の imsbackup および imsrestore ユーティリティーを呼び出します。

この節では、Messaging Server のメッセージストアで Legato Networker を使用する方法についての情報を提供します。Legato Networker インタフェースについて理解するには、Legato のマニュアルを参照してください。

Legato Networker を使用してデータをバックアップする

1. /usr/lib/nsr/imsasm から msg-srv-base/lib/msg/imsasm へのシンボリックリンクを作成します。

2. Sun または Legato から nsrfile バイナリのコピーを取得して、それを次のディレクトリにコピーします。

   /usr/bin/nsr

   これは、古いバージョンの Networker (5.x) を使用している場合にのみ必須です。Networker 6.0 以上では、nsrfile は自動的に /usr/bin/nsr の下にインストールされます。

3. ユーザーをグループ別にバックアップする必要がある場合は、次の手順を実行します。

   1. 「20.12.2 バックアップグループを作成する」の説明に従って、バックアップグループファイルを作成します。

   2. 設定を確認するために、mkbackupdir.sh. を実行します。

      mkbackupdir.sh によって作成されたディレクトリ構造を確認してください。その構造は、表 20–4 に示されているようになっている必要があります。

      backup-groups.conf ファイルを指定していないと、バックアッププロセスはすべてのユーザーに対して、デフォルトのバックアップグループ ALL を使用します。

4. ディレクトリ /nsr/res/ で、保存グループ用に res ファイルを作成して、バックアップの前に mkbackupdir.sh スクリプトを呼び出します。表 20–4 に示した例を参照してください。

   ---

   注 –

   Legato Networker の旧バージョンでは、保存設定の名前には最高 64 文字まで使用できます。このディレクトリ名とメールボックスの論理名を合わせたもの (たとえば /primary/groupA/fred) が 64 文字を超えた場合、mkbackupdir.sh -p を実行する必要があります。このため、mkbackupdir.sh の -p オプションの短いパス名を使用してください。たとえば、次のコマンドでは /backup ディレクトリの下にバックアップイメージが作成されます。

   mkbackupdir.sh -p /backup

   重要: バックアップディレクトリは、メッセージストアの所有者による書き込みが可能でなければなりません (例: mailsrv)。

   ---

   表 20–6 には、バックアップグループのディレクトリ構造の例が示されています。

   /backup/primary/groupA/amy /bob /carly /groupB/mary /nancy /zelda /groupC/123go /1bill /354hut

   次の例に、res ファイルのサンプルとして、/nsr/res ディレクトリにある IMS.res という名前のファイルを示します。

   type: savepnpc; precmd: "echo mkbackupdir started", "/usr/siroe/server5/msg-siroe/bin/mkbackupdir.sh -p /backup"; pstcmd: "echo imsbackup Completed"; timeout: "12:00 pm";

   ここまでの準備が完了したら、次の手順に従って Legato Networker インタフェースを実行します。

5. 必要に応じて Messaging Server 保存グループを作成します。

   1. nwadmin を実行します。

   2. Customize | Group | Create の順に選択します。

6. バックアップコマンドとして savepnpc を使用して、バックアップクライアントを作成します。

   1. mkbackupdir によって作成されるディレクトリに対して保存設定を行います。

      単一セッションのバックアップには、/backup を使用します。

      同時バックアップには、/backup/server/group を使用します。

      「20.12.2 バックアップグループを作成する」の定義に従って group があらかじめ作成されていることを確認します。

      また、同時実行するバックアップセッションの数も設定する必要があります。

      詳細については、「Legato Networker を使用してデータをバックアップする」を参照してください。

7. Group Control | Start の順に選択して、バックアップ設定のテストを行います。

   例: Networker でバックアップクライアントを作成する

   Networker でバックアップクライアントを作成するには、nwadmin から、Client | Client Setup | Create の順に選択します。

   Name: siroe Group: IMS Savesets:/backup/primary/groupA /backup/secondary/groupB /backup/tertiary/groupC . . Backup Command:savepnpc Parallelism: 4

20.12.6.1 Legato Networker を使用したデータの復元

データの回復は、Legato Networker の nwrecover インタフェースまたは recover コマンド行ユーティリティーを使用して実行できます。次の例では、ユーザー a1 の INBOX を回復しています。

recover -a -f -s siroe /backup/siroe/groupA/a1/INBOX

次の例では、メッセージストア全体を回復しています。

recover -a -f -s siroe /backup/siroe

20.12.7 サードパーティーのバックアップソフトウェア (Legato 以外) を使用する

Messaging Server では、コマンド行 imsbackup と Solstice Backup (Legato Networker) の 2 つのメッセージストアバックアップソリューションを提供しています。メッセージストア全体をバックアップするために imbackup を単体で実行すると、大規模なメッセージストアの場合、非常に長い時間がかかってしまう可能性があります。Legato ソリューションでは、複数のバックアップデバイスでのバックアップセッションの同時実行をサポートしています。バックアップを同時実行することにより、バックアップ時間を大幅に短縮できます (毎時 25G バイトのデータバックアップが達成できる)。

その他のサードパーティーのバックアップソフトウェア (Netbackup など) を使用する場合は、次の方法によってバックアップソフトウェアを Messaging Server に統合します。

サードパーティーのバックアップソフトウェア (Legato 以外) を使用する

1. ユーザーをグループに分割し (「20.12.2 バックアップグループを作成する」を参照)、msg-svr-base/config/ ディレクトリの下に backup-groups.conf ファイルを作成します。

   ---

   注 –

   このバックアップソリューションは追加のディスク容量を必要とします。すべてのグループを同時にバックアップするには、メッセージストアの 2 倍のサイズのディスク容量が必要になります。ディスク容量に余裕のない場合は、ユーザーを小規模なグループに分け、グループセット単位でバックアップしていきます。たとえば、group1 〜 group5、group6 〜 group10 というようになります。バックアップ後、グループデータファイルを削除します。

   ---

2. imsbackup を実行して、準備領域にあるファイルに各グループをバックアップします。

   このためのコマンドは、imsbackup -f <device> /<instance>/<group> です。

   複数の imsbackup プロセスを同時に実行することができます。次に例を示します。

   # imsbackup -f- /primary/groupA > /bkdata/groupA & # imsbackup -f- /primary/groupB > /bkdata/groupB & . . .

   imsbackup は大きなサイズのファイルをサポートしていないため、バックアップデータが 2G バイトを超える場合は -f- オプションを使用して、データを stdout に書き込み、ファイルへ出力を受け渡します。

3. サードパーティー製のバックアップソフトウェアを使用して、準備領域 (上の例では /bkdata) のグループデータファイルをバックアップします。

4. ユーザーを復元するには、ユーザーのグループファイル名を確認し、そのファイルをテープから復元し、imsrestore を使用してデータファイルからユーザーを復元します。

   imsrestore は大きなサイズのファイルをサポートしていません。データファイルが 2G バイトより大きい場合は、次のコマンドを使用してください。

   # cat /bkdata/groupA | imsrestore -f- /primary/groupA/andy

20.12.8 バックアップおよび復元の問題のトラブルシューティング

この節では、一般的なバックアップと復元の問題、およびその問題の解決策について説明します。

• 問題: imsrestore または imsasm を使用してフォルダまたは INBOX を復元すると、そのフォルダ内のすべてのメッセージが現在のフォルダに追加されます。その結果、そのフォルダにメッセージの複数のコピーが作成されます。

  解決策: imsasm スクリプトで、imsrestore の -i フラグが設定されていないことを確認してください。

• 問題: メールフォルダに追加された新しいメッセージのみの増分バックアップを行おうとしたが、フォルダ全体がバックアップされてしまいます。新しいメッセージのみをバックアップする方法はありますか。

  解決策: imsbackup の -d datetime フラグを設定します。このようにすると、指定された日時から現在までに保存されたメッセージがバックアップされます。デフォルトでは、日付に無関係にすべてのメッセージがバックアップされます。

20.12.9 メッセージストアの災害時のバックアップと復元

災害とは、1 つまたは複数のメールボックスではなく、メッセージストア全体に壊滅的な障害が発生することを指します。つまり、メッセージストアサーバー上のすべてのデータが失われた状態のことです。メッセージストアの災害時の完全な復元では、失われた次のデータが復元されます。

• すべてのメッセージストアデータ。このデータは、「20.12 メッセージストアのバックアップと復元を行う」に説明されている手順を使ってバックアップできます。ファイルシステムバックアップ方法を使用する場合は、次のデータを必ずバックアップするようにします。

  • すべてのメッセージストアパーティション

  • msg-svr-base/data/store/mboxlist にあるメッセージストアデータベースファイル

  • msg-svr-base/data/store/dbdata/snapshots にあるメッセージストアデータベースのスナップショット。メッセージストアデータベースのスナップショットファイルの場所は configutil パラメータ local.store.snapshotpath で設定できます。

• 設定データ。msg-svr-base/data/config にあるローカル設定ファイルを含みます。

障害回復に備えてメッセージストアをバックアップする場合は、ファイルシステムスナップショットツールを使用してファイルシステムのスナップショットを作成できます。このスナップショットは、ポイントインタイムのファイルシステムスナップショットである必要があります。そうでない場合は、mboxlist のバックアップを使用できません。mboxlist データベースは、完全なデータベーススナップショットから復元する必要があります。

同じポイントインタイムのすべてのデータ (メッセージストアパーティション、データベースファイル、その他) を取得することをお勧めしますが、それが不可能な場合は、次の順序でデータをバックアップしてください。

1. データベーススナップショット

2. データベースファイル

3. メッセージストアパーティション

4. 設定データ

メッセージストアパーティションとデータベースファイルを同じポイントインタイムのスナップショットでバックアップしなかった場合は、ファイルシステムスナップショットの復元後に reconstruct -m を実行してください。これにより、データベースとメッセージストアパーティションが同期します。

20.13 ユーザーアクセスを監視する

Messaging Server では、imsconnutil コマンドが提供されます。このコマンドを使用して、ユーザーの IMAP、POP、および HTTP を介したメッセージストアアクセスを監視できます。また、ユーザーの最新のログインおよびログアウトを確認できます。このコマンドは、メッセージストア単位で機能するものであり、メッセージストア全体に対しては機能しません。

適用される法律または条例に違反する使用、または顧客自身のポリシーまたは契約に違反する使用の場合、この機能またはその他の Messaging Server の機能を使ってユーザーのメールを監視、読み取り、もしくはアクセスすると、不利益を引き起こす可能性があります。

このコマンドを使用するにはシステムユーザー (デフォルト: mailsrv) によるルートアクセスが必要です。また、設定変数の local.imap.enableuserlist、local.http.enableuserlist、local.enablelastaccess を 1 に設定する必要があります。

IMAP または Web メールクライアントを介して現在ログインしているユーザーを一覧表示するには、次のコマンドを使用します。

# imsconnutil -c

メッセージストアのユーザーごとの最新の IMAP、POP、または Messenger Express によるアクセス (ログインおよびログアウト) を一覧表示するには、次のコマンドを使用します。

# imsconnutil -a

次のコマンドは 2 つの処理を実行します。1) 指定したユーザーが現在 IMAP、Messenger Express、または mshttp を介して接続しているクライアントからログインしているかどうか判別する (一般に、POP ユーザーの場合は常時接続でない場合があるので、この処理は POP には機能しないことに注意)。2) ユーザーが最後にログインおよびログアウトした時刻を一覧表示する。

# imsconnutil -c -a -u user_ID

ユーザーの一覧は、次のコマンドを使用して 1 行につき 1 ユーザーずつファイルで入力できます。

# imsconnutil -c -a -f filename

-s フラグを使用して、特定のサービス (imap または http) を指定することもできます。たとえば、特定のユーザー ID が IMAP にログインしたかどうかを一覧表示するには、次のコマンドを使用します。

# imsconnutil -c -s imap -u user_ID

imsconnutil の構文の詳細については、『Sun Java System Messaging Server 6.3 Administration Reference』の「imsconnutil」を参照してください。

次に出力例を示します。

$ ./imsconnutil -a -u soroork

UID     IMAP last access    HTTP last access    POP last access
=========================================================================
ed   08/Jul/2003:10:49:05   10/Jul/2003:14:55:52  ---NOT-RECORDED---

$ ./imsconnutil -c

IMAP
UID    TIME                AUTH            TO                 FROM
===========================================================================
ed   17/Jun/2003:11:24:03  plain     172.58.73.45:193   129.157.12.73:2631
bil  17/Jun/2003:04:28:43  plain     172.58.73.45:193   129.158.16.34:2340
mia  17/Jun/2003:09:36:54  plain     172.58.73.45:193   192.18.184.103:3744
jay  17/Jun/2003:05:38:46  plain     172.58.73.45:193   129.159.18.123:3687
pau  17/Jun/2003:12:23:28  plaintext 172.58.73.45:193   192.18.194.83:2943
ton  17/Jun/2003:05:38:46  plain     172.58.73.45:193   129.152.18.123:3688
ani  17/Jun/2003:12:26:40  plaintext 172.58.73.45:193   192.18.164.17:1767
ani  17/Jun/2003:12:25:17  plaintext 172.58.73.45:193   129.150.17.34:3117
jac  17/Jun/2003:12:26:32  plaintext 172.58.73.45:193   129.150.17.34:3119
ton  17/Jun/2003:12:25:32  plaintext 172.58.73.45:193   192.18.148.17:1764
===========================================================================
10 users were logged in to imap.
Feature is not enabled for http.
---------------------------------------------------------------------------

20.14 メッセージストアをトラブルシューティングする

この節では、障害に備えてメッセージストアを保守する際のガイドラインについて説明します。また、メッセージストアが壊れたり、予期せずシャットダウンされた場合に使用する、その他のメッセージストアの回復手順についても説明します。メッセージストア回復の追加手順に関する節は、「20.14.3 メールボックスとメールボックスデータベースの修復」の続きになります。

この節を読む前に、この章のこれまでの部分と、『Sun Java System Messaging Server Administration Reference』のコマンド行ユーティリティーおよび configutil に関する章を再度読まれますよう、強くお勧めします。この節では、次の項目について説明します。

• 「20.14.1 標準的なメッセージストアの監視手順」

• 「20.14.4 一般的な問題と解決策」

• 「20.14.2 メッセージストアの起動と回復」

• 「20.14.3 メールボックスとメールボックスデータベースの修復」

20.14.1 標準的なメッセージストアの監視手順

ここでは、メッセージストアの監視の標準的な手順の概要を説明します。ここで説明する手順は、メッセージストアの全般的なチェック、テスト、および標準的な保守を行う場合に役立つものです。

その他の情報については、「27.7 メッセージストアを監視する」を参照してください。

20.14.1.1 ハードウェアの容量のチェック

メッセージストアには、十分な追加のディスク容量とハードウェアリソースが必要です。メッセージストアがディスク容量とハードウェア容量の上限に近づくと、メッセージストアに問題が発生することがあります。

ディスクの空き容量の不足は、メールサーバーで発生する問題や故障のうち、特に頻繁におきる原因の 1 つです。メッセージストアへ書き込むとき、そのための容量が不足していると、メールサーバーにエラーが発生します。さらに、利用可能なディスク容量が一定のしきい値より少なくなると、メッセージ配信やログ記録などに関連する多数の問題が発生します。stored プロセスのクリーンアップ機能が失敗し、削除されたメッセージがメッセージストアから消去されていないと、ディスク容量が急激に不足することがあります。

ディスク容量の監視の詳細については、「20.11.5 ディスク容量を監視する」および 「27.7 メッセージストアを監視する」を参照してください。

20.14.1.2 ログファイルのチェック

ログファイルをチェックして、メッセージストアプロセスが設定どおりに実行されていることを確認します。Messaging Server は、サポートしている主なプロトコルまたはサービス (SMTP、IMAP、POP、および HTTP) ごとに一連のログファイルを作成します。ログファイルは、msg-svr-base/log/ ディレクトリで表示できます。ログファイルは定期的に監視する必要があります。

ログ記録はサーバーパフォーマンスに影響することがあります。より詳細なログ記録を指定するほど、一定期間にログファイルが多くのディスク容量を占有することになります。効果的に定義する必要がありますが、現実的なログローテーション、有効期間、サーバーのバックアップポリシーなどを考慮する必要があります。サーバーのログポリシーの定義の詳細は、第 25 章「ログの管理」を参照してください。

20.14.1.3 テレメトリを使用してユーザーの IMAP/POP/Webmail セッションをチェックする

Messaging Server では、テレメトリと呼ばれる機能が提供されており、ユーザーの IMAP、POP、または HTTP のセッション全体をファイルに取得できます。この機能は、クライアント問題をデバッグするのに便利です。たとえば、メッセージアクセスクライアントが期待どおりに機能しないとユーザーが訴えた場合、この機能を使用してアクセスクライアントと Messaging Server 間の対話を記録することができます。

POP セッションの記録をとるには、次のディレクトリを作成します。

msg-svr-base/data/telemetry/pop_or_imap_or_http/userid

POP セッションの記録をとるには、次のディレクトリを作成します。

msg-svr-base/data/telemetry/pop/ userid

IMAP セッションの記録をとるには、次のディレクトリを作成します。

msg-svr-base/data/telemetry/imap/ userid

Webmail セッションの記録をとるには、次のディレクトリを作成します。

msg-svr-base/data/telemetry/http/ userid

このディレクトリは、Messaging Server のユーザー ID によって所有され、書き込み可能である必要があります。

Messaging Server によって、セッションにつき 1 ファイルがそのディレクトリに作成されます。出力例を次に示します。

LOGIN redb 2003/11/26 13:03:21
>0.017>1 OK User logged in
<0.047<2 XSERVERINFO MANAGEACCOUNTURL MANAGELISTSURL MANAGEFILTERSURL
>0.003>* XSERVERINFO MANAGEACCOUNTURL {67}
http://redb@cuisine.blue.planet.com:800/bin/user/admin/bin/enduser 
MANAGELISTSURL NIL MANAGEFILTERSURL NIL
2 OK Completed
<0.046<3 select "INBOX"
>0.236>* FLAGS (\Answered flagged draft deleted \Seen $MDNSent Junk)
* OK [PERMANENTFLAGS (\Answered flag draft deleted \Seen $MDNSent Junk \*)]
* 1538 EXISTS
* 0 RECENT
* OK [UNSEEN 23]
* OK [UIDVALIDITY 1046219200]
* OK [UIDNEXT 1968]
3 OK [READ-WRITE] Completed
<0.045<4 UID fetch 1:* (FLAGS)
>0.117>* 1 FETCH (FLAGS (\Seen) UID 330)
* 2 FETCH (FLAGS (\Seen) UID 331)
* 3 FETCH (FLAGS (\Seen) UID 332)
* 4 FETCH (FLAGS (\Seen) UID 333)
* 5 FETCH (FLAGS (\Seen) UID 334)
<etc>

20.14.1.4 stored プロセスのチェック

stored 機能は、存続期間決定ポリシーを実行したり、ディスクに保存されているメッセージを消去して、メッセージデータベースのデッドロック操作やトランザクション操作などの、さまざまな重要なタスクを実行します。stored が実行を停止すると、最終的には Messaging Server に問題が発生します。start-msg が実行されているときに stored が起動していないと、ほかのプロセスも起動しません。

• stored プロセスが実行中かどうかをチェックします。stored -t -v を実行します。

• store_root/mboxlist 内に作成されたログファイルをチェックします。

• デフォルトログファイルの msg-svr-base/log/default/default 内の stored メッセージをチェックします。

• stored プロセスによって次の機能のいずれかが試行された場合は、必ず次のファイル (msg-svr-base/config/ ディレクトリ内) のタイムスタンプが更新されることを確認します。

stored プロセスの詳細については、『Sun Java System Messaging Server 6.3 Administration Reference』の 「20.11.6 stored デーモン」の章を参照してください。

stored 機能の監視の詳細については、「27.7 メッセージストアを監視する」を参照してください。

20.14.1.5 データベースログファイルをチェックする

データベースログファイルは、sleepycat トランザクションのチェックポイントログファイル (store_root/mboxlist ディレクトリ内) を指します。ログファイルが蓄積されると、データベースのチェックポイント設定は行われません。通常は、単一の期間内に、2 つまたは 3 つのデータベースログファイルがあります。ログファイルがそれ以上ある場合は、問題がある可能性があります。

20.14.1.6 ユーザーフォルダのチェック

ユーザーフォルダをチェックする場合は、次のコマンドを実行します。reconstruct -r -n (すべてのメールボックス、修復なし)。これにより、ユーザーフォルダおよびレポートのエラーを確認します。reconstruct コマンドの詳細については、「20.14.3 メールボックスとメールボックスデータベースの修復」を参照してください。

20.14.1.7 コアファイルのチェック

コアファイルは、プロセスが予期せず終了したときにのみ存在します。コアファイルを確認することは、メッセージストアに問題がありそうなときは特に重要です。Solaris の場合は、coreadm を使用して core ファイルの場所を設定します。

20.14.2 メッセージストアの起動と回復

メッセージストアのデータはメッセージ、インデックスデータ、およびメッセージストアデータベースで構成されています。このデータは堅固ですが、ごくまれにメッセージストアのデータに関する問題がシステムに存在することがあります。このような問題はデフォルトのログファイルに示され、ほとんどの場合は透過的に修正されます。ただし、reconstruct ユーティリティーを実行する必要があることを示すエラーメッセージがログファイルに表示される場合がまれにあります。また、最終手段として、メッセージは 「20.12 メッセージストアのバックアップと復元を行う」で説明されているバックアップと復元のプロセスによって保護されます。この節では、stored の自動起動および回復プロセスについて説明します。

メッセージストアでは、以前は管理者の職責であった多くの回復処理が自動化されています。これらの処理はメッセージストアデーモンの stored によって起動時に実行され、必要に応じてデータベーススナップショットおよび自動高速復元が含まれます。stored によってメッセージストアのデータベースが徹底的にチェックされ、問題が検出された場合は自動的に修復されます。

また、stored は、デフォルトのログにステータスメッセージを出力することで、データベースのステータスの総合的な分析を提供し、メッセージストアに行われた修復およびメッセージストアを回復するために行われた自動試行について報告します。

20.14.2.1 自動起動と自動回復 - 動作方式

stored デーモンは、ほかのメッセージストアプロセスが起動する前に起動します。このデーモンによってメッセージストアデータベースは初期化され、必要に応じて回復処理が行われます。メッセージストアデータベースは、フォルダ、容量制限、購読、およびメッセージフラグの情報を保持します。データベースはログ用とトランザクション用であるので、回復はすでに組み込まれています。また、一部のデータベース情報は、各フォルダのインデックス領域に予備でコピーされています。

データベースは非常に堅固ですが、まれに壊れたとしても、ほとんどの場合は stored によって透過的に回復および修復されます。ただし、stored が再起動された場合は毎回、デフォルトのログファイルをチェックして、ほかに管理操作が必要ないことを確認してください。データベースをさらに修復する必要がある場合は、ログファイルのステータスメッセージで reconstruct を実行するように示されます。

メッセージストアデータベースを開く前に、stored はデータベースの完全性を分析し、ステータスメッセージを warning のカテゴリの下にあるデフォルトログに出力します。メッセージには管理者にとって有用なものも、内部分析に使用されるコード化されたデータで構成されるものもあります。stored によって問題が検出された場合は、データベースの修復が試行され、再起動が試行されます。

データベースが開くと、stored は、ほかのサービスが起動することを合図します。自動修復が失敗した場合、デフォルトログのメッセージで実行するべきアクションが示されます。詳細については、「reconstruct が必要であることを示すエラーメッセージ」を参照してください。

以前のリリースでは、stored は非常に長い時間がかかる回復プロセスを開始することがあり、stored が「スタック」したかのように見えることがありました。このタイプの長い回復プロセスは取り除かれ、stored は最終的な状態を 1 分以内に判断するようになりました。ただし、stored がスナップショットからの回復などの回復手段を採用する必要がある場合、プロセスは数分かかる場合があります。

ほとんどの回復プロセスでは通常、終了後のデータベースは最新の状態になっていて、ほかに必要な操作はありません。ただし、一部の回復プロセスでは、reconstruct -m を実行してメッセージストアの冗長データを同期させる必要がある場合もあります。これもデフォルトログに示されます。したがって、起動後にデフォルトログを監視することは重要です。メッセージストアが通常どおり起動し、機能しているように見える場合でも、reconstruct など、要求されている操作がある場合は実行することが重要です。

ログファイルを読むもう 1 つの理由は、データベースに障害を引き起こした原因を確認することです。stored は、システムでの問題の種類にかかわらずメッセージストアを回復するように設計されていますが、データベース障害はより大きな問題が潜んでいることの徴候である可能性があるので、原因を解明することをお勧めします。

reconstruct が必要であることを示すエラーメッセージ

ここでは、reconstruct の実行が必要なエラーメッセージのタイプについて説明します。

エラーメッセージでメールボックスエラーが示された場合は、reconstruct <mailbox> を実行します。例:

"Invalid cache data for msg 102 in mailbox user/joe/INBOX. Needs reconstruct"

"Mailbox corrupted, missing fixed headers: user/joe/INBOX"

"Mailbox corrupted, start_offset beyond EOF: user/joe/INBOX"

エラーメッセージでデータベースエラーが示された場合は、reconstruct -m を実行します。例:

"Removing extra database logs. Run reconstruct -m soon after startup to resync redundant data"

"Recovering database from snapshot. Run reconstruct -m soon after startup to resync redundant data"

データベーススナップショット

スナップショットは、データベースのホットバックアップであり、壊れたデータベースを数分で透過的に回復するために stored で使用されます。これは、ほかの領域に保存された冗長情報に依存する reconstruct を使用するよりもはるかに速い方法です。

メッセージストアのデータベーススナップショット - 動作方式

データベースのスナップショット (mboxlist ディレクトリ内) は自動的に作成されます。デフォルトでは、24 時間ごとに作成されます。デフォルトでは、スナップショットは store ディレクトリのサブディレクトリにコピーされます。デフォルトでは、常時 5 つのスナップショットが保存されています。ライブデータベースが 1 つ、スナップショットが 3 つ、データベース/削除済みコピーが 1 つです。データベース/削除済みコピーはより新しいものであり、mboxlist データベースディレクトリの removed サブディレクトリに入れられたデータベースの非常時用のコピーです。

現在のデータベースに障害があるために回復プロセスで削除することが決定されると、stored がデータベースを removed ディレクトリに移動します (可能な場合)。したがって、必要に応じてそのデータベースを分析できるようになっています。

データの移動は、1 週間に 1 度だけ実行されます。データベースのコピーがすでに移動先に存在する場合、stored はストアが起動するたびごとにはコピーを置き換えません。removed ディレクトリのデータが 1 週間よりも古い場合にのみ置き換えます。これは、元のデータベースが一連の起動によってあまりにも早く置き換えられないようにするためです。

メッセージストアのデータベーススナップショットの間隔と場所を指定する

データベースとスナップショットを組み合わせるには、5 倍の容量が必要です。スナップショットが別のディスク上で実行されるように再設定し、システムの要件に合わせることを強くお勧めします。

stored によって起動時にデータベースに関する問題が検出された場合は、最善のスナップショットが自動的に回復します。3 つのスナップショット変数を使用して設定できるパラメータは、次のとおりです。スナップショットファイルの場所、スナップショットの作成間隔、保存されるスナップショットの数。表 20–13 に、これらの configutil パラメータを示します。

スナップショットの間隔が短すぎると、システムに頻繁に負荷がかかるとともに、データベースの問題がスナップショットとしてコピーされる可能性が高くなります。スナップショットの間隔が長すぎると、データベースはスナップショットが作成された過去の時点の状態を維持することになります。

スナップショット間隔は 1 日にすることをお勧めします。1 週間またはそれより長い間隔のスナップショットは、システムで問題が数日間解消されない場合に、問題が存在する前の状態に戻すのに便利です。

stored はデータベースの監視を実行し、データベースが完全でない可能性がある場合は最新のスナップショットを拒否する高度な機能があります。代わりに最新のもっとも信頼性の高いスナップショットを取り出します。1 日前のスナップショットが取り出される可能性があることにもかかわらず、システムはより新しい冗長データがある場合はそのデータを使用して古いスナップショットデータを無効にします。

つまり、スナップショットの根本的な役割は、システムを最新の状態に近づけることと、進行中のデータを再構築しようとするシステムのほかの部分の負担を軽減することです。

20.14.3 メールボックスとメールボックスデータベースの修復

1 つまたは複数のメールボックスが破損した場合、reconstruct ユーティリティーを使用してメールボックスまたはメールボックスデータベースを再構築し、すべての矛盾を修復することができます。

reconstruct ユーティリティーは、1 つまたは複数のメールボックスまたはマスターメールボックスファイルを再構築し、すべての矛盾を修復します。このユーティリティーを使うと、メールストアにおけるほとんどすべてのデータ破損を回復することができます。詳細については、「reconstruct が必要であることを示すエラーメッセージ」を参照してください。

表 20–14 に、reconstruct オプションの一覧を示します。構文や使用要件の詳細については、『Sun Java System Messaging Server 6.3 Administration Reference』の「reconstruct」を参照してください。

20.14.3.1 メールボックスを再構築する

メールボックスを再構築するには -r オプションを使用します。このオプションは次の場合に使用します。

• メールボックスにアクセスしたら、「システム I/O エラーが発生しました」または「メールボックスのフォーマットが不正です」のどちらかのエラーが返された場合。

• メールボックスにアクセスしたらサーバーがクラッシュした場合。

• ファイルがスプールディレクトリに追加されたか、スプールディレクトリから削除された場合。

reconstruct -r は、最初に整合性チェックを行います。問題が検出された場合にのみ、すべての整合性を報告し、再構築を行います。したがって、このリリースでは reconstruct ユーティリティーのパフォーマンスが向上しています。

reconstruct は、次の例で説明するように使用することができます。

ユーザー daphne に属するメールボックスのスプール領域を再構築するには、次のコマンドを使用します。

reconstruct -r user/daphne

メールボックスデータベースに一覧表示されたすべてのメールボックスのスプール領域を再構築するには、次のように入力します。

reconstruct -r

ただし、このオプションは注意して使用してください。メールボックスデータベースに一覧表示されたすべてのメールボックスのスプール領域を再構築する場合、メッセージストアが大規模なため非常に長い時間を要する可能性があるからです。(「20.14.3.3 reconstruct のパフォーマンス」を参照。) これよりも優れた障害復旧に対する手段は、ストア用に複数のディスクを使用することでしょう。ディスクが 1 つダウンしてもストア全体がダウンすることはないからです。ディスクが破損した場合、次のように -p オプションを使用してストアの一部分を再構築するだけですみます。

reconstruct -r -p subpartition

コマンド行の引数にリストされたメールボックスが primary パーティションに存在する場合のみそれらを再構築するには、次のように入力します。

reconstruct -p primary mbox1 mbox2 mbox3

primary パーティションに存在するすべてのメールボックスを再構築する必要がある場合は、次のようになります。

reconstruct -r -p primary

整合性チェックを実行せずにフォルダを再構築する場合は、-f オプションを使用します。たとえば、次のコマンドはユーザーフォルダ daphne の再構築を実行します。

reconstruct -f -r user/daphne

すべてのメールボックスを修正せずにチェックする場合は、次のように -n オプションを使用します。

reconstruct -r -n

20.14.3.2 メールボックスのチェックと修復

高レベルの整合性チェックを行い、メールボックスデータベースを修復するには、次のように入力します。

reconstruct -m

整合性チェックを行い、プライマリパーティションを修復するには次のように入力します。

reconstruct -p primary -m

-p および -m フラグを指定して reconstruct を実行しても、lright.db は修復されません。これは lright.db を修復すると、メッセージストア内のすべてのユーザーに対して ACL のスキャンを実行する必要があるためです。これをすべてのパーティションに対して実行するのは効率的でありません。lright.db を修復するには、reconstruct -l を実行します。

整合性チェックを行い、john という名前のユーザーのメールボックスを修復するには次のように入力します。

reconstruct -p primary -u john -m

-m オプションは次の場合に使用します。

• 1 つまたは複数のディレクトリがストアスプール領域から削除されたため、メールボックスデータベースのエントリも削除する必要が生じた場合。

• 1 つまたは複数のディレクトリがストアスプール領域に復元されたため、メールボックスデータベースのエントリも追加する必要が生じた場合。

• stored -d オプションによってデータベースの整合性を保つことができない場合。

  stored -d オプションによってデータベースの整合性を保つことができない場合、次の手順を順番に実行します。

  • すべてのサーバーを停止します。

  • store_root/mboxlist 内のすべてのファイルを削除します。

  • サーバープロセスを再起動します。

  • reconstruct -m を実行して、スプール領域の内容から新しいメールボックスデータベースを構築します。

20.14.3.3 reconstruct のパフォーマンス

reconstruct が処理を実行するのにかかる時間は、次に示すいくつかの要素によって異なります。

• 実行される処理と選択したオプションの種類

• ディスクパフォーマンス

• reconstruct -m 実行時のフォルダの数

• reconstruct -r 実行時のメッセージの数

• メッセージストアの全体サイズ

• システムが実行するほかのプロセスとシステムのビジー状態

• 実行中の POP、IMAP、HTTP、または SMTP アクティビティーが存在するかどうか

reconstruct -r オプションにより、最初の整合性チェックが実行されます。このチェックでは、再構築の必要なフォルダの数に応じて reconstruct のパフォーマンスが向上します。

ユーザー数が約 2400、メッセージストアが 85G バイトで、POP、IMAP、または SMTP アクティビティーが同時にサーバーで実行されているシステムでは、次のパフォーマンスが得られました。

• reconstruct -m に要した時間は約 1 時間

• reconstruct -r -f に要した時間は約 18 時間

reconstruct の操作にかかる時間は、サーバーで POP、IMAP、HTTP、または SMTP アクティビティーが実行されていない場合、大幅に減少します。

20.14.4 一般的な問題と解決策

この節では、次のようなメッセージストアの一般的な問題と解決策の一覧を示します。

• 「20.14.4.1 Linux - Messaging Server パッチ 120230-08: プロセスあたりのセッション数超過のために IMAP サーバー、POP サーバー、および HTTP サーバーが起動しない」

• 「20.14.4.2 Messenger Express または Communications Express がメールページを読み込まない」

• 「20.14.4.3 ワイルドカードパターンを使用したコマンドが機能しない」

• 「20.14.4.4 不明または無効なパーティション」

• 「20.14.4.5 ユーザーメールボックスディレクトリに関する問題」

• 「20.14.4.6 store デーモンが起動しない」

• 「20.14.4.7 メールボックスのオーバーフローによりユーザーメールが配信されない」

20.14.4.1 Linux - Messaging Server パッチ 120230-08: プロセスあたりのセッション数超過のために IMAP サーバー、POP サーバー、および HTTP サーバーが起動しない

このパッチのインストール後、Messaging Server を起動しようとすると、IMAP サーバー、POP サーバー、および HTTP サーバーが起動せず、次の例のようなエラーログが送信されることがあります。

http server - log:
[29/May/2006:17:44:37 +051800] usg197 httpd[6751]: General Critical: Not enough file 
descriptors to support 6000 sessions per process; Recommend ulimit -n 12851 or 87 
sessions per process.

pop server - log:
[29/May/2006:17:44:37 +051800] usg197 popd[6749]: General Critical: Not enough file 
descriptors to support 600 sessions per process; Recommend ulimit -n 2651 or 58 
sessions per process.

Once these values setting in /opt/sun/messaging/sbin/configutil then imap server 
failed to start

imap server - log: 
[29/May/2006:17:44:37 +051800] usg197 imapd[6747]: General Critical: Not enough 
file descriptors to support 4000 sessions per process; Recommend ulimit -n 12851 
or 58 sessions per process.

3 つのサーバーセッションに対応する適切なファイル記述子の数を設定してください。追加のファイル記述子は、/etc/sysctl.conf に次のような行を追加し、sysctl -p を使用してそのファイルを再度読み込むことによって使用可能になります。

fs.file-max = 65536 

また、/etc/security/limits.conf にも次のような行を追加してください。

*   soft  nofile  65536  
*   hard  nofile  65536

20.14.4.2 Messenger Express または Communications Express がメールページを読み込まない

ユーザーが Messenger Express ページまたは Communications Express メールページを読み込めない場合は、圧縮後にデータが破損している可能性があります。これは、古いプロキシサーバーがシステムに配備されている場合に発生することがあります。この問題を解決するには、local.service.http.gzip.static および local.service.http.gzip.dynamic を 0 に設定して、データ圧縮を無効にしてください。これで問題が解決したら、プロキシサーバーを更新することができます。

20.14.4.3 ワイルドカードパターンを使用したコマンドが機能しない

UNIX シェルには、ワイルドカードパターンを引用符で囲む必要があるものとその必要のないものがあります。たとえば、C シェルはワイルドカード (*、?) を含む引数をファイルとして展開しようとするため、一致するものがない場合は失敗します。これらのパターンマッチング引数は、mboxutil のようなコマンドに渡すためには引用符で囲む必要があります。

次に例を示します。

mboxutil -l -p user/usr44*

これは Bourne シェルで機能しますが、tsch や C シェルでは失敗します。これらのシェルには次のコマンドが必要です。

mboxutil -l -p "user/usr44*"

ワイルドカードパターンを使用したコマンドが機能しない場合は、そのシェルではワイルドカードを引用符で囲む必要があるかどうかを確認してください。

20.14.4.4 不明または無効なパーティション

ユーザーのメールボックスが作成したばかりの新しいパーティションに移動され、Messaging Server が更新または再起動されていない場合、Messenger Express で「パーティションが不明または無効です」というメッセージが表示されることがあります。この問題は新しいパーティションでのみ発生します。この新しいパーティションにユーザーメールボックスを新しく追加する場合、Messaging Server の更新または再起動を行う必要はありません。

20.14.4.5 ユーザーメールボックスディレクトリに関する問題

ユーザーメールボックスに関する問題が発生するのは、メッセージストアの損傷が少数のユーザーに限られていて、システム全体に対する損傷がないときです。ユーザーメールボックスのディレクトリに関する問題を識別、分析、および解決する際は、次のガイドラインを参考にしてください。

1. ログファイル、エラーメッセージ、またはユーザーが見た異常な動作を確認します。

2. デバッグ情報と履歴を保存しておくには、store_root/mboxlist/ ユーザーディレクトリ全体を、メッセージストア外部の別の場所にコピーします。

3. 問題の原因になっている可能性のあるユーザーフォルダを見つけるには、reconstruct -r -n コマンドを実行します。reconstruct を使用しても問題のあるフォルダが見つからない場合は、該当のフォルダが folder.db 内にない可能性があります。

   reconstruct -r -n コマンドを使用してもフォルダが見つからない場合は、hashdir コマンドを使用して場所を確認します。hashdir の詳細については、「20.11.2.3 hashdir ユーティリティー」および、『Sun Java System Messaging Server 6.3 Administration Reference』の Messaging Server コマンド行ユーティリティーの章の hashdir ユーティリティーを参照してください。

4. ファイルが見つかったら、ファイルを調べ、権限をチェックし、適切なファイルのサイズを確認します。

5. reconstruct -r (-n オプションは付けない) を使用して、メールボックスを再構築します。

6. reconstruct で問題が検出されない場合は、reconstruct -r -f コマンドを使用して、メールフォルダを強制的に再構築することができます。

7. フォルダが mboxlist ディレクトリ (store_root/mboxlist) 内にはなく、partition ディレクトリ (store_root/partition) にある場合は、全体的な矛盾がある可能性があります。この場合は、reconstruct -m コマンドを実行する必要があります。

8. 上記の手順が機能しない場合は、store.idx ファイルを削除してから、再度 reconstruct コマンドを実行してください。

   ---

   注意 –

   問題のあるファイルが reconstruct では見つからないファイルであることがわかっている場合は、store.idx ファイルだけを削除してください。

   ---

9. 原因が問題を起こすメッセージに限られている場合は、メッセージファイルをメッセージストアの外側の別の場所にコピーしてから、mailbox/ ディレクトリ上で reconstruct -r コマンドを実行する必要があります。

10. フォルダがディスク (store_root/partition/ ディレクトリ) 上にあっても、明らかにデータベース (store_root/mboxlist/ ディレクトリ) 内にはないことがわかった場合は、reconstruct -m コマンドを実行してメッセージストアの整合性をチェックします。

reconstruct コマンドの詳細については、「20.14.3 メールボックスとメールボックスデータベースの修復」を参照してください。

20.14.4.6 store デーモンが起動しない

stored が起動せずに次のエラーメッセージが表示される場合があります。

# msg-svr-base/sbin/start-msg

msg-svr-base: Starting STORE daemon ...Fatal error: Cannot
find group in name service

上記のメッセージは、local.servergid に設定された UNIX グループが見つからないことを示しています。Stored などは、gid をグループに設定する必要があります。local.servergid によって定義されたグループが誤って削除されることがあります。この場合は、削除されたグループを作成し、mailsrv をグループに追加し、instance_root の所有権とそのファイルを mailsrv とグループに変更します。

20.14.4.7 メールボックスのオーバーフローによりユーザーメールが配信されない

メッセージストアには store.idx ファイルに関して 2G バイトという強い制限があります。これは、1 メールボックス (フォルダ) あたりおよそ 100 万メッセージに相当します。store.idx ファイルが 2G バイトを超えそうなレベルまでメールボックスが大きくなると、ユーザーは新しい電子メールを受信できなくなります。また、imapd、popd、mshttpd など、そのメールボックスを処理するほかのプロセスのパフォーマンスも低下する可能性があります。

この問題が発生すると、mail.log_current に次のようなエラーが出力されます。

05-Oct-2005 16:09:09.63 ims-ms Q 7 ...System I/O error.Administrator, check server log for details.System I/O error.

また、MTA のログファイルにも次のようなエラーが出力されます。

[05/Oct/2005:16:09:09 +0900] jmail ims_master[20745]:Store Error:Unable to append cache for user/admin:File too large

この問題を最終的に特定するには、ユーザーのメッセージストアディレクトリ内の該当するファイルを確認するか、または imta ログファイルで詳細なメッセージを確認します。

当面の措置としては、ファイルのサイズを減らします。一部のメールを削除するか、別のメールボックスに移動します。また、mboxutil -r を使用して該当するフォルダの名前を別のものに変更したり、mboxutil -d を使用してフォルダを削除したりすることもできます (「20.11.2.1 mboxutil ユーティリティー」 を参照)。

長期的には、ユーザーに対するメールボックスのサイズ制限の周知、存続期間決定ポリシー (「20.9 自動メッセージ削除 (有効期限および消去) 機能を設定する」を参照) および制限容量ポリシー (「20.8 メッセージストアの制限容量について」を参照) の実装、local.store.maxmessages を設定することによるメールボックス制限値の設定 (『Sun Java System Messaging Server 6.3 Administration Reference』の「configutil Parameters」を参照)、アーカイブシステムの設定、またはメールボックスのサイズを抑制するためのなんらかの措置を行う必要があります。

20.15 新しいシステムへのメールボックスの移行または移動

あるメッセージングサーバーシステムから別のメッセージングサーバーシステムに、既存のメールボックスを移動しなければならない場合があります。これは通常、次のような状況で発生します。

• Sun 以外のメッセージングサーバーから Sun Java System Messaging Server に移行する

• ある物理サーバーから別の物理サーバーにメールボックスを移動する

Messaging Server では、別のシステムにメールボックスを移動するための方法がいくつか用意されています。各方法には、利点と欠点があります。これらの方法については、「2.5 ユーザーメールボックスの移行」を参照してください。