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



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


この章では、iPlanet Messaging Server のプロビジョニングを行うために必要なドメインと組織ユニットの作成方法について説明します。これらのユニットの一部は、インストール時または Delegated Administrator の使用時に作成されますが、ここでは説明のために、これらのユニットの作成手順を示します。また、このマニュアルでは、属性の概要を説明します。属性の詳細は、『iPlanet Messaging and Collaboration スキマーリファレンスマニュアル』に記載されています。この章には、以下の節があります。



ドメイン ACI

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

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

# 匿名アクセス制御
#
# ユーザエントリに対する匿名の読み取りと検索のアクセスを許可
#
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 の詳細については、『iPlanet Directory Server 4.1 管理者ガイド』を参照してください。



DC ツリーの作成




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


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



ルートエントリは、ディレクトリツリーのトップレベルノードです。DC ツリーでは、ルートは o=internet に設定する慣例になっています。ルートを o=internet 以外に設定する場合は、Messaging Server 構成内の service.dcroot が、DC ツリールートの DN に一致していることを確認します。コード例 2-1 に DC ルートを作成するための LDIF レコードを示します。DC ツリーと組織ツリーのルートノードはインストール時に作成されますが、ここでは説明のために LDIF を示します。デフォルトの ACI は、付録 A「ルートとドメインの ACI の例」に記載しています。

注

通常、特定の共通属性にはエイリアスを指定します。エイリアスは、Directory Server の構成ディレクトリ内の定義ファイル (*.at.conf) で指定します。一般的に使用されるエイリアスには、cn (commonname)、ou (organizationalUnit)、o (organization)、sn (surname)、dn (distinguishedName) などがあります。


コード例 2-1    DC ツリールートの LDIF レコード
dn: o=internet
objectClass: organization
o: internet
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 内に設定されている値と同じ値にする必要があります。
    注

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



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



トップレベルドメインエントリは、ルートのすぐ下にあり、DNS ドメインのドメインコンポーネントをミラー化する必要があります。コード例 2-2 に、トップレベルノードを作成するための LDIF レコードを示します。ルートノード、トップレベルノード、およびデフォルトドメインノードはインストール時に作成されます。ここでは、説明のために 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: mailDomain
    objectClass: nsManagedDomain
    objectClass: icsCalendarDomain

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

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

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

    nsManagedDomain は、iPlanet Delegated Administrator for Messaging 用の情報を格納します。
    注

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



ドメイン属性

  • description: DC node for sesta.com hosted domain

    自由な形式のテキスト記述。通常は、このエントリの属性 organizationName の値に関連付けられている組織の完全な名前です。

  • dc: sesta

    必須の属性。dc は、このノードに関連付けられている DNS ドメインコンポーネントです。


inetDomain Attributes

  • 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 とコンソールで、このメールドメイン内のユーザとグループの 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 属性が、組織ツリー内の対応するノードを指している必要があります。コード例 2-5 に、組織ツリー内のホストドメインを作成するための LDIF コードの例を示します。

コード例 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 Messaging and Collaboration スキマーリファレンスマニュアル』を参照してください。

  • 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

    Delegated Administrator で使用中のユーザアカウントの数を示します。

  • nsMaxUsers: 1000

    作成可能なユーザアカウントの最大数を示します。


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



各ホストドメインは、ユーザエントリ用の people という名前のコンテナと、メーリングリストエントリ用の groups という名前のコンテナを持っている必要があります。次にコードの例を示します。

コード例 2-6    ホストドメインコンテナの LDIF コード
dn: ou=People,o=sesta.com,o=isp
objectClass: organizationalUnit
ou: People

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


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

  • 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 内には、組織を作成するメカニズムはありません。ただし、Delegated Administrator コンソールは、既存のドメイン組織内のユーザやグループの作成、削除、変更をサポートしています。

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 に電子メールアカウントを持っているとします。同社の社員は、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 ドメインアドレスになります。catch-all ドメインアドレスとは、MTA が正確に一致するアドレスを見つけることができなかった場合に、ドメイン florizel.com 宛てのメールを受信するアドレスです。ダイレクト LDAP 参照を使用するシステムの場合は、mailDomainCatchAllAddress 属性 (「ドメインの catch-all アドレスの指定」を参照) を使用する必要があります。

