Previous     Contents     Index     Next     
iPlanet Messaging Server 5.2 Provisioning Guide



Chapter 2   Provisioning Domains


This chapter describes how to create the domains and organizational units needed to provision the iPlanet Message Server. Note that some of these units are created during installation or when using the Delegated Administrator. However, we show these procedures for educational purposes. Attribute descriptions in this guide are overviews. Complete descriptions are available in the iPlanet Schema Reference Manual. This chapter consists of the following sections:



Domain ACIs

ACIs are required for all root and domain entries in both the DC and Organization Trees. The ACIs control access to the directory by the various types of users and administrators as well as the iPlanet Delegated Administrator for Messaging tool. For a more complete discussion of Messaging Server ACI design for user access, see "ACI Architecture".

Upon installation ACIs are installed for the root-level of both the DC and Organization Trees, as well as the top-level domains of the Organization Tree (see Appendix A "Root and Domain ACI Examples"). These ACIs apply to the node as well as all sub-nodes. Thus, ACIs created on the root node will apply to all the domains under the root. ACI rules can be viewed by doing an ldapsearch for a specific domain. The rules are displayed after the attributes of the domain entry and have the following format:

# Anonymous access control
#
# Allow anonymous read and search access to user entries
#
aci: (targetattr != "userPassword")
(targetfilter=(objectClass=nsManagedPerson))
(version 3.0; acl "Anonymous access to User entries";
allow (read,search)
userdn="ldap:///anyone";)
#

