前へ     目次     索引     DocHome     次へ     
iPlanet Messaging Server プロビジョニングガイド



第 2 章   ドメインのプロビジョニング


この章では、iPlanet Message Server のプロビジョニングを行うために必要なドメインおよび組織ユニットを作成する方法を説明します。 これらのユニットの一部はインストール時、または Delegated Administrator の使用時に作成されます。ただし、これらの手順は教育的な目的で記載します。本書では属性の概要のみを説明しています。詳細は、『iPlanet Schema Reference Manual』を参照してください。この章には次の節があります。



ドメインACI

ACI は、DC ツリーおよび組織ツリーの両方のすべてのルートエントリおよびドメインエントリに必要です。 ACI は、さまざまなタイプのユーザおよび管理者と iPlanet Delegated Administrator for Messaging ツールによるディレクトリへのアクセスを制御します。 ユーザ アクセス用 Messenging Server ACI の詳細については、「ACI アーキテクチャ」 を参照してください。

インストール時に、ACI は DC ツリーおよび組織ツリーの両方のルートレベル、および組織ツリーのトップレベルドメイン用にインストールされます ( 付録 A「ルートおよびドメイン ACI の例」を参照)。 これらの ACI は、ノードとすべてのサブノードに適用されます。 したがって、ルートノード上に作成された ACI は、ルートの下のすべてのドメインに適用されます。 ACI 規則は、特定のドメインに対して ldapsearch を実行することによって参照できます。 規則は、ドメインエントリ属性の後に次の形式で表示されます。

#匿名アクセス制御
#
# ユーザエントリへの匿名読み取りおよび検索アクセスを許可します
#
aci: (targetattr != "userPassword")
(targetfilter=(objectClass=nsManagedPerson))
(version 3.0; acl "Anonymous access to User entries";
allow (read,search)
userdn="ldap:///anyone";)
#

