第 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 实例的用户邮箱。消息存储的大小随邮箱、文件夹和日志文件的数量的增加而增加。可以通过指定对邮箱大小（磁盘配额）的限制、指定对允许的邮件总数的限制以及为存储中的邮件设置生存期策略来控制存储的大小。

向系统添加更多用户时，磁盘存储要求会相应增加。根据服务器支持的用户的数量，消息存储可能需要一个物理磁盘或多个物理磁盘。将此附加磁盘空间集成到系统中的方法有两种。最简单的方法是添加附加消息存储分区（请参见20.10 配置消息存储分区）。

同样，如果要支持多个托管域，您可能需要将一个服务器实例专用于一个大型域。通过此配置，您可以为特定域指定存储管理员。还可以通过添加更多分区扩展消息存储。

为了管理消息存储，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 配置消息存储分区。虽然为了易于维护，我们建议每个消息存储分区使用一个磁盘分区，但是消息存储分区与磁盘分区并不相同。

邮箱（例如 INBOX）位于 store_root 中。例如，样例目录路径可能如下所示：

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

下表介绍了消息存储目录。

.../userid/nn/
或
.../userid/folder/nn/

20.2.1 有效和无效的文件夹名称

以下是有效和无效的 IMAP 文件夹字符。

有效的 IMAP 文件夹字符：<space> ! " # $ & ' ( ) + , - . / 0-9 : ; < = > @ A-Z [ \ ] ^ _ ` a-z { | } ~

无效的 IMAP 文件夹字符：% * ?

请注意，某些字符序列将被拒绝，例如名为 public/ 的文件夹。使用英语语言环境时这些限制同样适用。其他语言（如日语）使用编码字符集。

20.3 消息存储如何删除邮件

从消息存储中删除邮件分三个阶段：

1. 删除。客户端可以将邮件标志设置为删除。此时邮件被标记为删除，但是通过去掉删除标志，客户端仍然可以恢复邮件。如果有第二个客户端，则已删除标志可能不会立即被该客户端识别。可以设置 configutil 参数 local.imap.immediateflagupdate 以使标志立即更新。

2. 擦除。邮件将从邮箱中删除。从技术上讲，邮件将从消息存储索引文件 store.idx 中删除。邮件本身仍然在磁盘上，但是一旦邮件被擦除，客户端将不能再恢复邮件。

   过期是擦除的一个特例。符合管理员定义的一组删除条件（例如邮件大小、生存期等）的邮件将被擦除。请参见20.9 设置自动删除邮件（过期和清除）功能。

3. 清除。默认情况下，imexpire 实用程序将在每天晚上 11 点从磁盘上清除所有已被擦除的邮件。可以使用 local.schedule.expire 和 store.cleanupage 配置此实用程序，其中 local.schedule.expire 用于控制邮件过期时间安排，而 store.cleanupage 用于控制清除操作的宽限期（在此宽限期之前不会清除邮件）。请注意，这与 imsimta purge 命令和用于清除旧版本 MTA 日志文件的 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 防止邮箱由管理员之外的其他人员删除或重命名

您可能希望某些邮箱受到保护以免管理员之外的其他人员删除或修改。下面的过程介绍了如何实现此操作。如果除管理员之外的其他人员试图删除、修改或重命名受保护的邮箱，系统将显示邮箱已固定错误消息。

设置 local.store.pin configutil 变量。使用以下格式：

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

其中，mailbox1、mailbox2 和 mailbox 3 是要保护的邮箱（请注意，邮箱名中可以使用空格），% 是邮箱间的分隔符。

20.5 关于共享文件夹

组或共享文件夹与任意其他邮件文件夹类似，不同之处在于，其他用户和组可以根据所具有的权限读取、删除组或共享文件夹中的邮件或向其中添加邮件。将邮件添加到共享文件夹时，可以通过普通的拖放操作、使用 Sieve 过滤器或直接使用以下形式发送邮件来实现：uid+folder @domain。

下面的示例显示了向某个专用共享文件夹发送电子邮件时所用的地址，该文件夹名为 crafts_club，由 carol.fanning@siroe.com 拥有：

carol.fanning+crafts_club@siroe.com

下面的示例显示了向某个公用共享文件夹发送电子邮件时所用的地址，该文件夹名为 tennis@siroe.com。

public+tennis@siroe.com

共享文件夹对于启动、共享和归档正在进行的有关特定主题的电子邮件对话非常有用。例如，一组软件开发者可以创建名为 mosaic_voices 的共享文件夹，用于讨论特定项目的开发。将邮件发送或拖至 mosaic_voices 文件夹时，任何有权访问该共享文件夹的用户（可以通过单个地址或组地址添加权限）都可以打开此邮箱并阅读邮件。

共享文件夹显示在用户邮箱树中名为 Shared Folders 的文件夹下。下面显示了一个示例：

图 20–2 来自邮件客户端的共享邮件文件夹列表示例

有两种共享文件夹：

• 专用共享文件夹—由特定用户使用 Communications Express 或其他支持创建共享文件夹的邮件客户端创建和拥有的共享文件夹。（有关详细信息，请参见 Communications Express 帮助屏幕。）专用共享文件夹位于 Shared Folders/User 邮件文件夹目录中。

• 公用共享文件夹—公用共享文件夹由邮件管理员创建，但没有拥有者。公用文件夹的电子邮件地址类似如下形式：

  public+foldername@domain
  

  例如，您可能需要一个文件夹（例如 public+software_dev@siroe.com）用于邮寄有关公司内部特殊兴趣组的信息。可以授予有兴趣的员工对此公用文件夹的访问权限。公用共享文件夹位于 Shared Folders/Public 邮件文件夹目录中。

通常，只有特定消息存储中的用户才可以使用共享文件夹。但是，Messaging Server 允许您创建可以从多个消息存储中访问的特殊共享文件夹。这些文件夹称为分布式共享文件夹。有关详细信息，请参见20.6.4 设置分布式共享文件夹。

20.6 共享文件夹任务

本节介绍了共享文件夹的管理员任务：

• 指定专用共享文件夹的共享属性

• 创建公用共享文件夹

• 20.6.1 使用电子邮件组添加共享文件夹

• 20.6.2 设置或更改共享文件夹的访问控制权限

• 20.6.3 启用或禁用共享文件夹列表

• 20.6.4 设置分布式共享文件夹

• 20.6.5 监视和维护共享文件夹数据

指定专用共享文件夹的共享属性

1. 专用共享文件夹由用户创建。

   许多邮件客户端支持创建专用共享文件夹。您可以在 Communications Express 上尝试该操作。

2. 设置专用共享文件夹的共享参数。

   支持以下 configutil 参数：

   store.privatesharedfolders.restrictanyone - 如果启用 (1)，将禁止一般用户将专用共享文件夹的权限设置为 anyone。默认值：0

   store.privatesharedfolders.restrictdomain - 如果启用 (1)，将禁止一般用户与其域之外的用户共享专用文件夹。默认值：0

   store.privatesharedfolders.shareflags - 如果为 0，用户之间将不能共享标记。如果为 1，用户之间可以共享标记。默认值：0

   store.publicsharedfolders.user - 公用共享文件夹拥有者的 userid。通常只是 public。默认值：NULL（未设置）

创建公用共享文件夹

由于公用文件夹的创建需要访问 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. 设置文件夹的名称。

   通常为 public。以下是将文件夹名称设置为 public 的命令：

   configutil -o store.publicsharedfolders.user —v public

4. 指定用户及其对该共享文件夹的访问权限。

   使用 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))

   （由于印刷原因，样例条目行已自动换行。实际条目应显示在一行中。）

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 -sfoldername 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 地址向共享文件夹邮寄邮件需要在具备 p（邮寄）访问权限的前提下使用 readership 命令。请参见20.6.2 设置或更改共享文件夹的访问控制权限。

20.6.3 启用或禁用共享文件夹列表

响应 LIST 命令时，根据配置选项 local.store.sharedfolders 中的设置，服务器将返回或不返回共享文件夹。将选项设置为 off 将禁用该选项。默认情况下，该设置处于启用状态（设置为 on）。

SELECT 和 LSUB 命令不受此选项的影响。LSUB 命令将返回每个已订阅的文件夹，包括共享文件夹。用户可以选择 (SELECT) 其拥有或订阅的共享文件夹。

20.6.4 设置分布式共享文件夹

通常，只有特定消息存储中的用户才可以使用共享文件夹。但是，Messaging Server 允许您创建可以从多个消息存储中访问的分布式共享文件夹。即，可以将对分布式共享文件夹的访问权限授予消息存储组内的所有用户。但是，请注意 Web 邮件客户端（HTTP 访问客户端，如 Messenger Express）不支持远程共享文件夹访问。用户可以列出和订阅文件夹，但不能查看或更改内容。

设置分布式共享文件夹要满足以下要求：

• 消息存储 userid 在消息存储的组内必须是唯一的。

• 部署内的目录数据必须相同。

必须通过设置表 20–4 中列出的配置变量，将远程消息存储（即不保留共享文件夹的消息存储）配置为代理服务器。

20.6.4.1 设置分布式共享文件夹—示例

图 20–3 显示了三个名称分别为 StoreServer1、StoreServer2 和 StoreServer3 的消息存储服务器的分布式文件夹示例。

图 20–3 分布式共享文件夹—示例

通过设置表 20–4 中所示的变量，这些服务器被相互连接成对等的代理消息存储。每个服务器均有一个专用共享文件夹—golf（Han 拥有）、tennis（Kat 拥有）和 hurling（Luke 拥有）。此外，还有两个分别名为 press_releases 和 Announcements 的公用共享文件夹。三个服务器中任何一个上的用户均可以访问这三个共享文件夹中的任何一个。图 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 是要检查的月数。

示例：删除在过去六个月中没有访问共享文件夹的用户：

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 邮件类型概述

统一邮件服务应用程序可以接受、发送、存储和管理多种邮件类型，包括文本邮件、语音邮件、传真邮件、图像数据以及其他数据格式。消息存储允许您定义多达 63 种不同的邮件类型。

有一种利用类型处理邮件的方法，即根据邮件类型将其分组到不同的文件夹中。

引入了邮件类型功能后，无需再使用单个邮箱文件夹维护不同的邮件类型。配置邮件类型后，无论将消息存储在何处，消息存储都能够识别出来。因此，您可以在同一个文件夹中存储不同的邮件类型。您也可以执行以下任务：