This ACI rule allows anyone to search and read everything but userPassword in any entry containing the object class nsManagedPerson. Pound signs (#) are non-executable comments. targetattr specifies the attributes upon which to act. targetfilter is the object class for which to search. version is a user defined version number and comment. allow lists the privileges allowed (read, write, search, delete, modify). userdn specifies who may act upon these attributes.

For a more complete discussion of directory ACIs, refer to the Netscape Directory Server 4.1 Administrator's Guide.



Creating a DC Tree




The DC Tree nodes contain the operating parameters of a specific domain (for example routing host, disk quota, etc.) as well as a pointer to the sub-tree containing the user and mailing list entries for the domain. The DC Tree mirrors the DNS structure and a default DC Tree is created upon installation. As new hosted domains or domain organizations are created, however, new domain and domain organization nodes must be created in both the DC and Organization Trees. This can be done using the iPlanet Delegated Administrator for Messaging command imadmin domain create (see the command description in the iPlanet Messaging Server Reference Manual) or the iPlanet Delegated Administrator for Messaging console (see the iPlanet Delegated Administrator Guide). In this section, however, we will only explain how to create them using LDAP. Note that MX records also need to be added for new domains.


Creating the DC Tree Root Domain Entry



The root entry is the top level node of a directory tree. In the DC Tree the convention is to set the root to o=internet. If you specify the root to something other than o=internet, make sure that service.dcroot in the messaging server configuration matches the DN of the DC Tree root. The LDIF record for creating the DC root is shown in Code Example 2-1. Note that the root nodes for the DC and Organization Trees are created during installation, but we show the LDIF for instructional purposes. The default ACIs are shown in Appendix A "Root and Domain ACI Examples.

Note It is a common practice to specify an alias for certain common attributes. These are done in the attributes definition files (*.at.conf) in the directory server configuration directory. Common aliases include cn (commonname), ou (organizationalUnit), o (organization), sn (surname), dn (distinguishedName).


Code Example 2-1    LDIF Record for a DC Tree Root
dn: o=internet
objectClass: organization
o: internet
description: Root level node in the Domain Component (DC) tree


DC Tree Root Entry Attributes and Object Classes

  • dn: o=internet

    The distinguished name (dn) uniquely identifies the directory entry in the tree. The default root node in the DC Tree is o=internet.

  • objectClass: organization

    The root node of the DC Tree is defined by the object class organization. The object class allows you to add other attributes to the entry, but only "o" is required. o must have the same value as set in the dn of this entry.
    Note All object classes inherit the top object class, so it is not necessary to include the line objectClass: top in the LDIF code for creating entries.



Creating DC Tree Top-level Domain Entries



The top-level domain entries are just below root and must mirror the domain components of the DNS domains. The LDIF record for creating the top-level nodes is shown in Code Example 2-2. Note that a root, top-level, and default domain nodes are created during installation. We show the LDIF for instructional purposes. ACIs are also created (see Appendix A "Root and Domain ACI Examples).

Code Example 2-2    LDIF Record for Top-level Nodes
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 Tree Top-level Node Attributes and Object Classes

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

    dn specifies the top-level domain node entries.

  • objectClass: domain

    The domain object class is used to create all the container entries (except for the root entry) in the DC Tree.


Creating a DC Tree Hosted Domain Entry



For each hosted domain in the Organization Tree, a corresponding hosted domain node must also be created in the DC Tree. The LDIF code for creating a hosted domain in the DC Tree is shown in below. See Appendix A "Root and Domain ACI Examples" for ACI information.

Code Example 2-3    LDIF Record for Creating a Hosted Domain Node in the DC Tree
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 Tree Hosted Domain Attributes and Object Classes

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

    The dn uniquely identifies the domain entry in the tree. Note that each hosted domain component must match the DNS node for the hosted domain.

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

    These lines specify the object classes required to create the dc=sesta entry in the DIT. domain is the core object class and provides attributes useful for describing the domain component nodes of the DC Tree.

    inetDomain provides attributes for describing the additional properties of a hosted domain. This object class is associated with directory entries which correspond to a DNS domain.

    mailDomain represents a hosted domain account and is used in conjunction with mailDomain and, optionally, inetDomainAuthInfo, for creating hosted domain nodes suitable for mail services for the hosted organization. This object class must be used for all hosted domain entries.

    nsManagedDomain stores information for the iPlanet Delegated Administrator for Messaging.
    Note If your user and group data is stored in the DC Tree and not in an Organization Tree, then you will need to include the nsManagedDomain object class and associated attributes. See "Creating a Hosted Domain Entry in the Organizational Tree".



domain Attributes

  • description: DC node for sesta.com hosted domain

    Free form text description. Usually the full name of the organization that is associated with the value of the attribute organizationName for this entry.

  • dc: sesta

    Required attribute. dc is the associated DNS domain component for this node.


inetDomain Attributes

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

    Single valued attribute. DN of the sub-tree where all user and group entries for this hosted domain are contained.

  • inetDomainStatus: active

    Current status of the hosted domain. Valid values: active, inactive, deleted. This attribute is the global domain status. Missing value implies status is active. An illegal value is treated as inactive. For mail domains, the other status attribute is mailDomainStatus.


mailDomain Attributes

  • mailDomainStatus: active

    Current status of the mail domain. May be one of the following values: active, inactive, deleted, hold.

  • mailDomainAllowedServiceAccess: +imap, pop3, http:*

    Stores service access filters. If no filters are specified, then user is allowed access to all services from all clients.

  • mailRoutingHosts: manatee.siroe.com

    Fully qualified host name of the MTA responsible for making routing decisions for users in this domain and all its sub-domains. If empty or missing, then all MTAs route user/group messages in this domain and its sub-domains.

  • preferredMailHost: manatee.siroe.com

    Used by the iPlanet Delegated Administrator for Messaging and Console to set the mailHost attribute of users and groups in this mail domain.

  • mailDomainDiskQuota: 100000000

    Disk quota, in bytes, for all users in the domain. -1 signifies no quota. Though provisioned by the Delegated Administrator, this value is not enforced; however, it may be useful for reporting purposes.

  • mailDomainMsgQuota: -1

    Quota of number of messages permitted for all users in this domain. -1 signifies no quota. Though provisioned by the Delegated Administrator, this value is not enforced; however it may be useful for reporting purposes.

  • mailClientAttachmentQuota: 5

    The number of attachments Messenger Express clients are allowed for this domain. -1 means no limit on attachments.



Creating an Organization Tree



The Organization Tree contains the user and group entries. The server references the DC Tree, which points to the Organization Tree. As new hosted domains are created, new domain nodes in the DC and Organization Trees are created. This can be done using the iPlanet Delegated Administrator for Messaging command imadmin domain create or the iPlanet Delegated Administrator for Messaging GUI tool.


Creating the Organizational Tree Root Domain Entry



The Organization Tree root entry is created upon installation just like the DC Tree root entry. The organizational tree root name can be specified by the installer. Although this node is created during installation, we show the LDIF for instructional purposes.

Code Example 2-4    LDIF Record for a Organizational Tree Root
dn: o=isp
objectClass: organization
o: internet
description: Root level node in the Organizational tree

In this example we use o=isp, as the root entry DN. For a description of the attributes see "Creating the DC Tree Root Domain Entry". See Appendix A "Root and Domain ACI Examples" for ACI information.


Creating a Hosted Domain Entry in the Organizational Tree



Hosted domains in the Organization Tree are created below the root (o=isp). The DN of the hosted domain can be any arbitrary name and does not need to reflect the name used in the DC Tree, but the inetDomainBaseDN attribute in the domain node of the DC Tree must point to its corresponding node in the Organization Tree. Example LDIF code for creating a hosted domain in the Organization Tree is shown in Code Example 2-5.

Code Example 2-5    Example LDIF Code for a Hosted Domain in the Organization Tree
dn: o=sesta.com,o=isp
objectclass: organization
objectclass: nsManagedDomain
o: sesta.com
nsNumMailLists: 5
nsMaxMailLists: 1000
nsNumUsers: 20
nsMaxUsers: 1000


Organization Tree Hosted Domain Attributes and Object Classes

This section provides brief descriptions of the hosted domain attributes. For more complete descriptions of the attributes refer to the iPlanet Schema Reference Manual.

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

    dn uniquely identifies the hosted domain entry in the tree.

  • objectClass: organization
    objectclass: nsManagedDomain

    Object classes required by hosted domain entries in the Organization Tree. organization is the core object class and is used to describe an organization. nsManagedDomain stores information for the iPlanet Delegated Administrator for Messaging.


organization Attributes

  • o: sesta.com

    o is an alias for organizationName and is a required attribute.


nsManagedDomain Attributes

  • nsNumMailLists: 5

    The number of mail lists that have been created by users in the domain. This count is cumulative for all nested sub-domains. The Delegated Administrator maintains this counter and enforces it.

  • nsMaxMailLists: 1000

    The maximum number of mail lists that users in the domain can create. This limit applies to all nested sub-domains.

  • nsNumUsers: 20

    The number of user accounts in use in delegated administrator.

  • nsMaxUsers: 1000

    The maximum number of user accounts that may be created.


Creating the Required Containers for Hosted Domains



Each hosted domain must have a container for user entries called people, and a container for mailing list entries called groups. Example code is shown below.

Code Example 2-6    LDIF Code for Hosted Domain Containers
dn: ou=People,o=sesta.com,o=isp
objectClass: organizationalUnit
ou: People

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


Organization Tree Hosted Domain Container Attributes and Object Classes

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

    These are the distinguished names for containers required by all hosted domains. ou=People contains all the user entries for the hosted domain. ou=Groups contains all the mailing list entries for the hosted domain.

  • objectClass: organizationalUnit

    The organizationalUnit object class is used to create the container entries of the hosted domain in our example.

  • ou: People
    ou: Groups

    These are the required organizationalUnit entries.



Creating a Domain Organization



A domain organization is a node with users and groups within a domain node (see above). When viewed from the Delegated Administrator for Messaging, a domain organization looks like another organization node. Domain organizations are useful for companies that wish to organize and delegate their user and group entries along departmental or functional lines. When a user entry is put in a domain organization, the user still retains the same email address.

Domain organizations can only be created through LDAP. Currently, there is no mechanism in the iPlanet Console or the iPlanet Delegated Administrator for Messaging to create organizations; however, the Delegated Administrator console does support the creation, deletion and modification of users and groups in existing domain organizations.

A domain organization entry without its ACIs is shown below. (See Appendix A "Root and Domain ACI Examples" for information on ACIs.) See the previous section, "Creating the Required Containers for Hosted Domains" for instructions on how to create containers for the domain organization.

Code Example 2-7    LDIF Record for a Domain Organization in the Organization Tree
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


Deleting a Domain Organization

Domain organizations are deleted as follows:

  1. Delete all users and groups using the imadmin delete commands.

  2. Purge all users and groups using the imadmin purge commands.

  3. Remove all remaining containers such as ou=users and ou=groups.



Creating a Vanity Domain

A vanity domain or custom domain is a domain name attached to individual user entries—not to a domain entry. Vanity domains are useful for individuals or small organizations desiring a customized domain name without the administrative overhead of supporting hosted domain. For example, a small company with six employees called Florizel has an email account with Siroe ISP. They would like to receive their email at florizel.com. Instead of creating a hosted domain, a vanity domain can be registered and set up so that each member of Florizel will receive mail at username@florizel.com.

A vanity domain does not have an LDAP entry for the domain name, but is instead specified on a per user basis by adding the MailAlternateAddress attribute (object class inetLocalMailRecipient) and the msgVanityDomain attribute (object class msgVanityDomainUser) in a user entry. An example is shown below.

Code Example 2-8    Example User Entry with Vanity Domain
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

In this example, msgVanityDomain specifies a domain name used by the MTA for routing purposes. Mail addressed to kelly.kong@siroe.com or kelly.kong@florizel.com will be sent to the message store for Kelly Kong.

The line mailAlternateAddress: @florizel.com makes kelly.kong@florizel.com a catch-all domain address, that is, an address that will receive mail to the domain florizel.com if the MTA does not find an exact address match. Note that if your system uses direct LDAP lookup, you must use the mailDomainCatchAllAddress attribute (see "Specifying a Catch-all Address for a Domain").

Note 1) Users with vanity domains must log in to the messaging server using the real domain name. In the example above, Kelly Kong must access her mail through the domain siroe.com and not florizel.com.

2) Vanity domain names must be unique registered internet domain names, and an MX record must be registered for each such name also.