この ACI 規則では、オブジェクトクラス nsManagedPerson を含む任意のエントリ内の userPassword 以外は、誰でもすべてを検索して読み取ることができます。 ポンド記号 (#) がある行は、コメントです。 targetattr は、動作する対象の属性を指定します。 targetfilter は、検索対象のオブジェクトクラスです。 version は、ユーザ定義のバージョン番号およびコメントです。 allow は、許可されている権限を一覧表示します (読み取り、書き込み、検索、削除、変更)。 userdn は、これらの属性上で処理を行うユーザを指定します。

ディレクトリ ACI の詳細については、『Netscape Directory Server 4.1 Administratorﾕs Guide』を参照してください。



DC ツリーの作成




DC ツリーノードは、特定のドメインのオペレーティングパラメータ (ルーティングホスト、ディスク制限容量など) と、ドメインのユーザおよびメーリングリスト エントリを含むサブツリーへのポインタを含みます。 DC ツリーは、DNS 構造をミラー化し、デフォルトの DC ツリーがインストール時に作成されます。 新しいホストドメインまたはドメイン組織が作成されますが、DC ツリーおよび組織ツリー内に新しいドメインおよびドメイン組織ノードを作成する必要があります。 これは、iPlanet Delegated Administrator for Messaging コマンド imadmin domain create (コマンドについての詳細は『iPlanet Messaging Server リファレンスマニュアル 』を参照) または iPlanet Delegated Administrator for Messaging コンソール (『iPlanet Delegated Administrator Guide 』を参照) を使用して実行できます。 この節では、LDAP を使用して作成する方法のみを説明します。MX レコードも新しいドメインに追加する必要があります。


DC ツリーのルートドメインエントリの作成



ルートエントリは、ディレクトリツリーのトップレベル ノードです。 DC ツリー内の規則では、ルートを o=internet に設定します。o=internet 以外にルートを指定する場合、メッセージングサーバ構成内の service.dcroot が、必ず DC ツリールートの DN に一致するようにします。 DC ルートを作成するための LDIF レコードを、コード例 2-1 に示します。 DC ツリーおよび組織ツリーのルート ノードはインストール時に作成されますが、ここでは、説明のために LDIF を示します。 デフォルト ACI については、付録 A「ルートおよびドメイン ACI の例」 で説明しています。


Note 一般的に、特定の共通属性には、別名を指定します。 これらは、ディレクトリサーバ構成ディレクトリの属性定義ファイル (*.at.conf) 内で行います。 共通別名には、cn (commonname)、ou (organizationalUnit)、o (organization)、sn (surname)、dn (distinguishedName) が含まれます。


コード例 2-1 DC ツリールートの LDIF レコード
description: Root level node in the Domain Component (DC) tree


DC ツリーのルートエントリ属性とオブジェクトクラス

  • dn: o=internet

    ツリー内のディレクトリエントリを個別に識別する識別名 (dn)。 DC ツリーのデフォルト ルート ノードは o=internet です。

  • objectClass: organization

    DC ツリーのルートノードは、オブジェクトクラス organization によって定義されます。 オブジェクト クラスでは、別の属性をエントリに追加できますが、"o" のみが必要です。 o は、このエントリの dn に設定されている値と同じ値でなければなりません。

    Note すべてのオブジェクトクラスは top オブジェクトクラスを継承するので、エントリの作成のために、 LDIF コードに objectClass: top を含める必要はありません。



DC ツリーのトップレベルドメインエントリの作成



トップレベル ドメインエントリはルートの真下で、DNS ドメインのドメインコンポーネントをミラー化する必要があります。 トップレベル ノードを作成するための LDIF レコードを、コード例 2-2 に示します。ルートノード、トップレベルノード、およびデフォルトドメインノードはインストール時に作成されますが、ここでは、説明のために LDIF を示します。 ACI も作成されます (付録 A「ルートおよびドメイン ACI の例」 を参照)。 コード例 2-2 トップレベルノードの LDIF レコード
dn: dc=com, o=internet
objectClass: domain
dc: com
description: top level .com domain in the DC tree

dn: dc=org, o=internet
objectClass: domain
dc: org
description: top level .org domain in the DC tree


DC ツリーのトップレベルノード属性とオブジェクトクラス

  • dn: dc=com,o=internet
    dn: dc=org,o=internet

    dn は上位レベルドメインノードエントリを指定します。

  • objectClass: domain

    domain オブジェクトクラスは、DC ツリー内のすべてのコンテナエントリを作成するために使用されます (ルートエントリを除く)。


DC ツリーのホストドメインエントリの作成



組織ツリーの各ホストドメインの場合、対応するホストドメインノードも DC ツリー内に作成する必要があります。DC ツリー内にホストドメインを作成する LDIF コードを次に示します。ACI については、付録 A「ルートおよびドメイン ACI の例」を参照してください。 コード例 2-3 DC ツリー内のホストドメインノードの作成用 LDIF レコード

dn: dc=sesta,dc=com,o=internet
objectClass: domain
objectClass: inetDomain
objectClass: mailDomain
objectClass: nsManagedDomain
objectClass: icsCalendarDomain
description: DC node for sesta.com hosted domain
dc: sesta
inetDomainBaseDN: o=sesta.com,o=isp
inetDomainStatus: active
mailDomainStatus: active
mailDomainAllowedServiceAccess: +imap, pop3, http:*
mailRoutingHosts: manatee.siroe.com
preferredMailHost: manatee.siroe.com
mailDomainDiskQuota: 100000000
mailDomainMsgQuota: -1
mailClientAttachmentQuota: 5


DC ツリーホストドメイン属性とオブジェクトクラス

  • dn: dc=sesta, dc=com, o=internet

    dn はツリー内のドメインエントリを固有に識別します。各ホストドメイン構成要素は、ホストドメインの DNS ノードと一致しなければなりません。

  • objectClass: domain
    objectClass: inetDomain
    objectClass: inetDomain
    objectClass: nsManagedDomain
    objectClass: icsCalendarDomain

    これらの行は、dc=sesta エントリを DIT 内に作成するために必要なオブジェクトクラスを指定します。 domain は、コアオブジェクトクラスで、DC ツリーのドメインコンポーネントノードを説明するために役立つ属性を提供します。

    inetDomain は、ホストドメインの追加プロパティを説明する属性を提供します。 このオブジェクト クラスは、DNS ドメインに対応するディレクトリエントリに関連付けられています。

    mailDomain は、ホストドメインアカウントを表し、mailDomain および、オプションで inetDomainAuthInfo と組み合わせて使用して、ホスト組織のメールサービスに適したホストドメインノードを作成します。 このオブジェクトクラスは、すべてのホストドメインエントリで使用する必要があります。

    nsManagedDomain は、iPlanet Delegated Administrator for Messaging によって管理されるドメインの情報を格納します。

    Note ユーザおよびグループデータが DC ツリー内に格納されていて、組織ツリー内に格納されていない場合は、nsManagedDomain オブジェクトクラスおよび関連属性を含める必要があります。 「組織ツリー内のホストドメインエントリの作成」 を参照してください。



ドメイン属性

  • description: DC node for sesta.com hosted domain

    書式設定のないテキスト。 通常は、このエントリの属性 organizationName の値に関連付けられている組織のフルネームです。

  • dc: sesta

    必須な属性。 dc は、このノードの関連 DNS ドメイン構成要素です。


inetDomain 属性

  • inetDomainBaseDN: o=sesta.com,o=ISP

    単一の値の属性。 このホストドメインのすべてのユーザおよびグループエントリが含まれるサブツリーの DN。

  • inetDomainStatus: active

    ホストドメインの現在の状態。 有効な値は、 active、inactive、deletedです。 この属性はグローバルドメインステータスです。 値がない場合は、状態が active であることを示します。 不正な値は inactive として処理されます。 メール ドメインの場合、その他の状態属性は mailDomainStatus です。


mailDomain 属性

  • mailDomainStatus: active

    メールドメインの現在の状態。 これは、次の値のいずれかになります。 active、inactive、deleted、hold。

  • mailDomainAllowedServiceAccess: +imap, pop3, http:*

    サービスアクセスフィルタを格納します。フィルタを指定しない場合は、ユーザはすべてのクライアントからすべてのサービスへアクセスを許可されます。

  • mailRoutingHosts: manatee.siroe.com

    MTA の完全修飾ホスト名は、このドメインおよびそのサブドメインのすべてのユーザに対するルーティングを決定します。 空白または欠落している場合は、すべての MTA は、このドメインおよびそのサブドメインのユーザ/グループメッセージをルーティングする必要があります。

  • preferredMailHost: manatee.siroe.com

    iPlanet Delegated Administrator for Messagingおよび Console で、このメールドメイン内のユーザおよびグループの mailHost 属性を設定するために使用されます。

  • mailDomainDiskQuota: 100000000

    ドメイン内のすべてのユーザ用のディスク制限容量 (バイト数単位)。 -1 は、制限がないことを示します。Delegated Administrator によりプロビジョニングが行われますが、この値は強制されません。ただし、報告するという目的には使用できます。

  • mailDomainMsgQuota: -1

    このドメイン内のすべてのユーザに許可されているメッセージ数のディスク制限容量。 -1 は、制限がないことを示します。Delegated Administrator によりプロビジョニングが行われますが、この値は強制されません。ただし、報告するという目的には使用できます。

  • mailClientAttachmentQuota: 5

    Messenger Expressクライアントが、このドメインに対して許可される添付の数。 -1 は、添付に制限がないことを示します。



組織ツリーの作成



組織ツリーには、ユーザおよびグループのエントリが含まれます。 サーバは、組織ツリーを示す DC ツリーを参照します。 新しいホストドメインを作成すると、DC ツリーおよび組織ツリー内に新しいドメインノードが作成されます。 これは、iPlanet Delegated Administrator for Messaging コマンド imadmin domain create または iPlanet Delegated Administrator for Messaging GUI ツールを使用して行います。


組織ツリーのルートドメインエントリの作成



組織ツリーのルートエントリは、DC ツリーのルートエントリと同様にインストール時に作成されます。組織ツリーのルート名はインストーラによって指定できます。 このノードはインストール時に作成されますが、ここでは、説明のために LDIF を示します。 コード例 2-4 組織ツリー ルートの LDIF レコード
dn: o=ISP
objectClass: organization
o: internet
description: Root level node in the Organizational tree

この例では、ルートエントリ DN として o=isp を使用します。属性の説明は、「DC ツリーのルートドメインエントリの作成」を参照してください。ACI 情報については、付録 A「ルートおよびドメイン ACI の例」を参照してください。


組織ツリー内のホストドメインエントリの作成



組織ツリー内のホストドメインは、ルート(o=isp) の下に作成されます。 ホスト ドメインの DN は、任意の架空名称を使用できます。DC ツリー内で使用される名前を反映する必要はありませんが、DC ツリーのドメインノード内の inetDomainBaseDN 属性は、組織ツリー内の対応するノードを指し示している必要があります。 組織ツリー内のホストドメインを作成するための LDIF コードの例を、コード例 2-5 に示します。 コード例 2-5 組織ツリー内のホストドメイン用 LDIF レコード
dn: o=sesta.com,o=ISP
objectclass: organization
objectclass: nsManagedDomain
o: sesta.com
nsNumMailLists: 5
nsMaxMailLists: 1000
nsNumUsers: 20
nsMaxUsers: 1000


組織ツリーのホストドメイン属性とオブジェクトクラス

この節では、ホスト ドメイン属性について簡単に説明します。 属性の詳細については、『iPlanet Schema Reference Manual』を参照してください。

  • dn: o=sesta.com, o=ISP

    dnは、ツリー内のディレクトリエントリを個別に識別します。

  • objectClass: organization
    objectclass: nsManagedDomain

    これらは、組織ツリー内のホストドメイン エントリで必要なオブジェクトクラスです。 organization は、コアオブジェクトクラスで、組織を説明するために使用されます。 nsManagedDomain は、iPlanet Delegated Administrator for Messaging によって管理されるドメインの情報を格納します。


organization 属性

  • o: sesta.com

    o は、organizationName の別名で、必須属性です。


nsManagedDomain 属性

  • nsNumMailLists: 5

    ドメイン内のユーザによって作成されたメールリストの数を指定します。 この数は、すべてのネストされたサブドメインで累積されます。 Delegated Administrator はこの数を保持し、強制します。

  • nsMaxMailLists: 1000

    ドメイン内のユーザが作成できるメールリストの最大数を指定します。 この制限は、すべてのネストされたサブドメインに適用されます。

  • nsNumUsers: 20

    代表管理者で使用中のユーザアカウントの数を識別します。

  • nsMaxUsers: 1000

    作成されるユーザアカウントの最大数を指定します。


ホストドメインに必要なコンテナの作成



各ホストドメインは、ユーザエントリ用のコンテナ people、とメーリングリスト エントリ用のコンテナ groups を持っている必要があります。 次にコード例を示します。 コード例 2-6 ホストドメインコンテナの LDIF コード
dn: ou=People,o=sesta.com,o=ISP
ou: People
objectClass: organizationalUnit

dn: ou=Groups,o=sesta.com,o=ISP
ou: Groups
objectClass: organizationalUnit


組織ツリーのホストドメインコンテナ属性とオブジェクトクラス

  • dn: ou=People,o=sesta.com,o=ISP
    dn: ou=Groups,o=sesta.com,o=ISP

    これらは、すべてのホストドメインで必要なコンテナの識別名です。 ou=People には、ホストドメインのすべてのユーザエントリが含まれます。 ou=Groups には、ホストドメインのすべてのメーリングリストエントリが含まれます。

  • objectClass: organizationalUnit

    organizationalUnit オブジェクトクラスは、ここで説明している例において、ホストドメインのコンテナエントリを作成するために使用されます。

  • ou: People
    ou: Groups

    organizationalUnit の必須エントリです。



ドメイン組織の作成



ドメイン組織は、ドメインノード (上記を参照) 内のユーザとグループを持つノードです。Delegated Administrator for Messaging からは、ドメイン組織は別の組織ノードのように見えます。ドメイン組織は、部門や機能ラインにそって、ユーザとグループエントリを組織し、委任することを望む企業にとって有用です。ユーザエントリがドメイン組織に入力されると、そのユーザは以前と同じ電子メールアドレスを持ちます。

ドメイン組織は、LDAP を介してのみ作成できます。現在 iPlanet Console や iPlanet Delegated Administrator for Messaging 内には、組織を作成するメカニズムはありませんが、iPlanet Delegated Administrator for Messaging コンソールは、既存のドメイン組織のユーザおよびグループの作成、削除、変更をサポートしています。

ACI のないドメイン組織エントリを以下に示します(ACI に関する情報については、付録 A「ルートおよびドメイン ACI の例」を参照)。 ドメイン組織用にコンテナを作成する方法は、「ホストドメインに必要なコンテナの作成」を参照してください。

コード例 2-7 組織ツリー内のドメイン組織の LDIF レコード
dn: ou=east,o=siroe.com,o=isp
objectclass: nsManagedOrgUnit
objectclass: organizationalUnit
objectclass: inetdomainOrg
ou: east
nsdamodifiableby: cn=Domain Organization Administrators,ou=east,
o=siroe.com,o=isp
domOrgMaxUsers: 1000
domOrgNumUsers: 3


ドメイン組織の削除

ドメイン組織は次の方法で削除できます。

  1. imadmin delete コマンドを使用してすべてのユーザとグループを削除します。

  2. imadmin purge コマンドを使用してすべてのユーザとグループをパージします。

  3. ou=users や ou=groups など、残りのすべてのコンテナを削除します。



バニティドメインの作成

バニティドメインまたはカスタムドメインは、ドメインエントリではなく、個々のユーザエントリに添付されるドメイン名です。 バニティドメインは、ホストドメインを自分で持つことなく、独自のドメイン名を希望する個人または小規模な組織で役立ちます。 たとえば、従業員 6 人の小さな会社 Florizel が Siroe ISP で電子メールアカウントを持っているとします。 従業員は電子メールを siroe.com ではなく florizel.com で受け取ることを希望しています。 ホストドメインを作成する代わりに、バニティドメインを登録して Florizel の各メンバーが username@florizel.com でメールを受信できるように設定します。

バニティドメインはドメイン名に LDAP エントリを持ちませんが、その代わりにユーザエントリ内に MailAlternateAddress 属性 (オブジェクトクラス inetLocalMailRecipient) およびmsgVanityDomain 属性 (オブジェクトクラス msgVanityDomainUser) を追加することによって、各ユーザベースで指定されます。 次に例を示します。

コード例 2-8 バニティドメインによるユーザエントリの例
dn: uid=kong,ou=people,o=siroe.com,o=isp
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: inetUser
objectClass: ipUser
objectClass: inetMailUser
objectClass: inetLocalMailRecipient
objectClass: nsManagedPerson
objectClass: userPresenceProfile
objectClass: msgVanityDomainUser
cn: Kelly Kong
sn: Kong
initials: KK
givenName: Kelly
mail: Kelly.Kong@siroe.com
mailAlternateAddress: kelly.kong@florizel.com
mailAlternateAddress: @florizel.com
msgVanityDomain: florizel.com
mailDeliveryOption: mailbox
mailHost: manatee.siroe.com
uid: kong
dataSource: iMS 5.0 @(#)ims50users.sh 1.5a 02/3/00
userPassword: password
mailAllowedServiceAccess: +imap, imaps, pop3, http:*
inetUserStatus: active
mailUserStatus: active
mailQuota: -1
mailMsgQuota: 100

この例では、msgVanityDomain は、ルーティングのために MTA によって使用されるドメイン名を指定します。 kelly.kong@siroe.com または kelly.kong@florizel.com 宛てに送信されたメールは、Kelly Kong 用のメッセージ ストアに送信されます。

mailAlternateAddress: *@florizel.com という行により、 kelly.kong@florizel.com がすべてを受信する(catch-all)アドレスになります。これは、MTA が正確な一致アドレスを見つけることができなかった場合、ドメイン florizel.com へのメールを受信するアドレスです。


Note 1) バニティドメインを持つユーザは、実ドメイン名を使用してメッセージングサーバにログインする必要があります。 前述の例では、Kelly Kong はドメイン florizel.com からではなく、siroe.com から自分のメールにアクセスする必要があります。

2) バニティドメイン名は、固有のインターネットドメイン名で登録する必要があります。また、MX レコードはそれぞれの名前でも登録する必要があります。