• 跟踪邮件类型的使用

• 发送按邮件类型分组的通知

• 对不同的邮件类型设置并管理不同的配额，无论它们是存储在同一个文件夹还是不同的文件夹中

• 根据为每种邮件类型配置的唯一标准将邮件从一个文件夹移动到另一个文件夹

• 根据为每个邮件类型配置的标准处理邮件过期

20.7.1.1 规划邮件类型配置

在统一邮件服务应用程序中，给不同格式的数据分配标准的 Internet 邮件标题，以便 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 必须是大于 0 小于 64 的整数。您可以将该参数配置为其中任何一个整数，最多能够定义 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

在上例中，读取了两个邮件，一个文本邮件和一个语音邮件。

邮件类型标志使用由 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 是语音邮件。用来搜索的关键字是 voice_message，即 store.messagetype.2.flagname 参数的值。

20.7.3 发送邮件类型的通知邮件

通知可以传送关于各种不同类型的邮件（例如文本邮件、语音邮件和图像数据）的状态信息。Messaging Server 使用 Sun Java System Message Queue 发送邮件类型的通知信息。有关为 Message Queue 配置 JMQ 通知插件的消息，请参见第 22 章，配置 JMQ 通知插件为 Message Queue 生成邮件。

要启用 JMQ 通知插件识别特定的邮件类型，必须配置 store.messagetype 参数，包括 store.messagetype.x.flagname 参数。有关详细信息，请参见配置邮件类型。

一旦配置了邮件类型，JMQ 通知邮件就能够标识特定邮件类型。您可以编写 Message Queue 客户端，以根据邮件类型解释通知邮件，并将每种类型的状态信息传送到邮件客户端。

JMQ 通知功能可以按邮件类型统计邮箱中的当前邮件数。随通知邮件发送的是指定每种邮件类型计数的数组，而不是一个计数。

例如，NewMsg 通知邮件中的数据可以通知用户在其收件箱中有 7 个新的语音邮件和 4 个新的文本邮件。

有关按邮件类型发送通知的详细信息，请参见22.3.3 特定邮件类型的通知。

20.7.4 按邮件类型管理配额

为邮件类型设置配额时，应包含配额根中的值。配额根指定用户的配额。它可以针对特定的邮件类型和邮箱文件夹指定不同的配额，也可以指定应用到所有剩余邮件类型、文件夹和未按类型定义的邮件的默认配额。

有关设置和管理配额的完整信息，请参见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 为用户设置邮件类型配额。

  有关如何使用这些属性设置配额根的信息，请参见《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 设置以下配额：

• 默认的邮箱存储配额为 40 M

• 默认的邮箱邮件配额为 5000

• Archive 文件夹的存储配额为 100 M

• 文本邮件类型的存储配额为 10 M

• 文本邮件类型的邮件配额为 2000

• 语音邮件类型的存储配额为 10 M

• 语音邮件类型的邮件配额为 200

该配额根允许 Archive 文件夹的存储配额 (100 M) 比所有其他文件夹和邮件类型的总存储配额 (60 M) 大。另外，Archive 文件夹没有邮件限制；在本例中，归档只有存储限制。

邮件类型既有存储配额又有邮件数量配额。

邮件类型配额适用于所有这些类型的邮件之和，无论它们是存储在 Archive 文件夹还是任何其他文件夹中。

对于所有非文本或非语音邮件类型且未存储在 Archive 文件夹中的邮件，将应用默认的邮箱配额。也就是说，邮件类型配额和 Archive 配额不记为默认邮箱配额的一部分。

要在本例中设置配额根，应该执行以下步骤：

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 命令时，得到的 IMAP 会话显示用户 joe 邮箱的所有配额根，如下所示：

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

在本例中，文本邮件和语音邮件以不同的方式过期，它们遵守不同的时间安排，如下所示：

• 文本邮件在到达消息存储一年后，将从用户收件箱移动到用户的 Archive 文件夹。

• 语音邮件在两周后将从收件箱移动到 OldMail 文件夹。如果用户保存语音邮件，保存的日期将被重置，邮件将在新日期的两周后被移走。

• 语音邮件在 30 天后将从 OldMail 文件夹移动到 Trash 文件夹。用户也可以在 OldMail 文件夹中保存语音邮件，这将使邮件在新的保存日期上再推迟 30 天后才会被移走。

• 所有类型的邮件在移动到 Trash 文件夹 7 天后将被放弃。

  过期规则自动将语音邮件移动到 Trash。当用户删除文本邮件时它们将移动到 Trash。

注意：savedays 规则使邮件在保存指定天数之后过期。在典型的语音邮件系统中，用户可以在语音邮件菜单中保存语音邮件。对于文本邮件，当它移动到一个文件夹时被保存。messagedays 规则使邮件在第一次到达消息存储指定的天数之后过期，无论它存储在哪个文件夹或被移动了多少次。

20.8 关于消息存储配额

随着电子邮件和语音邮件的发展，IMAP 邮箱可以变得很大。消息存储配额限制（或配额）表示一个用户或域可以保留的磁盘空间大小或邮件数，它针对特定的文件夹或者特定的邮件类型。配额用于限制或减少消息存储的使用。本节包含有关以下内容的信息：

有关详细信息，请参见20.11.4 监视配额限制。

• 20.8.1 配额概述

• 20.8.2 配额操作原理

• 20.8.3 消息存储配额属性和参数

• 20.8.4 配置消息存储配额

20.8.1 配额概述

可以为特定的用户或域设置配额，也可以根据邮件数或字节数设置配额。还可以为特定文件夹和邮件类型设置配额。邮件类型配额允许您为邮件类型指定限制。例如，语音邮件和电子邮件。文件夹配额设置用户文件夹的大小限制，以字节或邮件数为单位。例如，可以对 Trash 文件夹设置配额。Messaging Server 允许您为域和用户设置默认配额或自定义配额。

设置配额后，即可配置超过或接近配额时系统响应用户或域的方式。一种响应方式是向用户发送一个超过配额通知。超过配额时的另一种响应方式是停止向消息存储传送邮件。这叫做强制配额，通常发生在指定的宽限期之后。宽限期是邮箱在强制发生前可以超出配额的时间。如果由于超过配额而停止传送邮件，则外来邮件将保留在 MTA 队列中，直到出现以下情况之一：

• 用户邮件的大小或数量不再超出配额，此时 MTA 将传送邮件。

• 未传送邮件在 MTA 队列中保留的时间超过指定的宽限期，此时邮件将被返回给发件人。（请参见20.8.4.5 设置宽限期。）

• 邮件保留在邮件队列中的时间比最大邮件队列时间长。该设置由 notices MTA 通道关键字控制（请参见10.10.4.3 设置通知邮件传送间隔）。

  例如，如果您的宽限期设置为两天，而您超出了配额一天，则将继续接收新邮件并将其保留在邮件队列中，并继续进行传送尝试。第二天后，邮件将被退回给发件人。

用户删除或擦除邮件，或者服务器根据已建立的过期策略删除邮件时，磁盘空间将变为可用（请参见20.9 设置自动删除邮件（过期和清除）功能）。

20.8.1.1 电话学应用程序服务器的异常

为支持统一的邮件服务要求，Messaging Server 提供了覆盖由消息存储强加的配额限制的能力。这可以保证已被特定代理（即电话学应用程序服务器 [TAS]）接受的邮件的传送。TAS 接受的邮件可以通过特殊的 MTA 通道传送，该通道可以确保邮件被传送到存储而不受配额的限制。这种用法的适用范围很小，但可以用于电话学应用程序。有关配置 TAS 通道的详细信息，请联系 Sun 邮件服务代表。

按邮件类型配额对于使用统一邮件服务的电话学应用程序非常有用。例如，如果在用户的邮箱中存储了一个混合邮件（如文本和语音邮件），那么管理员可以对不同类型的邮件设置不同的配额。用户的电子邮件可以有一个配额，语音邮件可以有一个不同的配额。

20.8.2 配额操作原理

将配额属性添加到 LDAP 用户和域条目可以指定自定义的用户和域配额。配额默认值、通知策略、强制配额和宽限期是在 configutil 参数中或通过使用 imquotacheck 实用程序指定的。

要确定用户是否超出配额，Messaging Server 将首先检查以确定是否已为单个用户设置配额。如果未设置配额，Messaging Server 将检查为所有用户设置的默认配额。对于用户，配额是指所有用户文件夹中的所有累积字节或邮件数。对于域，配额是指特定域中所有用户的所有累积字节或邮件数。对于邮件类型，配额是指该邮件类型的所有累积字节或邮件数。对于文件夹，配额是指用户文件夹的所有累积字节或邮件数。

您可以为用户邮箱树指定以下配额值：

• 用户邮箱中特定文件夹的配额值。

• 特定邮件类型（如语音邮件或文本邮件）的配额值。（邮件类型配额应用于用户邮箱中所有文件夹中该类型的邮件。）

• 对用户邮箱中所有未明确分配配额的文件夹和邮件类型应用默认的配额值。

为一个用户分配多个配额值时适用以下原则：

• 配额不得重叠。例如，当存在特定邮件类型或文件夹的配额时，该类型的邮件或者该文件夹中的邮件不记入默认配额。每个邮件只能记入一个配额。

• 整个用户邮箱的总配额等于所有默认配额与按照类型和文件夹指定的配额值之和。

• 邮件类型配额优先于文件夹配额。例如，假设为用户的 memos 文件夹指定了一个配额，而为语音邮件指定了另一个配额。现在假设用户将 8 个语音邮件存储在 memos 文件夹中。这 8 个邮件将记入语音邮件配额，而不记入 memos 文件夹配额。

对配额属性和 configutil 参数做出的更改将自动生效，但不是立即生效，因为信息存储在缓存中，更改完全生效前需要花一点时间。Messaging Server 提供一个立即更新更改的命令，即《Sun Java System Messaging Server 6.3 Administration Reference》中的“iminitquota”。

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 参数在运行该命令后将自动生效。不运行该命令更改也可以生效，但不是立即生效，因为信息存储在缓存中，更改生效前需要花费一定的时间。

imquotacheck 实用程序允许您根据分配的配额检查消息存储的使用情况。

20.8.4 配置消息存储配额

本节介绍了以下任务：

• 20.8.4.1 指定默认用户配额

• 20.8.4.2 指定单个用户配额