Domain Tasks


This section describes how to perform common domain tasks. The entire LDIF record is given for each task, however, most tasks require only adding one or more attributes to an existing domain. These attributes are shown in an LDIF update statement and appear in bold in the complete LDIF record. This section consists of the following subsections.


Adding/Removing Allowed Domain Mail Services

Allowed domain mail services are set with the mailDomainAllowedServiceAccess attribute. The format is as follows:

mailAllowedDomainServiceAccess: filter_syntax

(See the Filter Syntax section in the iPlanet Message Server Administration Guide for allowed services syntax.) The following LDIF modify code adds IMAP, POP3 and HTTP (Messenger Express) support for sesta.com.

Code Example 2-9    Modify Statement for Adding Domain Mail Services
dn: dc=sesta, dc=com, o=internet
changetype: modify
add: mailDomainAllowedServiceAccess
mailDomainAllowedServiceAccess: +imap:ALL$+pop:ALL$+http:ALL
Code Example 2-10    LDIF Record for Hosted Domain with Smart Routing Host
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


Creating a Domain Alias

A domain alias is a domain entry that points to another domain. Domain aliases are created in the DC Tree. A domain aliases must be a unique registered internet domain name. In order for a domain to receive mail, an MX record must be registered for it as well. In the LDIF example below, the domain florizel.com can be an alias to sesta.com.