ドメインタスク


この節では、共通ドメインタスクを実行する方法を説明します。 すべての LDIF レコードが各タスクに指定されますが、ほとんどのタスクは、1 つまたは複数の属性を既存のドメインに追加するだけです。 これらの属性は、LDIF 更新ステートメントに表示され、完全な LDIF レコードには太字で示されます。 この節には、次の項目が含まれます。


ドメイン別名の作成

ドメイン 別名 は、別のドメインを示すドメインエントリです。 ドメイン 別名は、DC ツリー内で作成されます。 ドメイン別名は、固有のインターネットドメイン名で登録する必要があります。ドメインがメールを受信するには、MX レコードも登録する必要があります。次の LDIF の例では、ドメイン florizel.com を sesta.com という別名にすることができます。 コード例 2-9 ドメイン 別名の作成
dn: dc=florizel, dc=com, o=internet
objectclass: alias
objectclass: inetDomainAlias
aliasedObjectName: dc=sesta, dc=com, o=internet
dc: florizel


ドメインのスマートルーティングホストの追加

スマートルーティング ホストまたはスマートホストは、ドメイン内のすべてのユーザ用のルーティング情報の正式なソースと見なされる MTA ホストです。 ローカル MTA がドメイン内にユーザを検出できない場合は、メッセージがスマートホストに転送されます。 ルーティング ホストの完全修飾ホスト名をドメインエントリの mailRoutingSmartHost 属性に追加することによって、スマートホストを指定します。 次の LDIF レコードは、smarthost1.siroe.com をドメイン sesta.com のルーティングホストとして設定します。 コード例 2-10 スマートルーティングホストを追加するための変更
dn: dc=sesta, dc=com, o=internet
changetype: modify
add: mailRoutingSmartHost
mailRoutingSmartHost: smarthost1.siroe.com
コード例 2-11 スマートルーティングホストを備えたホストドメインの LDIF レコード
dn: dc=sesta,dc=com,o=internet
objectClass: domain
objectClass: inetDomain
objectClass: mailDomain
description: DC node for sesta.com hosted domain
dc: sesta
inetDomainBaseDN: o=sesta.com,o=isp
inetDomainStatus: active
mailDomainStatus: active
mailDomainAllowedServiceAccess: +imap, pop3, http:*
mailRoutingHosts: manatee.sesta.com
preferredMailHost: manatee.sesta.com
mailDomainDiskQuota: 100000000
mailDomainMsgQuota: -1
mailClientAttachmentQuota: 5
mailRoutingSmartHost: smarthost1.siroe.com