• 20.8.4.3 指定域配额

• 设置配额通知

• 20.8.4.4 启用或禁用强制配额

• 20.8.4.5 设置宽限期

• 20.8.4.6 Netscape Messaging Server 配额兼容性模式

20.8.4.1 指定默认用户配额

没有在 LDAP 条目中设置个人配额的用户将应用默认配额。该过程分为两个步骤：1) 指定用户默认配额 2) 指定哪些用户受默认配额限制。以下示例显示了如何设置默认用户配额。有关详细的参数信息，请参阅《Sun Java System Messaging Server 6.3 Administration Reference》中的第 3  章 “Messaging Server Configuration”。

要以邮件大小（以字节为单位）的形式指定默认的用户磁盘配额，请运行以下命令：

configutil -o store.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 或将其设置为 –2。

要将配额设置为 1,000 封邮件，请将 mailMsgQuota 设置为 1000。

要将配额设置为 2 兆字节，请将 mailQuota 设置为 2M 或 2000000。

要将配额设置为 2 千兆字节，请将 mailQuota 设置为 2G 或 2000000000 或 2000M。

要指定 2 千兆字节的配额；20 兆字节的语音邮件配额；100 兆字节的 Archive 文件夹配额，请运行以下命令行：

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

2 千兆字节配额代表用户邮箱中所有没有明确分配配额的文件夹。在本例中，这不包括 Archive 文件夹中的邮件和语音类型的邮件。100 兆字节配额包括 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。

要将配额设置为 2 兆字节，请将 mailDomainDiskQuota 设置为 2M 或 2000000。

要将配额设置为 2 千兆字节，请将 mailDomainDiskQuota 设置为 2G 或 2000000000 或 2000M。

设置配额通知

配额通知是指当用户接近配额时向其发送警告邮件的过程。使用此功能需要执行以下三个步骤：

1. 启用配额通知

   运行以下命令行：

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

   如果未设置邮件，则不会向用户发送任何配额警告邮件。

2. 定义配额警告邮件

   警告邮件是指当用户快要超过磁盘配额时将向其发送的邮件。要通过命令行定义配额警告邮件，请运行以下命令：

   configutil -o store.quotaexceededmsg -v ’message’

   邮件必须是 RFC 822 格式。必须包含一个标题（至少具有一个主题行），接着是 $$，然后是邮件正文。"$" 表示一个新的行。可能需要在 $ 前面添加一个 \，使 $ 不再具有特殊含义（取决于所使用的 shell）。（$ 通常是 shell 的转义符。）示例：

   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 时，电子邮件通知不会被触发，直至用户的磁盘使用量超过配额的 100％，与使用 store.quotawarn 设置的阈值无关。

   ---

   对于其客户端支持 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 时，仅允许用户接受一个比配额小的邮件。即它将永远不会接受比用户配额大的邮件。

对这些参数做出更改后，请确保重新启动邮件传送服务。

这些消息存储属性应处于活动状态：

• 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 设置自动删除邮件（过期和清除）功能

自动删除邮件功能（也称为过期和清除）根据管理员定义的一组条件自动从消息存储中删除邮件。此功能可用于自动删除旧的和过大的邮件、已读/已删除邮件、带有特定主题行的邮件等等。此功能允许使用以下删除条件：

• 按文件夹（邮箱）、用户、域、整个消息存储或特定分区

• 邮箱中的邮件数

• 邮箱总大小

• 邮件在邮箱中已经存在的时间（以天为单位）

• 邮件的大小和宽限期（在清除前超大邮件将在消息存储中保留的天数）

• 邮件是否已标记为已读或已删除

• 标题字符串

此功能由 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 为每个分区创建一个线程。每个线程都将在其指定的分区下查看用户文件夹列表，同时装入本地过期规则文件。过期功能将按照适用于该文件夹的过期规则检查每个文件夹，并根据需要擦除邮件。如果在邮箱目录下存在 store.exp 文件，并且邮件由于超出了 store.cleanupage 配置参数指定的时间而被擦除/过期，清除功能将在邮件散列目录下永久删除邮件文件，并从 store.exp 文件中永久删除 UID 记录。

也可以通过在 msg-svr-base/config/ 中名为 expire_exclude_list 的文件中添加指定用户的用户 ID（每行一个），从过期规则中排除这些用户。

20.9.2 部署自动删除邮件功能

自动删除邮件需要三个步骤：

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。

超大邮件的生存期。自动删除在 Y 天宽限期后超过 X 字节的邮件。属性：messagesize 和 messagesizedays。

已读和已删除邮件标志。自动删除带有已读或已删除标志设置的邮件。可以将这些条件设置为 "and" 或 "or"。如果设置为 or，则邮件的已读/删除标志将导致自动删除而不管其他条件。如果设置为 and，则邮件的已读/删除标志必须设置为与指定的所有其他条件一起使用。属性：seen 和 deleted。

邮件的标题字段。允许您将标题和字符串指定为删除邮件的条件。例如，删除所有标题为 "Subject: Work from Home!" 的邮件”

邮件的文件夹。允许您指定要从其中删除邮件的文件夹。属性：folderpattern。请注意，该属性只使用已修改的 UTF-7 字符集。

imexpire 不允许根据邮件被读取后已存在的时间删除或保留邮件。例如，不能指定删除已经有 200 天未被读取的邮件。

自动删除邮件策略的示例

示例 1：删除超过 1,000 封邮件的文件夹中所有存在时间达到 365 天的邮件。

示例 2：删除域 siroe.com 中 180 天以上的邮件。

示例 3：删除所有已标记为已删除的邮件。

示例 4：删除 sesta.com 中已标记为已读、30 天以上、大于 100 千字节、位于超过 1,000 封邮件的文件夹中、带有标题 X-spam 的邮件。

20.9.2.2 设置实现自动删除邮件策略的规则

要实现上一节中定义的自动删除邮件策略，必须设置 imexpire 规则。可以通过将规则放入 store.expirerule 文件来设置规则。以下所示为两个全局 store.expirerule 规则的示例：

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

            

在此示例中，规则 1 指定垃圾文件夹中的所有邮件将在两天后被删除。规则 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 来指定。

  • 请注意，只在 Messaging Server 6.2p4 发行版及更高版本中实现了使用 rule_name 的多个非全局规则（用户、文件夹、分区）。

• 多个过期规则可以同时应用于一个邮箱。邮箱的过期策略由全局规则和本地规则组成。本地规则适用于同一目录下的邮箱及其所有子文件夹。

• imexpire 将统一应用于一个邮箱的所有过期规则，除非存在为此邮箱指定的专用规则（请参见表 20–8）。产生的规则集表示基于所有适用规则的最严格的过期策略。例如，如果规则 X 的过期策略指定最大邮件保存时间为 10 天，规则 Y 指定为 5 天，则统一规则为 5 天。

本地化的邮箱名称

IMAP 协议指定邮箱名称使用已修改的 UTF-7 编码。Messaging Server 在外部接口上支持本地化的字符集，从而可以本地化邮箱名称。但是，系统在内部将本地化的名称转换为 UTF-7。因此，客户端上具有本地化邮箱名称的文件夹有一个对应的 UTF-7 邮箱文件名称。（请注意，IMAP 错误邮件将以 UTF-7 而不是本地化字符集的形式输出邮箱名称。）

一般来说，尽管消息存储实用程序可能具有允许使用不同字符集的选项标志，但大部分需要邮箱名称的消息存储实用程序通常都希望使用本地化字符集的名称。这些实用程序有 reconstruct、mboxutil、imsbackup、imsrestore 和 hashdir。但是，imexpire 要求使用属性 folderpattern 指定的邮箱名称其字符集为 UTF-7。使用本地化名称将会无效。

要获取 imexpire 相应的 folderpattern，可能需要将本地化邮箱名称转换为等效的 UTF-7 邮箱名称。可以使用 mboxutil -E 命令进行此操作，如下所示：

第一个 mboxutil 显示了本地化的文件名。第二个 mboxutil 显示了已修改的 UTF-7 文件名。这也可以使用以下 IMAP list 命令：

通过文本方式设置 imexpire 规则

通过在 store.expirerule 文件中指定规则来设置自动删除邮件规则。store.expirerule 文件中每行包含一个过期条件。全局规则配置文件 (msg-svr-base/data/store/store.expirerule) 的过期条件的格式如下：

rule_name.attribute : value

用户或邮箱规则配置文件的过期规则的格式如下：

attribute: value

示例 20–4 显示了 msg-svr-base/config/store.expirerule 中的一组全局过期规则。

规则 1 设置全局过期策略（即应用于所有邮件的策略），如下所示：

• 在创建规则时启用 UNIX 正则表达式。

• 3 天后删除大于 100,000 字节的邮件。

• 删除用户已删除的邮件。

• 删除所有 Subject: 标题中带有 "Vigara Now!" 或 "XXX Porn!" 字符串的邮件。

• 将所有文件夹限制为容纳 1,000 封邮件。达到 1,000 封邮件后，系统将从文件夹中删除最早的邮件以保持总数为 1,000。

• 删除所有 365 天以前的邮件。

规则 2 为托管域 siroe.com 中的用户设置自动删除邮件策略。它将邮箱大小限制为 1 兆字节，删除已删除的邮件，并删除 14 天前的邮件。

规则 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 文件夹模式

通过将 imexpire 属性 regex 设置为 1，可以使用 POSIX 正则表达式指定文件夹模式。如果未指定，则将使用 IMAP 表达式。格式必须以 user/ 开头，后跟一种模式。表 20–9 显示了各种文件夹的文件夹模式。）

20.9.2.3 安排自动删除邮件和日志记录级别

通过 imsched 时间安排守护进程来激活自动删除邮件。默认情况下，imsched 将在每天 23:00 点调用 imexpire，邮件将被擦除并被清除。可以通过设置表 20–10 中介绍的 configutil 参数 local.schedule.expire 和 store.cleanupage 自定义此时间安排。

对于大型消息存储，可能会花费很长时间才能完成过期和清除，因此您可能需要通过试验决定运行这些进程的频率。例如，如果过期/清除周期花费 10 小时，您可能不希望默认时间安排为每天运行过期和清除一次。使用 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（调试）选项可以用于指示 imexpire 日志记录 stderr 的详细状态/调试消息。如果通过 imsched 调用 imexpire，则 configutil 参数 local.store.expire.loglevel 可以设置为 1、2 或 3 以进行不同级别的日志记录。Loglevel 1 是默认值，将记录整个过期会话的摘要。Loglevel 2 将对每个过期邮箱记录一条消息。Loglevel 3 将对每个过期邮件记录一条消息。