Code Example 2-11    Creating a Domain Alias
dn: dc=florizel, dc=com, o=internet
objectclass: alias
objectclass: inetDomainAlias
aliasedObjectName: dc=sesta, dc=com, o=internet
dc: florizel


Adding a Smart Routing Host for a Domain

A smart routing host or smart host is an MTA host that is considered to be the authoritative source of routing information for all users in a domain. If a local MTA does not find a user in its local directory, it will forward the message to the smart host. Specify a smart host by adding the fully qualified host name of the routing host to the mailRoutingSmartHost attribute of the domain entry. The following LDIF record sets smarthost1.siroe.com as the routing host for domain sesta.com.

Code Example 2-12    Modify Statement for Adding a Smart Routing Host
dn: dc=sesta, dc=com, o=internet
changetype: modify
add: mailRoutingSmartHost
mailRoutingSmartHost: smarthost1.siroe.com
Code Example 2-13    LDIF Record for Hosted Domain with Smart Routing Host
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


Adding a New Routing Host for a Domain

A routing host is the MTA host that is permitted route mail for addresses in a domain and its sub-domains. A missing mailRoutingHosts attribute in a domain record means all MTAs with access to the directory in the system are permitted to route mail for that domain. The example LDIF record below shows how to designate one or more specific MTAs as responsible for mail routing for the domain.