ドメインの新しいルーティング ホストの追加

ルーティング ホストは、特定のドメインとそのサブドメイン内のアドレスにメールをルーティングできる MTA ホストです。 ドメインレコード内の mailRoutingHosts 属性が欠落している場合は、そのディレクトリにアクセスする、システム内のすべての MTA がそのドメインのメールのルーティングを処理します。 次の LDIF レコードの例は、1 つまたは複数の特定の MTA をドメインのメールルーティングを処理するように指定する方法を示しています。 コード例 2-12 ルーティングホストを追加するための変更
dn: dc=sesta, dc=com, o=internet
changetype: modify
add: mailRoutingHosts
mailRoutingHosts: sestarouter1.siroe.com
mailRoutingHosts: sestarouter2.siroe.com
コード例 2-13 ルーティングホストを備えたホストドメインの LDIF レコード
dn: dc=sesta,dc=com,o=internet
objectClass: domain
objectClass: inetDomain
objectClass: mailDomain
description: DC node for sesta.com hosted domain
dc: sesta
inetDomainBaseDN: o=sesta.com,o=isp
inetDomainStatus: active
mailDomainStatus: active
mailDomainAllowedServiceAccess: +imap, pop3, http:*
mailRoutingHosts: manatee.sesta.com
mailRoutingHosts: sestarouter1.siroe.com
mailRoutingHosts: sestarouter2.siroe.com
preferredMailHost: manatee.sesta.com
mailDomainDiskQuota: 100000000
mailDomainMsgQuota: -1
mailClientAttachmentQuota: 5