从自动删除邮件中排除指定的用户

通过在 msg-svr-base/config/ 中名为 expire_exclude_list 的文件中添加指定用户的用户 ID（每行一个），以从过期规则中排除这些用户。或者，在用户邮箱下配置一个伪排外过期规则。

20.10 配置消息存储分区

邮箱存储在消息存储分区，即专门用于存储消息存储的磁盘分区的区域。虽然为了易于维护，我们建议每个消息存储分区使用一个磁盘分区和一个文件系统，但是消息存储分区与磁盘分区并不相同。消息存储分区是专门指定为消息存储的目录。

默认情况下，用户邮箱存储在 store_root/partition/ 目录中（请参见20.2 消息存储目录布局）。partition 目录是可能包含一个或多个分区的逻辑目录。在启动时，partition 目录包含一个名为 primary 分区的子分区。

您可以根据需要向 partition 目录添加分区。例如，您可能希望对单个磁盘进行分区以组织您的用户，如下所示：

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. 确保在迁移进程期间用户与其各自的邮箱断开了连接。可以通过通知用户在邮箱移动期间注销或脱机来完成此操作，或者通过设置 mailAllowedServiceAccess 属性以便在注销后不允许使用 POP、IMAP 和 HTTP 服务。（请参见《Sun Java Communications Suite 5 Schema Reference》中的“mailAllowedServiceAccess”。

   ---

   注 –

   将 mailAllowedServiceAccess 设置为不允许 POP、IMAP、HTTP 访问不会断开与邮箱的任何开放连接。移动邮箱前必须确保关闭所有连接。

   ---

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. 通知用户现在允许消息存储连接。如果可用，则更改 mailAllowedServiceAccess 属性以允许 POP、IMAP 和 HTTP 服务。

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 实例的用户邮箱。消息存储的大小随邮箱、文件夹和日志文件的数量的增加而增加。

向系统添加更多用户时，磁盘存储要求会相应增加。根据服务器支持的用户的数量，消息存储可能需要一个物理磁盘或多个物理磁盘。Messaging Server 使您可以根据需要添加更多存储。添加更多存储的一种方法是使用存储设备。有关如何使用 Messaging Server 配置 Network Appliance 存储设备的信息，请参见《Using NetApp Filers with Sun Java System Messaging Server Message Store》。

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 的级别之前的目录级别。实用程序会将路径信息发送到标准输出。

例如，要查找用户 crowe 的邮箱的相对路径，请运行以下命令：

hashdir crowe

20.11.2.4 readership 实用程序

readership 实用程序将报告有多少用户（而不是邮箱拥有者）已经阅读了共享 IMAP 文件夹中的邮件。

IMAP 文件夹的拥有者可以授予其他用户阅读文件夹中的邮件的权限。允许其他用户访问的文件夹称为共享文件夹。管理员可以使用 readership 实用程序查看有多少用户（而不是拥有者）正在访问共享文件夹。

此实用程序将扫描所有邮箱并为每个共享文件夹生成一行输出，报告阅读者的数量，接着是一个空格和邮箱的名称。

每个阅读者都是在过去的指定天数内选择了共享文件夹的独特验证身份。用户阅读自己的个人邮箱时系统不进行计数。系统不报告个人邮箱，除非至少有一个文件夹拥有者以外的阅读者。

例如，以下命令行将在过去 15 天内选择了共享 IMAP 文件夹的任何身份都作为阅读者进行计数：

readership -d 15

20.11.3 邮箱最大大小

一个邮箱的最大大小可以容纳约一百万封邮件。超过此限制将导致邮件无法传送给用户，并且可能会导致消息存储库性能问题。有关详细信息，请参见20.14.4.7 由于邮箱溢出而无法传送邮件。

20.11.4 监视配额限制

通过使用 imquotacheck 监视配额使用情况和限制，此实用程序生成一个报告，其中列出了已定义的配额和限制，并提供有关配额使用情况的信息。以千字节为单位报告配额和使用情况数字。此实用程序也可以将邮箱大小与用户分配的配额进行比较。此外，您可以选择通过电子邮件向已超出的配额量达到所设置的百分比的用户发送通知。

在 imquotacheck 中某些功能已更改。（在 Messaging Server 6.x 中，imquotacheck 实用程序已取代了 quotacheck 实用程序。）在 Messaging Server 5.x 中，当您使用 quotacheck 实用程序检索用户列表时，quotacheck 搜索本地 mboxlist 数据库。此功能重复 mboxutil 实用程序中的搜索功能。

在 Messaging Server 6.x 中，此重复功能已从 imquotacheck 实用程序中删除。如果您使用 imquotacheck 执行用户搜索，将针对 LDAP 目录执行搜索，而不是针对本地 mboxlist 数据库。要从本地 mboxlist 数据库检索用户列表，请使用 mboxutil 实用程序。

要列出配额超出规则文件中的最小阈值的所有用户的使用情况，请运行以下命令：

imquotacheck

列出域 siroe.com 的配额信息：

imquotacheck -d siroe.com

要依据默认规则文件向所有用户发送通知，请运行以下命令：

imquotacheck -n

要根据指定的 rulefile、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 由于重复存储相同的邮件而减少消息存储大小

将某邮件发送给多个收件人时，该邮件将被置于每个收件人的邮箱中。某些邮件服务系统将同一邮件的副本分别存储在每个收件人的邮箱中。相反地，Sun Java System Messaging Server 力求保留一个邮件副本，而不考虑该邮件所在的邮箱数。通过在包含该邮件的邮箱中创建指向该邮件的硬链接即可实现此目的。

在将其他邮件服务系统迁移到 Sun Java Messaging Server 时，可能会在迁移过程中将这些多个邮件副本复制到 Sun Java Messaging Server 中。消息存储会很大，这意味着不必要地重复了很多邮件。此外，在正常的服务器操作中也可能会积累同一邮件的多个副本，例如，从 IMAP append操作或其他来源中。

Messaging Server 提供了一个名为 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 消息存储摘要系统信息库

对于这封邮件，链接计数为三。如果从 fredb 和 gregk 邮箱中删除了这两封相同邮件，则链接计数为一并且可以清除此邮件。

还可以在实时模式下运行 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 必须计算每封邮件的摘要—有关配置 relinker 条件的信息，请参见20.11.7.4 配置 relinker。例如，处理 100 千兆字节的消息存储可能需要花费六个小时。但是，如果启用了运行时重链接，请参见20.11.7.3 在实时模式下使用 relinker。

如果单独使用 relinker 命令行模式，而不使用运行时选项，则必须清除摘要系统信息库 (=md5)，否则存储 (=user) 中清除的邮件所占用的空间将不能成为可用磁盘空间，因为在摘要系统信息库中仍有这些邮件的链接（它们将成为孤立邮件）。如果只执行存储的一次性优化（例如，在迁移后），您可以运行一次 relinker，然后使用 relinker -d 删除整个系统信息库。对于迁移过程中进行的重复清除，只要重复运行 relinker 命令就可以了，因为每次运行该命令时，还会从系统信息库中清除过期的或孤立的邮件。

并行运行 relinker 的多个实例来使每个实例分别处理不同分区（使用 -p 选项），这样做是最安全的。仅在同一分区内重链接邮件。

20.11.7.3 在实时模式下使用 relinker

通过将 configutil 参数 local.store.relinker.enabled 设置为 yes 可以在实时模式下启用 relinker 函数。在实时模式下使用 relinker 将计算符合配置的 relinker 条件（20.11.7.4 配置 relinker）的每封已传送（或已恢复、IMAP 已附加等）邮件的摘要，然后查找系统信息库以查看该摘要是否已存在。如果摘要存在，relinker 将在目标邮箱中创建一个指向该摘要的链接而不创建该邮件的新副本。如果摘要不存在，relinker 将创建该邮件，然后在系统信息库中添加指向该邮件的链接。

stored 将扫描每个分区的摘要系统信息库，并清除链接计数为 1 或不符合 relinker 条件的邮件。在可配置的时间段内，扫描一次将扫描完一个目录。这样可以平均分布 I/O 负载而不会对其他服务器操作造成明显影响。默认情况下，清除周期为 24 小时，这意味着从存储中删除了邮件或者邮件超过了配置的最大生存期后，这些邮件最多还可在磁盘上保存 24 小时。如果启用了 relinker 实时模式，将启用此任务。

20.11.7.4 配置 relinker

表 20–11 显示了用于设置 relinker 条件的参数。

20.12 备份并恢复消息存储

消息存储备份和恢复是最常见和最重要的管理任务之一。它由备份消息存储中的所有邮件和文件夹组成。必须实现消息存储的备份和恢复策略，以确保发生以下问题时不会丢失数据：

• 系统崩溃

• 硬件故障

• 邮件或邮箱的意外删除

• 重新安装或升级系统时出现问题

• 自然灾难（例如，地震、火灾、飓风）

• 迁移用户

您可以使用命令行实用程序 imsbackup 和 imsrestore，或集成解决方案（使用 Legato Networker^TM）执行消息存储备份和恢复。

Messaging Server 提供了单副本备份过程。不管多少用户文件夹包含特定邮件，备份期间仅使用找到的第一封邮件文件备份一次邮件文件。第二封邮件副本将作为第一封邮件文件名称的链接备份，依此类推。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:00 AM）可能是安排备份的最佳时段。

20.12.1.2 完全备份和增量备份

增量备份（请参见增量备份）将扫描存储查找更改的数据，并仅备份已经更改的内容。完全备份将备份整个消息存储。需要确定与增量备份相比系统执行完全备份的频率。您可能需要将增量备份作为每日维护过程执行，而每星期执行一次完全备份。

20.12.1.3 并行备份和串行备份

用户数据存储在多个磁盘中时，如果需要，可以并行备份用户组。根据系统资源，并行备份可以加速整体备份过程。但是，如果要减少备份对服务器性能的影响，可能需要使用串行备份。使用并行备份还是串行备份可能取决于许多因素，包括系统负载、硬件配置、有多少可用的磁带驱动器等等。

20.12.2 创建备份组

备份组是由正则表达式定义的任意用户邮箱集。通过将用户邮箱组织成备份组，您可以定义更灵活的备份管理。