Code Example 2-14    Modify Statement for Adding Routing Hosts
dn: dc=sesta, dc=com, o=internet
changetype: modify
add: mailRoutingHosts
mailRoutingHosts: sestarouter1.siroe.com
mailRoutingHosts: sestarouter2.siroe.com
Code Example 2-15    LDIF Record for Hosted Domain with Routing Host
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


Limiting Number of Attachments for Messenger Express Clients

To limit the number of attachments a Messenger Express client can send on a single message, set the attribute mailClientAttachmentQuota as shown below.

Code Example 2-16    Modify Statement Limiting Messenger Express Attachments to 2 Per Message
dn: dc=sesta, dc=com, o=internet
changetype: modify
replace: mailClientAttachmentQuota
mailClientAttachmentQuota: 2
Code Example 2-17    LDIF Record for Limiting WebMail Attachments to 2 Per Message
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


Setting the Domain State

A mail domain can have one of the following states:

  • active - the mail service in the domain is fully operational.

  • inactive - the mail service is suspended.

  • deleted - mail service is suspended, and the domain is marked for deletion by the imadmin domain purge command (refer to the iPlanet Messaging Server Reference Manual).

  • hold - tells the MTA to hold all messages for users in that domain in the destination mail server's HOLD queue. This may be used when users are being transitioned from one server to another, and you wish to hold the messages while the user is being moved.

These states are set in the attribute mailDomainStatus. States may be changed from one value to another. A missing value implies that the status is active. An illegal value is treated as inactive. The following LDIF sets the state to hold.

Code Example 2-18    Modify Statement Setting Domain State to Hold
dn: dc=sesta, dc=com, o=internet
changetype: modify
replace: mailDomainStatus
mailDomainStatus: hold
Code Example 2-19    LDIF Record for Hosted Domain on Hold
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


Setting the Domain Postmaster

The postmaster is a special user for each domain. The postmaster address is used for error messages or delivery status notifications. If a postmaster is not explicitly specified, the default is postmaster@domain.

Note This procedure can only be used in system that uses direct LDAP for mail routing. If your system uses dirsync, this procedure will not work.


Code Example 2-20    Modify Statement to Create a Domain Postmaster
dn: dc=sesta, dc=com, o=internet
changetype: modify
add: mailDomainReportAddress
mailDomainReportAddress: rfc822_Address
Code Example 2-21    LDIF Record for Creating a Domain Postmaster
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


Setting Limits on Received Message Size

You can impose a size limit on messages sent to users in a domain using the mailDomainMsgMaxBlocks attribute. Message size is set in MTA block size (default is 1024 bytes). Note that if the user block limit attribute, mailMsgMaxBlocks, is set, it overrides mailDomainMsgMaxBlocks. The example below sets the limit to one megabyte assuming a one kilobyte block size.

Note This procedure can only be used in system that uses direct LDAP for mail routing. If your system uses dirsync, this procedure will not work.


Code Example 2-22    Modify Statement to Set a Domain Message Size Limit
dn: dc=sesta, dc=com, o=internet
changetype: modify
add: mailDomainMsgMaxBlocks
mailDomainMsgMaxBlocks: 1000
Code Example 2-23    LDIF Record for Setting a Domain Message Size Limit
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


Specifying a Catch-all Address for a Domain

If a message is sent to the domain and the recipient address does not match any user or group, that message is typically returned to sender. You can, however, specify an address that will receive all such messages. This is called a catch-all address. Catch-all addresses are specified by using the mailDomainCatchAllAddress attribute.

Note This procedure can only be used in system that uses direct LDAP for mail routing. If your system uses dirsync, this procedure will not work.


Code Example 2-24    Modify Statement to Specify a Catch-all Address
dn: dc=sesta, dc=com, o=internet
changetype: modify
add: mailDomainCatchAllAddress
mailDomainCatchAllAddress: rfc822_Address
Code Example 2-25    LDIF Record to Specify a Catch-all Address
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


Previous     Contents     Index     Next     
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.

Last Updated February 13, 2002