注

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

2) バニティドメイン名には、一意の登録済みインターネットドメイン名を使用する必要があります。また、MX レコードも、それらの名前で登録する必要があります。




ドメインタスク


この節では、一般的なドメインタスクを実行する方法について説明します。各タスクについて LDIF レコード全体が示されていますが、ほとんどのタスクでは、1 つまたは複数の属性を既存のドメインに追加するだけで済みます。これらの属性は、LDIF の更新文内に示されています。また、LDIF レコード全体の中では、これらの属性は太字で示されています。この節には、以下の項があります。


使用可能なドメインメールサービスの追加と削除

使用可能なドメインメールサービスは、mailDomainAllowedServiceAccess 属性で設定します。形式は次のとおりです。

mailAllowedDomainServiceAccess: filter_syntax

(使用可能なサービスのシンタックスについては、『iPlanet Message Server 管理者ガイド』の「フィルタの構文」の節を参照してください。) 次の LDIF 変更コードは、sesta.com 用の IMAP、POP3、および HTTP (Messenger Express) サポートを追加します。

コード例 2-9    ドメインメールサービスを追加するための変更文
dn: dc=sesta, dc=com, o=internet
changetype: modify
add: mailDomainAllowedServiceAccess
mailDomainAllowedServiceAccess: +imap:ALL$+pop:ALL$+http:ALL
コード例 2-10    スマートルーティングホストを含むホストドメインの 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
mailDomainAllowedServiceAccess: +imap:ALL$+pop:ALL$+http:ALL


ドメインのエイリアスの作成

ドメインのエイリアスとは、別のドメインを指すドメインエントリのことです。ドメインのエイリアスは、DC ツリー内で作成されます。ドメインのエイリアスには、登録済みの一意のインターネットドメイン名を使用する必要があります。ドメインでメールを受信するには、MX レコードもドメインに登録する必要があります。次の LDIF の例では、ドメイン florizel.com を sesta.com のエイリアスにすることができます。

コード例 2-11    ドメインのエイリアスの作成
dn: dc=sesta, 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-12    スマートルーティングホストを追加するための変更文
dn: dc=sesta, dc=com, o=internet
changetype: modify
add: mailRoutingSmartHost
mailRoutingSmartHostsmarthost1.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
preferredMailHost: manatee.sesta.com
mailDomainDiskQuota: 100000000
mailDomainMsgQuota: -1
mailClientAttachmentQuota: 5
mailRoutingSmartHost: smarthost1.siroe.com


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

ルーティングホストとは、特定のドメインおよびそのサブドメイン内のアドレスにメールをルーティングすることになっている MTA ホストです。ドメインレコード内に mailRoutingHosts 属性が含まれていない場合は、システム内でそのディレクトリにアクセスするすべての MTA がそのドメインのメールのルーティングを行う必要があります。次の LDIF レコードの例は、ドメインのメールルーティングを行う複数の MTA を指定する方法を示しています。

コード例 2-14    ルーティングホストを追加するための変更文
dn: dc=sesta, dc=com, o=internet
changetype: modify
add: mailRoutingHosts
mailRoutingHosts: sestarouter1.siroe.com
mailRoutingHosts: sestarouter2.siroe.com
コード例 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.sesta.com
mailRoutingHosts: sestarouter1.siroe.com
mailRoutingHosts: sestarouter2.siroe.com
preferredMailHost: manatee.sesta.com
mailDomainDiskQuota: 100000000
mailDomainMsgQuota: -1
mailClientAttachmentQuota: 5


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