例如，您可以创建三个备份组，第一个组包含以字母 A 至 L 开始的用户 ID，第二个组包含用户 ID 以 M 至 Z 开始的用户，而第三个组包含用户 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
.
.
.

使用上述段落中介绍的示例，以下定义将用于创建三个备份组：

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 指定一个值。

您可以指定单个邮箱或由 '%' 字符分隔开的邮箱列表。（在邮箱名称中 '%' 是非法字符。）例如，您可以指定以下值：

Trash

Trash%Bulk Mail%Third Class Mail

在第一个示例中，排除了文件夹 Trash。在第二个示例中，排除了文件夹 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

“垃圾箱”文件夹被排除。

20.12.5 部分恢复的注意事项

部分恢复是指仅恢复部分消息存储。完全恢复是指恢复整个消息存储。消息存储使用单副本邮件系统。即，仅将任何邮件的单个副本作为单个文件保存在存储中。该邮件的任何其他实例（如邮件发送到多个邮箱时）都存储为该副本的链接。由于此原因，恢复邮件时会有一些影响。例如：

• 完全恢复。完全恢复期间，链接的邮件仍将指向同一个索引节点，将其作为它们要链接到的邮件文件。

• 部分备份/恢复。但是，部分备份和部分恢复期间可能不会保留消息存储的单副本特征。

以下示例说明了执行部分恢复时，由多个用户使用的邮件发生的变化。假设有三封邮件，同时属于三个用户 A、B 和 C，如下所示：

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 编号，并且邮件数据被写入磁盘上的新位置。仅恢复了一封邮件；第二封邮件是第一封邮件的硬链接。

示例 2。在此示例中，系统执行完全备份和部分恢复，如下所示：

1. 执行完全备份。

2. 删除用户 A 的邮箱。

3. 恢复用户 A 的邮箱。

A/INBOX/1 被指定了新的索引节点编号。

示例 3。在此示例中，部分恢复可能需要多次尝试：

1. 执行完全备份。

   将 B/INBOX/1 和 C/INBOX/1 备份为 A/INBOX/1 的链接。

2. 删除用户 A 和 B 的邮箱。

3. 恢复用户 B 的邮箱。

   恢复实用程序要求管理员首先恢复 A/INBOX。

4. 恢复用户 A 和 B 的邮箱。

5. 删除用户 A 的邮箱（可选）。

   ---

   注 –

   如果要确保对所有邮件进行部分恢复，可以运行 imsbackup 命令并使用 -i 选项。如果有必要，-i 选项将多次备份每封邮件。

   如果备份设备（如：驱动器或磁带）可查找，imsrestore 将查找包含 A/INBOX/1 的位置，并将其恢复为 B/INBOX/1。如果备份设备（如：UNIX 管道）不可查找，imsrestore 将日志记录对象 ID 和文件的相关（链接）对象的 ID，并且管理员必须使用 -r 选项再次调用 imsrestore 以恢复缺少的邮件引用。

   ---

20.12.5.1 从已被增量备份的邮箱中恢复邮件

如果您正从已被增量备份的邮箱中恢复邮件，并且该邮箱存在于您要用于恢复邮件的服务器上，那么恢复邮件需要简单而直观的运行 imesrestore。但是如果您要从已被增量备份的邮箱中恢复邮件，并且该邮箱不再存在，则必须遵循不同的恢复过程。

使用以下过程之一将邮件恢复至不存在于消息存储服务器上的邮箱中：

• 在恢复操作期间，禁用邮件向用户传送。通过将 LDAP 属性 mailDeliveryOption 设置为 hold 来实现该操作。

• 在使用 imesrestore 之前，应使用 mboxutil -c 命令创建邮箱。

恢复增量备份必须遵循这些说明的原因如下：在邮箱已被删除或正被迁移时，imsrestore 实用程序将使用存储在备份归档文件中的邮箱唯一标识有效性标志和邮件唯一标识 (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 为备份和恢复消息存储数据提供了可以由 Legato Networker 的 save 和 recover 命令调用的应用程序特定模块 (Application Specific Module, ASM)。然后，ASM 将调用 Messaging Server 的 imsbackup 和 imsrestore 实用程序。

本节提供有关如何将 Legato Networker 与 Messaging Server 消息存储一起使用的信息。要了解 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

   以下示例显示了 /nsr/res 目录中名为 IMS.res 的样例 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. 选择“自定义”|“组”|“创建”。

6. 使用 savepnpc 作为备份命令创建备份客户端：

   1. 将保存组设置为由 mkbackupdir 创建的目录。

      对于单个会话备份，使用 /backup

      对于并行备份，使用 /backup/server/group

      确保已经创建如20.12.2 创建备份组中所定义的 group

      还必须设置备份会话数量的并行性。

      请参见使用 Legato Networker 备份数据。

7. 选择“组控制”|“启动”以测试备份配置。

   示例：在 Networker 中创建备份客户端：

   要在 Networker 中创建备份客户端，从 nwadmin 选择“客户端”|“客户端设置”|“创建”

   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)。运行单个 imbackup 备份整个消息存储的大型消息存储将花费相当长的时间。Legato 解决方案支持多个备份设备上的并行备份会话。并行备份可以显著缩短备份时间（可达到每小时可备份 25GB 数据）。

如果使用的是其他第三方并行备份软件（例如，Netbackup），可以使用以下方法将备份软件与 Messaging Server 集成。

使用除 Legato 以外其他的第三方备份软件

1. 将用户分成组（请参见20.12.2 创建备份组），并在 msg-svr-base/config/ 目录下创建 backup-groups.conf 文件。

   ---

   注 –

   此备份解决方案需要附加的磁盘空间。要并行备份所有组，磁盘空间要求将是消息存储大小的两倍。如果没有足够的磁盘空间，请将用户分成较小的组，然后一次备份一个组集。例如 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 不支持大型文件，如果备份数据大于 2 GB，则需要使用 -f- 选项将数据写入 stdout 然后将输出传输到一个文件中。

3. 使用第三方备份软件以备份中转区（在我们的示例中是 /bkdata）中的组数据文件。

4. 要恢复用户，请标识用户的组文件名，从磁带恢复该文件，然后使用 imsrestore 从数据文件恢复用户。

   注意，imsrestore 不支持大型文件。如果数据文件大于 2GB，请使用以下命令：

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

20.12.8 备份和恢复问题的故障排除

本节介绍常见的备份和恢复问题及其解决方法。

• 问题：当使用 imsrestore 或 imsasm 恢复文件夹或 INBOX 时，它会把该文件夹中所有的邮件附加至当前文件夹。这将导致该文件夹中存在这些邮件的多个副本。

  解决方案：确保 imsasm 脚本中未设置 imsrestore 的 -i 标志。

• 问题：我只想对邮件文件夹中新添加的邮件进行增量备份，但当我进行尝试时，整个文件夹都进行了备份。如何只备份新添加的邮件呢？

  解决方案：在 imsbackup 上设置 -d datetime 标志。这将备份从指定日期和时间至今所存储的邮件。默认情况下将备份所有邮件而不考虑它们的日期。

20.12.9 消息存储灾难备份和恢复

灾难是指整个消息存储而非一个邮箱或一组邮箱的灾难性故障。即消息存储服务器上的所有数据全部丢失的情况。完整的消息存储灾难恢复将包含恢复以下丢失的数据：

• 所有消息存储数据。可以使用20.12 备份并恢复消息存储中描述的过程备份这些数据。如果使用了文件系统备份方法，请确保备份以下数据：

  • 所有消息存储分区

  • 位于 msg-svr-base/data/store/mboxlist 的消息存储数据库文件。

  • 位于 msg-svr-base/data/store/dbdata/snapshots 的消息存储数据库快照（请注意，可以使用 configutil 参数 local.store.snapshotpath 配置消息存储数据库快照文件的位置。）

• 配置数据。包括位于 msg-svr-base/data/config 的本地配置文件

如果您想备份消息存储供灾难恢复时使用，您可以使用文件系统快照工具备份一个文件系统快照。快照必须是快速及时点 (point-in-time) 文件系统快照。否则，将无法使用 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

以下命令可以完成两项任务：1) 确定指定用户当前是否已通过 IMAP 或 Messenger Express 或者任何通过 mshttp 连接的客户端登录（请注意，此项不适用于 POP，因为 POP 用户通常不保持连接），2) 列出用户上次登录和注销的时间：

# imsconnutil -c -a -u user_ID

请注意，使用以下命令可以从文件输入用户列表，每行一个用户：

# imsconnutil -c -a -f filename

您还可以使用 -s 标志指定特定服务（imap 或 http）。例如，要列出特定用户 ID 是否已登录 IMAP，使用以下命令：

# imsconnutil -c -s imap -u user_ID

请注意，-k 选项只有在已配置 IMAP IDLE 的情况下才起作用。有关 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.2 消息存储启动和恢复

• 20.14.3 修复邮箱和邮箱数据库

• 20.14.4 常见问题和解决方案

20.14.1 标准消息存储监视过程

本节概述了消息存储的标准监视过程。这些过程有助于常规消息存储检查、测试和标准维护。

有关其他信息，请参见27.7 监视消息存储。

20.14.1.1 检查硬件空间

消息存储应具有足够的附加磁盘空间和硬件资源。消息存储接近磁盘空间和硬件空间的最大限度时，消息存储内部可能会出现问题。

磁盘空间不足是导致邮件服务器问题和故障的最常见的原因之一。如果没有用于写入到消息存储的空间，邮件服务器将会失败。此外，可用磁盘空间低于特定阈值时，会产生与邮件传送、日志记录等相关的问题。当 stored 进程的清除功能失败并且不从消息存储中擦除已删除的邮件时，磁盘空间会迅速耗尽。

有关监视磁盘空间的信息，请参见20.11.5 监视磁盘空间和27.7 监视消息存储。

20.14.1.2 检查日志文件

检查日志文件以确保消息存储进程按配置运行。Messaging Server 为其支持的以下每个主要协议（或服务）都创建了一组单独的日志文件：SMTP、IMAP、POP 和 HTTP。您可以在目录 msg-svr-bas/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

请注意，目录必须由邮件传送服务器 userid 拥有和重写。

Messaging Server 将在此目录中为每个会话创建一个文件。下面显示了输出示例：

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 进程是否在运行。运行 imcheck