ドメインのようこそメッセージの設定

ドメインがドメインの新しいユーザに「ようこそメッセージ」を配信する場合、mailDomainWelcomeMessage 属性に「ようこそメッセージ」を設定できます。 次の LDIF レコードは、ドメイン sesta.com の「ようこそメッセージ」を設定します。 $$ は、改行復帰に置換されます。

コード例 2-14 ドメインのようこそメッセージを追加するための変更
dn: dc=sesta, dc=com, o=internet
changetype: modify
add: mailDomainWelcomeMessage
mailDomainWelcomeMessage: Subject: Welcome to Sesta! $$ Welcome!
コード例 2-15 ようこそメッセージを備えたホストドメインの LDIF レコード
dn: dc=sesta,dc=com,o=internet
objectClass: domain
objectClass: inetDomain
objectClass: mailDomain
description: DC node for sesta.com hosted domain
dc: sesta
inetDomainBaseDN: o=sesta.com,o=isp
inetDomainStatus: active
mailDomainStatus: active
mailDomainAllowedServiceAccess: +imap, pop3, http:*
mailRoutingHosts: manatee.siroe.com
preferredMailHost: manatee.siroe.com
mailDomainDiskQuota: 100000000
mailDomainMsgQuota: -1
mailClientAttachmentQuota: 5
mailDomainWelcomeMessage: Subject: Welcome to Sesta! $$ Welcome!