Messenger Express クライアントが 1 つのメッセージで送信できる添付ファイルの数を制限するには、次のように mailClientAttachmentQuota 属性を設定します。

コード例 2-16    Messenger Express の添付ファイル数を各メッセージで 2 つまでに制限するための変更文
dn: dc=sesta, dc=com, o=internet
changetype: modify
replace: mailClientAttachmentQuota
mailClientAttachmentQuota: 2
コード例 2-17    Messenger Express の添付ファイル数を各メッセージで 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 内に設定されます。状態は 1 つの値から別の値に変化する場合があります。値がない場合は、状態が active であることを示します。不正な値は、inactive として扱われます。次の LDIF は、状態を hold に設定します。

コード例 2-18    ドメインの状態を Hold に設定するための変更文
dn: dc=sesta, dc=com, o=internet
changetype: modify
replace: mailDomainStatus
mailDomainStatus: hold
コード例 2-19    Hold 状態のホストドメインの 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


ドメインのポストマスターの設定

ポストマスターは各ドメインの特別なユーザです。ポストマスターのアドレスは、エラーメッセージや配信ステータスの通知に使用されます。ポストマスターを明示的に指定していない場合は、デフォルトの「postmaster@ドメイン」に設定されます。

注

この手順は、ダイレクト LDAP を使用してメールのルーティングを行うシステムだけで使用できます。dirsync を使用するシステムでは、次の手順は使用できません。


コード例 2-20    ドメインのポストマスターを作成するための変更文
dn: dc=sesta, dc=com, o=internet
changetype: modify
add: mailDomainReportAddress
mailDomainReportAddress: rfc822_Address
コード例 2-21    ドメインのポストマスターを作成するための 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
mailDomainReportAddress: rfc822_Address


受信メッセージサイズの制限の設定

mailDomainMsgMaxBlocks 属性を使用すると、ドメイン内のユーザ宛てに送信されるメッセージサイズの制限を設定できます。メッセージサイズは、MTA ブロックサイズ (デフォルトは 1024 バイト) 単位で設定します。ユーザのブロック制限属性 mailMsgMaxBlocks が設定されている場合は、mailDomainMsgMaxBlocks は無視されます。次の例では、ブロックサイズが 1K バイトであると仮定して、制限を 1M バイトに設定しています。

注

この手順は、ダイレクト LDAP を使用してメールのルーティングを行うシステムだけで使用できます。dirsync を使用するシステムでは、次の手順は使用できません。


コード例 2-22    ドメインのメッセージサイズの制限を設定するための変更文
dn: dc=sesta, dc=com, o=internet
changetype: modify
add: mailDomainMsgMaxBlocks
mailDomainMsgMaxBlocks: 1000
コード例 2-23    ドメインのメッセージサイズの制限を設定するための 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
mailDomainMsgMaxBlocks: 1000


ドメインの catch-all アドレスの指定

ドメインにメッセージが送信され、その受取人アドレスと一致するユーザまたはグループがない場合は、通常メッセージは差出人に返されます。しかし、そのようなメッセージをすべて受信するアドレスを指定することができます。これは catch-all アドレスと呼ばれます。catch-all アドレスは、mailDomainCatchAllAddress 属性を使用して指定します。

注

この手順は、ダイレクト LDAP を使用してメールのルーティングを行うシステムだけで使用できます。dirsync を使用するシステムでは、次の手順は使用できません。


コード例 2-24    catch-all アドレスを指定するための変更文
dn: dc=sesta, dc=com, o=internet
changetype: modify
add: mailDomainCatchAllAddress
mailDomainCatchAllAddressrfc822_Address
コード例 2-25    catch-all アドレスを指定するための 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
mailDomainCatchAllAddress: rfc822_Address


前へ     目次     索引     DocHome     次へ     
Copyright © 2000 Sun Microsystems, Inc.

最新更新日 2002 年 2 月 13 日