• 检查在 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 中）。如果日志文件堆积，则不会出现数据库检查点操作。通常，单个时间段内存在两个或三个数据库日志文件。如果有更多文件，则可能是问题的征兆。

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 将分析其完整性，并将状态消息发送到警告类别下的默认日志。某些邮件将对管理员很有用，某些邮件将由用于内部分析的编码数据组成。如果 stored 检测到任何问题，则将尝试修复数据库并尝试再次启动数据库。

打开数据库时，stored 将以信号表明其余服务可以启动。如果自动修复失败，默认日志中的消息将指定要采取的措施。请参见表示需要 reconstruct 的错误消息。

在以前的版本中，stored 可能会花费很长时间启动恢复进程，致使管理员怀疑 stored 是否已被“阻塞”。这种长时间的恢复现在已不存在，stored 将在一分钟内确定最终状态。但是，如果 stored 需要使用恢复技术（例如从快照恢复），则进程可能会花费几分钟时间。

大多数恢复之后，数据库通常会更新，并且不需要进行任何其他操作。但是，某些恢复需要 reconstruct -m 以便与消息存储中的冗余数据同步。同样，这会在默认日志中说明，因此启动后监视默认日志非常重要。即使消息存储看起来启动和运行正常，运行任何要求的操作（例如 reconstruct）都是很重要的。

阅读日志文件的另一个原因是可以首先确定导致数据库损坏的原因。尽管 stored 用于调出消息存储，而不管系统中的任何问题，但是您仍要尝试确定导致数据库损坏的原因，因为这可能是更大的隐藏问题的征兆。

表示需要 reconstruct 的错误消息

本节介绍需要运行 reconstruct 的错误消息类型。

错误消息指示邮箱错误时，运行 reconstruct <mailbox>。示例：

“邮箱 user/joe/INBOX 中的邮件 102 的高速缓存数据无效。需要重建”

“邮箱已破坏，缺少固定标题: user/joe/INBOX”

“邮箱已破坏，start_offset 在 EOF: user/joe/INBOX 之外”

当错误消息指示数据库错误时，请运行 reconstruct -m。示例：

“正在删除附加数据库日志。请在启动后立即运行 reconstruct -m 以再同步冗余数据”

“正在从快照恢复数据库。请在启动后立即运行 reconstruct -m 以再同步冗余数据”

数据库快照

快照是数据库的热备份，由 stored 使用以在几分钟内透明地恢复已损坏的数据库。这比使用 reconstruct 要快得多，后者依赖于其他区域中存储的冗余信息。

消息存储数据库快照—操作原理

默认情况下，每 24 小时自动获取一次数据库（位于 mboxlist 目录中）的快照。默认情况下，快照将被复制到 store 目录的子目录中。默认情况下，在任意给定时间有五个快照：一个实时数据库、三个快照和一个数据库/已删除副本。数据库/已删除副本比较新，并且是放入 mboxlist 数据库目录的子目录 removed 中的数据库的紧急副本。

如果恢复进程由于确定数据库已损坏而决定删除当前数据库，stored 会将其移入 removed 目录（如果可以）。此操作允许在需要时对数据库进行分析。

数据移动一周仅发生一次。如果已存在数据库的副本，stored 将不会在每次进行存储时替换副本。仅当 removed 目录中的数据是一星期以前的数据时，才会替换副本。这将防止有问题的原始数据库由于连续启动而被替换得太快。

指定消息存储数据库快照的时间间隔和位置

应有五倍的空间用于组合的数据库和快照。强烈建议管理员重新配置快照以在单独的磁盘上运行，并调节快照以满足系统需求。

如果 stored 在启动时检测到数据库的问题，最好的快照将自动被恢复。有三个快照变量，可以设置以下参数：快照文件的位置、获取快照的时间间隔、保存的快照数量。表 20–13 显示了这些 configutil 参数。

获取快照时间间隔太小将会导致给系统带来频繁的负担，并更有可能会将数据库中的问题复制为快照。获取快照时间间隔太大意味着获取快照时数据库要保持过去的状态。

建议采用一天的快照时间间隔，如果问题将在系统中保存若干天，并且您希望返回问题存在的时间点以前的时段，则一周或更长的快照时间间隔会很有用。

stored 可以监视数据库并且非常智能，如果检测到数据库不够完好，则拒绝最新快照。而将检索最新、最可靠的快照。尽管快照可能是从一天以前检索的，系统将使用更新的冗余数据并覆盖较早的快照数据（如果可用）。

因此，快照所起的最终作用是使系统接近最新，并尝试在运行中重建数据来减轻系统剩余部分的负担。

20.14.3 修复邮箱和邮箱数据库

如果一个或多个邮箱已破坏，您可以使用 reconstruct 实用程序重建邮箱或邮箱数据库，并修复所有不一致性。

reconstruct 实用程序将重建一个或多个邮箱或主邮箱文件，并修复所有不一致性。您可以使用此实用程序恢复邮件存储中几乎所有形式的数据破坏。请参见表示需要 reconstruct 的错误消息。

表 20–14 列出了 reconstruct 选项。有关详细的语法和使用要求，请参见《Sun Java System Messaging Server 6.3 Administration Reference》中的“reconstruct”。

20.14.3.1 重建邮箱

要重建邮箱，请使用 -r 选项。您应在以下情况使用此选项：

• 访问邮箱时返回以下错误之一：“System I/O 错误”或“邮箱格式无效”。

• 访问邮箱时导致服务器崩溃。

• 已经向假脱机目录添加文件或从其中删除文件。

reconstruct -r 首先将运行一致性检查。仅在检测到任何问题时报告所有不一致性并重建。因此，reconstruct 实用程序的性能在此版本内得到了改进。

您可以使用以下示例中所述的 reconstruct：

要重建属于用户 daphne 的邮箱的假脱机区域，请使用以下命令：

reconstruct -r user/daphne

要重建邮箱数据库中列出的所有邮箱的假脱机区域，请使用以下命令：

reconstruct -r

但是，您必须谨慎使用此选项，因为对于大型消息存储，重建邮箱数据库中列出的所有邮箱的假脱机区域将花费很长时间。（请参见20.14.3.3 reconstruct 性能。）故障恢复的更好的方法可能是将多个磁盘用于存储。如果一个磁盘出现故障，整个存储不会出现故障。如果一个磁盘破坏，只需使用 -p 选项重建一个存储的分区，如下所示：

reconstruct -r -p subpartition

要重建命令行参数中列出的邮箱，只要它们位于 primary 分区中，请使用以下命令：

reconstruct -p primary mbox1 mbox2 mbox3

如果确实需要重建 primary 分区中的所有邮箱，请使用以下命令：

reconstruct -r -p primary

如果要强制 reconstruct 程序重建文件夹，而不执行一致性检查，请使用 -f 选项。例如，以下命令将强制执行用户文件夹 daphne 的重建：

reconstruct -f -r user/daphne

要检查所有邮箱而不对其进行修复，请使用 -n 选项，如下所示：

reconstruct -r -n

20.14.3.2 检查并修复邮箱

要执行高级别一致性检查和邮箱数据库的修复，请使用以下命令：

reconstruct -m

要执行主分区的一致性检查和修复，请使用以下命令：

reconstruct -p primary -m

运行 reconstruct 时同时使用 -P 和 -m 标记将不能修复 lright.db。这是因为修复 lright.db 需要对消息存储中的每个用户进行 ACL 扫描。为每个分区执行此操作效率不高。要修复 lright.db，请运行 reconstruct -l

要执行名为 john 的单个用户的邮箱的一致性检查和修复，请执行以下命令：

reconstruct -p primary -u john -m

您应在以下情况下使用 -m 选项：

• 从存储假脱机区域删除了一个或多个目录，因此也需要删除邮箱数据库条目。

• 一个或多个目录被恢复到存储假脱机区域，因此也需要添加邮箱数据库条目。

• 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 个用户、85GB 的消息存储和在服务器上并行的 POP、IMAP 或 SMTP 活动的系统具有如下性能：

• reconstruct -m 花费大约 1 小时

• reconstruct -r -f 花费大约 18 小时

如果服务器不执行正在进行的 POP、IMAP、HTTP 或 SMTP 活动，reconstruct 操作可能会明显花费较少的时间。

20.14.4 常见问题和解决方案

本节列出了常见的消息存储问题和解决方案：

• 20.14.4.1 Linux - Messaging Server Patch 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 Patch 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.

为所有三个服务器会话设置相应数目的文件描述符。通过向 /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 shell 可能需要用引号引起通配符参数，某些则不需要。例如，C shell 尝试将包含通配符（*、?）的参数扩展为文件，如果未找到任何匹配项，则将失败。这些模式匹配参数可能需要包含在引号中，以传递给命令（如 mboxutil）。

例如：

mboxutil -l -p user/usr44*

将在 Bourne shell 中运行，但在 tsch 和 C shell 中将失败。这些 shell 可能需要以下命令：

mboxutil -l -p "user/usr44*"

如果使用通配符模式的命令不起作用请验证是否需要为该 shell 的通配符使用引号。

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 Command-line Utilities" 一章中的 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 文件设置了 2 千兆字节的硬性限制，这等效于在一个邮箱（文件夹）中可以存放一百万封邮件。当邮箱增长到 store.idx 文件将超过 2 千兆字节的那一点时，用户将停止接收任何新的电子邮件。此外，处理该邮箱的其他进程（如 mapd、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 将邮箱迁移或移动到新系统

有时必须将现有邮箱从一个 Messaging Server 系统移动到另一个 Messaging Server 系统中。这通常发生于以下情况：

• 从非 Sun Messaging Server 迁移到 Sun Java System Messaging Server

• 将邮箱从一个物理服务器移动到另一个物理服务器

Messaging Server 提供了若干种将邮箱从一个系统移动到另一个系统的方法。每种方法都有它的优点和缺点，这将在以下小节中进行说明。下面的小节介绍了这些方法：

• 20.15.1 在联机状态下将用户邮箱迁移到其他 Messaging Server

• 在保持联机状态下将用户邮箱从一个 Messaging Server 迁移到另一个 Messaging Server 中

• 使用 IMAP 客户端移动邮箱

• 使用 moveuser 命令移动邮箱

• 使用 imsimport 命令移动邮箱

20.15.1 在联机状态下将用户邮箱迁移到其他 Messaging Server