Messenger Express クライアントに対する添付ファイル数の制限

Messenger Express クライアントが 1 つのメッセージで送信できる添付ファイルの数を制限するには、次のように mailClientAttachmentQuota 属性を設定します。 コード例 2-16 Messenger Express 添付ファイルを 1 メッセージにつき 2 つに制限するための変更
dn: dc=sesta, dc=com, o=internet
changetype: modify
replace: mailClientAttachmentQuota
mailClientAttachmentQuota: 2
コード例 2-17 Messenger Express 添付ファイルを 1 メッセージにつき 2 つに制限するための LDIF レコード
dn: dc=sesta,dc=com,o=internet
objectClass: domain
objectClass: inetDomain
objectClass: mailDomain
description: DC node for sesta.com hosted domain
dc: sesta
inetDomainBaseDN: o=sesta.com,o=isp
inetDomainStatus: active
mailDomainStatus: active
mailRoutingHosts: manatee.siroe.com
preferredMailHost: manatee.siroe.com
mailDomainDiskQuota: 100000000
mailDomainMsgQuota: -1
mailClientAttachmentQuota: 2


ドメインの状態の設定

メール ドメインは、次のいずれかの状態になります。

  • active - ドメイン内のメールサービスが完全に機能しています。

  • inactive - メールサービスが一時中断しています。

  • deleted - メール サービスが一時中断していて、imadmin domain purge コマンドによってドメインに削除マークが付いています (『iPlanet Messaging Server リファレンスマニュアル』を参照)。

  • hold - ドメイン内のユーザへのすべてのメッセージを宛先メール サーバ のHOLD キューに、保持するようMTA に通知します。 これは、ユーザが 1 つのサーバーから別のサーバーに移され、移動が完了するまでメッセージを保持しておく場合に使用します。

これらの状態は、 mailDomainStatus 属性に設定されます。 状態は、別の値に変更することができます。 値がない場合は、状態が active であることを示します。 不正な値は inactive として処理されます。次の LDIF は、状態を hold に設定します。 コード例 2-18 ドメインの状態を保留にする変更
dn: dc=sesta, dc=com, o=internet
changetype: modify
replace: mailDomainStatus
mailDomainStatus: hold
コード例 2-19 保留中のホストドメインの LDIF レコード
dn: dc=sesta,dc=com,o=internet
objectClass: domain
objectClass: inetDomain
objectClass: mailDomain
description: DC node for sesta.com hosted domain
dc: sesta
inetDomainBaseDN: o=sesta.com,o=isp
inetDomainStatus: active
mailDomainStatus: active
mailRoutingHosts: manatee.sesta.com
mailDomainDiskQuota: 100000000
mailDomainMsgQuota: -1
mailClientAttachmentQuota: 5
mailDomainStatus: hold


前へ     目次     索引     DocHome     次へ     
Copyright © 2000 Sun Microsystems, Inc. Some preexisting portions Copyright © 2000 Netscape Communications Corp. All rights reserved.

最終更新日時 2001 年 5 月 18 日