可以使用此过程将消息存储从旧版本的 Messaging Server 迁移到较新版本的 Messaging Server，也可以将邮箱从一个 Sun Messaging Server 消息存储移动到另一个 Sun Messaging Server 消息存储。此过程适用于 iPlanet Messaging Server 5.0 和更高版本。不能使用此过程从早期版本的 Messaging Server 或非 Sun Microsystems 消息存储中移动邮件。

使用此过程移动邮箱的优点如下所示：

• 无需用户参与，系统管理员即可将邮箱从旧的源系统移动到新的目标系统。

• 此过程比任何其他过程都快。

• 如果要移动整个分区，则不需要进行重新链接。

• 两个 Messaging Server 系统都处于活动和联机状态。

• 您可以迁移消息存储上的所有邮箱或这些邮件的某个子集。此过程可以实现增量迁移。

使用此过程移动邮箱的缺点如下所示：

• 此方法不适用于非 Sun 邮件服务器。

• 所迁移的用户在自己的邮箱完成迁移之前，将无法访问这些邮箱。

• 此方法可能很复杂且费时。

20.15.1.1 增量邮箱迁移

增量迁移具有许多优点，可以安全有效地将消息存储移动到其他系统中或升级到新系统；增量迁移允许在保留旧后端消息存储的同时构建新的后端消息存储系统。您可以随后测试新系统，迁移一些友好用户，然后再次测试新系统。在适应了新系统、新配置和迁移过程之后，即可开始迁移实际的商业用户。可以将这些用户分成单独的备份组，这样在迁移过程中，只有此组的成员在短时间内处于脱机状态。

联机增量迁移的另一个优点是，不必在升级失败时规划系统范围的回退。回退是用于恢复对系统所做更改的过程，以便将系统恢复到原始工作状态。进行迁移时，您必须针对故障进行规划，这意味着必须对迁移中的每个步骤进行规划，以便将系统恢复到先前的工作状态。

脱机迁移的问题是，在完成所有迁移步骤并重新启用服务之前，无法确定迁移是否成功。如果系统出现故障且无法立即修复，则需要回退所有已执行的步骤。这可能会给您带来压力，并且需要花费一些时间，而在这段时间内用户仍处于脱机状态。

使用联机增量迁移时，您需要执行以下基本步骤：

1. 构建与旧系统并存的新系统，以使两个系统可以独立运行。

2. 配置旧系统，使之与新系统并存。

3. 迁移一组友好用户，并测试新系统及其与旧系统的并存情况。

4. 对旧系统上的用户进行分组，并根据需要将这些组逐个迁移到新系统中。

5. 对旧系统进行反汇编。

由于两个系统将会并存，因此在迁移到新系统之前，您将有时间来测试和适应新系统。如果必须执行回退过程（这种可能性很小），则只需对步骤 2 和 步骤 4 进行规划。由于未涉及到用户数据，因此步骤 2 很容易恢复。在步骤 4 中，回退过程会将用户状态恢复为活动状态，并将其 mailhost 属性恢复为旧主机。不必执行系统范围的回退。

20.15.1.2 联机迁移概述

在联机状态下迁移邮箱的过程非常简单。但要确保在迁移过程中传输到邮箱的邮件（在 MTA 通道队列中等待传送）不会丢失，则情况会比较复杂。一种解决方案是，以 held 状态保留迁移过程中发送的邮件，并等待各个通道队列中的邮件传送出去。但是，邮件可能会由于系统问题或特定用户超过配额而阻塞在队列中。在这种情况下，您必须在迁移邮箱之前解决此问题。

您可以采取各种措施来降低邮件丢失的可能性，并确保邮件不会阻塞在通道队列中，但这些措施会使迁移过程变得更加复杂。

此过程中的步骤的顺序和必要性会有所不同，具体取决于部署以及是否不允许丢失发送到每个邮箱的每封邮件。本节介绍了与这些步骤相关的理论和概念。您必须了解每个步骤，并根据您的特定部署来确定要执行的步骤以及执行顺序。以下是对移动邮箱过程的概述。此过程可能会根据部署的不同而有所不同。

1. 阻止用户访问要移动的邮箱。

2. 暂时保留发送到要移动的邮箱的邮件。

3. 确保邮件未阻塞在通道队列中。

4. 将用户的 mailhost 属性更改为新的邮箱位置。

5. 将邮箱移动到新位置。

6. 释放所保留的邮件，以便将其传送到新邮箱，并使外来邮件能够传送到已迁移的邮箱。

7. 检查旧的消息存储，以查看在迁移后是否将邮件传送到此存储中。

8. 取消阻止用户对邮箱的访问。

在保持联机状态下将用户邮箱从一个 Messaging Server 迁移到另一个 Messaging Server 中

开始之前

此类型迁移的要求如下所示：

• stored 应同时在源（旧）邮件服务器和目标（新）邮件服务器上运行。

• 如果源系统和目标系统并存运行，则这两种系统必须能够互相发送邮件。这一点很有必要，举例来说，如果能够互相发送邮件，即可在目标系统上生成传送状态通知邮件，然后将其传送到源系统。

某些步骤只有在将邮件服务器从早期版本升级到较高版本时才适用。如果只是将邮箱从一个消息存储迁移到另一个消息存储，则这些步骤可能不适用。适用于迁移整个系统的步骤将会特别指出。

1. 在源系统中，使用 backup-groups.conf 文件将要移动的用户条目分为均等的备份组。

   此步骤是邮箱迁移（将在此过程后面执行的步骤 8）的准备过程。有关详细说明，请参见20.12.2 创建备份组。

   也可以将用户名置于文件中，然后在 imsbackup 命令中使用 -u 选项。

2. 通知要移动的用户在移动完成之前无法访问他们的邮箱。

   确保要移动的用户在数据移动之前已从邮件系统注销。（请参见20.13 监视用户访问。）

3. 在后端消息存储和 MMP 系统上将验证缓存超时设置为 0，并在 MTA 上将 ALIAS_ENTRY_CACHE_TIMEOUT 选项设置为 0。

   1. 在包含要移动的邮箱的后端消息存储上，将验证缓存超时设置为 0。

      configutil -o service.authcachettl -v 0

      此步骤和步骤 7（将 mailUserStatus 更改为 hold）将立即阻止用户在迁移期间访问其邮箱。

   2. 在所有 MMP 上，将 LDAP 和验证缓存超时设置为 0。

      在 ImapProxyAService.cfg 和 PopProxyAService.cfg 中，将 LdapCacheTTL 和 AuthCacheTTL 设置为 0。

   3. 在托管 MTA（可将邮件插入到要迁移的邮箱中）的任意 Messaging Server 上，将 ALIAS_ENTRY_CACHE_TIMEOUT 选项设置为 0。

      托管 MTA（可将邮件插入到要迁移的邮箱中）的 Messaging Server 通常是后端消息存储。但是，如果系统使用的是 LMTP，则此系统将是入站 MTA。检查配置以确保正确无误。

      重置 /msg_svr_base /config/option.dat 中的 ALIAS_ENTRY_CACHE_TIMEOUT 可以强制 MTA 避开缓存而直接查看 LDAP 条目，从而使中间通道队列（例如，conversion 或 reprocess 通道）可以查看所移动用户的新 mailUserStatus (hold) ，而不是过期的缓存信息。ALIAS_ENTRY_CACHE_TIMEOUT 位于 option.dat 中。

   4. 重新启动重置了缓存的系统。

      必须重新启动系统以使上述更改生效。有关说明，请参见4.4 启动和停止服务。

4. 确保源 Messaging Server 和目标 Messaging Server 已启动并且正在运行。

   源 Messaging Server 必须能够将外来邮件路由到新的目标服务器。

5. 将要移动邮箱的所有用户条目的 LDAP 属性 mailUserStatus 由 active 更改为 hold。

   更改此属性可以使外来邮件保留在 hold 队列中，并可防止通过 IMAP、POP 和 HTTP 访问邮箱。通常以用户组的形式移动用户。如果移动单个域的所有邮箱，则可以使用 mailDomainStatus 属性。

   有关 mailUserStatus 的更多信息，请参见《Sun Java Communications Suite 5 Schema Reference》中的“mailUserStatus”。

6. 确保发送到迁移邮箱的邮件未阻塞在 ims-ms 或 tcp_lmtp* 通道队列中（如果已部署 LMTP）。

   使用以下命令查看发送到迁移用户的邮件是否存在于通道队列目录树中，并且处于 held 状态（查看 .HELD 文件）：

   imsimta qm directory -to=<user_address_to_be_migrated> -directory_tree imsimta qm directory -to=<user_address_to_be_migrated> -held -directory_tree

   如果此队列中有邮件，请在稍后运行相同命令来查看 MTA 是否已将这些邮件移出队列。如果有未移出队列的邮件，则必须在迁移之前解决此问题。这种问题很少发生，但可能的原因有以下几点：收件人邮箱超过配额、邮箱被锁定（可能由于用户已登录并且正在移动邮件）、LMTP 后端服务器未响应、网络或名称服务器问题等等。

7. 更改要移动的用户条目以及任何邮件组条目中的 LDAP 属性 mailHost*。

   使用 ldapmodify 命令将条目更改为新的邮件服务器。使用 Messaging Server 或目录服务器附带的 ldapmodify。不要使用 Solaris 操作系统的 ldapmodify 命令。

   * 如果关闭了旧邮件主机，则只需更改邮件组条目中的 mailHost 属性。可以将此属性更改为新的邮件主机名，也可以干脆删除此属性。对于邮件组而言，mailHost 是可选的。具有 mailHost 意味着只有该主机可以进行组扩展；而忽略 mailHost（此种情况较为常见）则意味着所有 MTA 都可以进行组扩展。请注意，邮件组条目不包含要迁移的邮箱，通常甚至没有 mailhost 属性。

   有关 mailhost 的更多信息，请参见《Sun Java Communications Suite 5 Schema Reference》中的“mailHost”。

8. 将邮箱数据从源 Messaging Server 消息存储移动到目标 Messaging Server 消息存储，并记录开始时间。

   使用 imsbackup 实用程序备份邮箱，并使用 imsrestore 实用程序将其恢复到新的 Messaging Server 中。例如，要将邮箱从名为 oldmail.siroe.com 的 Messaging Server 5.2 系统迁移到 newmail.siroe.com，请在 oldmail.siroe.com 上运行以下命令：

   /server-root/bin/msg/store/bin/imsbackup -f- /instance/group \ | rsh newmail.siroe.com /opt/SUNWmsgsr/lib/msg/imsrestore.sh \ -f- -c y -v 1

   您可以运行多个并发的备份和恢复会话（每组一个），以使传送到新消息存储的速率达到最大化。有关 imsbackup 和 imsrestore 实用程序以及20.12 备份并恢复消息存储的更多信息，请参见《Sun Java System Messaging Server 6.3 Administration Reference》中的“Command Descriptions”。

   ---

   注 –

   记录 imsbackup 开始运行的时间戳，用于以后的传送验证。

   ---

9. （系统升级的条件式步骤）如果邮箱迁移是升级（从早期版本的 Messaging Server 升级到当前版本）过程的一部分，请将当前版本的 Messaging Server 设置为新的系统默认 Messaging Server。

   将 oldmail.siroe.com 的 DNS A 记录更改为指向 newmail.siroe.com（此服务器负责先前托管在 oldmail.siroe.com 上的域）。

10. 启用用户对新消息存储的访问。

    如果适用，将 LDAP 属性 mailUserStatus 或 mailDomainStatus 设置为将其更改为 hold 之前的任意值（如 active）。

11. 释放所有源 Messaging Server 上处于 held 状态的邮件。

    任何可能保留外来邮件的系统都需要运行以下命令，以释放所有用户邮件：

    imsimta qm release -channel=hold -scope

    其中，scope 可以是 all（释放所有邮件）、user（用户 ID）或 domain（用户所在的域）。

12. 将验证缓存超时和 ALIAS_ENTRY_CACHE_TIMEOUT 选项重置为默认值或所需值，然后重新启动系统。

    此时，您已经迁移了需要迁移的所有用户邮箱。在继续操作之前，请确保 LDAP 中没有使用旧系统作为 mailhost 创建的新条目；如果有，请迁移这些条目。此外，还要确保无法通过修改置备系统来创建此类条目。

    还要将 preferredmailhost 属性更改为新邮件主机的名称。

    对于后端消息存储，请将验证缓存超时设置为以下值：

    configutil -o service.authcachettl -v 900

    对于 MMP，请在 ImapProxyAService.cfg 和 PopProxyAService.cfg 中将 LdapCacheTTL 和 AuthCacheTTL 选项设置为 900。

    对于 MTA，请将 ALIAS_ENTRY_CACHE_TIMEOUT 选项设置为 600。ALIAS_ENTRY_CACHE_TIMEOUT 位于 option.dat 中。

    必须重新启动系统以使上述更改生效。有关说明，请参见4.4 启动和停止服务。

13. 确保用户客户端将指向新的邮件服务器。

    升级完成后，通过用户的邮件客户端程序使用户指向新服务器（在此示例中，使用户从 oldmail.siroe.com 指向 newmail.siroe.com）。

    一种替代方法是使用邮件多路复用器 (MMP)，这样用户可以不必将其客户端直接指向新的邮件服务器。MMP 将从 mailHost 属性（存储在 LDAP 用户条目中）获取该信息，并自动将客户端重定向到新服务器。

14. 一切正常运行之后，请验证在迁移后没有向旧消息存储中传送任何邮件。

    转到旧消息存储并运行 mboxutil -l 以列出邮箱。检查最后的邮件传送时间戳。如果在迁移时间戳（运行 imsbackup 命令时的日期戳）之后传送了邮件，请使用备份和恢复命令迁移这些邮件。由于提供了准备步骤，因此在迁移后极少会出现传送邮件的情况。

    在理论上，邮件可能会在队列中阻塞一段时间，由 notices 通道关键字指定天数和小时数（请参见10.10.4.3 设置通知邮件传送间隔）。

15. 删除新消息存储上的重复邮件，然后运行 relinker 命令。

    此命令可以释放新消息存储上的磁盘空间。请参见20.11.7 由于重复存储相同的邮件而减少消息存储大小。

16. 从迁移的源存储中删除旧邮件，然后从旧存储上的数据库中删除用户。

    运行 mboxutil -d 命令。（请参见20.11.2.1 mboxutil 实用程序。）

使用 IMAP 客户端移动邮箱

无论何时需要将邮件从一个邮件服务器迁移到其他邮件服务器，都可以使用此过程。使用此方法移动邮箱之前，请考虑该方法的优缺点。

使用 IMAP 客户端移动邮箱的优点如下所示：

• 此方法可用于从非 Sun Messaging Server 到 Sun Java System Messaging Server 的迁移。还可以用于将邮箱从一个物理服务器移动到其他物理服务器。

• 系统管理员设置新邮件服务器或消息存储之后，将由用户负责将邮箱移动到新系统。

• 移动邮箱的过程相对简单。

• 不必禁用用户对邮箱的访问。

使用 IMAP 客户端移动邮箱的缺点如下所示：

• 需要新旧系统同时运行，并且可由用户访问。

• 使用此方法移动邮箱所累计花费的时间比使用其他方法长。

• 用户负责将邮箱移动到新系统。

• 执行重新链接操作之前，新消息存储的大小将明显大于旧消息存储。

1. 安装并配置新 Messaging Server。

2. 将 local.store.relinker 设置为启用。

   这样可以减小重复存储相同的邮件而增加的新系统上的消息存储大小。有关更多信息，请参见20.11.7 由于重复存储相同的邮件而减少消息存储大小。

3. 在新 Messaging Server 上置备用户。

   您可以使用 Delegated Administrator 执行此操作。在新系统上置备用户后，新到达的邮件将被立即传送到新的收件箱。

4. 让用户配置其邮件客户端以查看新旧 Messaging Server 邮箱。

   这可能涉及客户端上新电子邮件帐户的设置。有关详细信息，请参见邮件客户端文档。

5. 指导用户将文件夹从其旧 Messaging Server 拖到其新 Messaging Server。

6. 验证用户是否已将所有邮箱迁移到新系统，然后关闭旧系统上的用户帐户。

使用 moveuser 命令移动邮箱

无论何时需要将邮件从一个邮件服务器迁移到其他邮件服务器，都可以使用此过程。将 IMAP 邮箱从非 Sun Messaging Server 迁移到 Sun Java System Messaging Server 时，此过程非常有用。使用此方法移动邮箱之前，请考虑该方法的优缺点。

使用 moveuser 命令移动邮箱的优点如下所示：

• 将邮箱从旧系统移动到新系统的工作完全由系统管理员负责。用户不必进行任何操作。

• 适用于所有 IMAP 服务器。

使用 moveuser 命令移动邮箱的缺点如下所示：

• 需要新旧系统同时运行，并且可由用户访问。

• 与其他非 IMAP 方法相比，使用此方法移动邮箱花费的时间较多。

• 移动邮箱时必须禁用用户对邮箱的访问。

• 执行重新链接操作之前，新消息存储的大小将明显大于旧消息存储。

1. 安装并配置新 Messaging Server。

2. 将 local.store.relinker 设置为启用。

   这样可以减小重复存储相同的邮件而增加的新系统上的消息存储大小。有关更多信息，请参见20.11.7 由于重复存储相同的邮件而减少消息存储大小。

3. 停止向邮件服务器传入邮件。

   将用户属性 mailUserStatus 设置为 hold。

4. 如果需要，在新 Messaging Server 上置备用户。

   如果从以前版本的邮件服务器迁移，则可以使用同一 LDAP 目录和服务器。moveuser 可以更改每个用户条目中的 mailhost 属性。

5. 运行 moveuser 命令。

   要根据 Directory Server siroe.com 中的帐户信息将所有用户从 host1 移动到 host2，请执行以下命令：

   MoveUser -l \ "ldap://siroe.com:389/o=siroe.com???(mailhost=host1.domain.com)" \ -D "cn=Directory Manager" -w password -s host1 -x admin \ -p password -d host2 -a admin -v password

   有关 moveuser 命令的详细信息，请参见《Sun Java System Messaging Server 6.3 Administration Reference》中的“MoveUser”。

6. 启用用户对新邮件服务存储的访问。

   将 LDAP 属性 mailUserStatus 设置为 active。

7. 关闭旧系统。

使用 imsimport 命令移动邮箱

此过程专用于将邮箱从 UNIX /var/mail 格式文件夹移动到 Sun Java System Messaging Server 消息存储。但是，如果您正在从中迁移的邮件服务器可以将 IMAP 消息存储转换为 UNIX /var/mail 格式，则可以使用 imsimport 命令将邮件迁移到 Sun Java System Messaging Server。使用此方法移动邮箱之前，请考虑该方法的优缺点。

使用 imsimport 命令移动邮箱的优点如下所示：

• 将邮箱从旧系统移动到新系统的工作完全由系统管理员负责。用户不必进行任何操作。

使用 imsimport 命令移动邮箱的缺点如下所示：

• 与其他非 IMAP 方法相比，使用此方法移动邮箱花费的时间较多。

• 移动邮箱时必须禁用用户对邮箱的访问。

• 执行重新链接操作之前，新消息存储的大小将明显大于旧消息存储。

1. 安装并配置新 Messaging Server。

2. 将 local.store.relinker 设置为启用。

   这样可以减小重复存储相同的邮件而增加的新系统上的消息存储大小。有关更多信息，请参见20.11.7 由于重复存储相同的邮件而减少消息存储大小。

3. 如果需要，在新 Messaging Server 上置备用户。

   您可以使用 Delegated Administrator 执行此操作。现在还不要切换至新系统。

4. 禁用用户对新旧邮件服务存储的访问。

   将 mailUserStatus LDAP 属性设置为 hold。用户的邮件将被发送到 hold 队列中并且不允许通过 IMAP、POP 和 HTTP 访问邮箱。存储服务器上的 MTA 和 Message Access Server 必须符合此要求。该设置将覆盖所有其他 mailDeliveryOption 设置。

5. 如果现有邮件服务器的邮件存储还不是 /var/mail 格式，请将其转换为 /var/mail 文件。

   请参见第三方邮件服务器文档。

6. 运行 imsimport 命令。

   例如：

   imsimport -s /var/mail/joe -d INBOX -u joe

   有关 imsimport 命令的详细信息，请参见《Sun Java System Messaging Server 6.3 Administration Reference》中的“imsimport”。

7. 启用用户对消息存储的访问。

   将 LDAP 属性 mailUserStatus 设置为 active。

8. 启用用户对新邮件服务存储的访问。

9. 关闭旧系统。