These release notes contain important information available at the time of the version 5.1 patch 1 release of iPlanet Messaging Server. Features and enhancements, installation notes, known problems, and other late-breaking issues are addressed here. Read this document before you install the patch.
An electronic version of these release notes can be found at the iPlanet documentation web site: http://docs.iplanet.com/docs/manuals/messaging.html/. Check the web site prior to installing and setting up your software and then periodically thereafter to view the most up-to-date release notes and manuals.
These release notes contain the following sections:
iPlanet Messaging Server provides a powerful and flexible solution to the email needs of enterprises and messaging hosts of all sizes using open Internet standards.
iPlanet Messaging Server is an integration of the Netscape Messaging Server and Sun Internet Messaging Server. The most robust and highest performing components of each product have been combined to produce the iPlanet Messaging Server. For example, the message store, LDAP directory, and Administration Console come from Netscape Messaging Server, while the message transfer agent (MTA) and delegated administrator command line interface come from Sun Internet Mail Server.
Because this is an integrated product, Netscape Messaging Server and Sun Internet Messaging Server customers might find that many processes and procedures for those products are different for iPlanet Messaging Server. For complete information refer to the iPlanet Messaging Server 5.1 documentation at http://docs.iplanet.com/docs/manuals/messaging.html.
The following list describes features available in Messaging Server 5.1:
The minimum hardware requirements for iPlanet Messaging Server are:
The following addresses client software requirements. For Messenger Express access, Messaging Server requires a JavaScript-enabled browser. For optimal performance, iPlanet recommends the following browsers:
Supported Sun Cluster software for iPlanet Messaging Server 5.1 patch 1 now includes Sun Cluster 3.0 Update 2. It is strongly recommended that you upgrade your cluster software to Sun Cluster 3.0 Update 2 in order to take advantage of many bug fixes.
You should upgrade cluster software after stopping all Messaging Server services. Then proceed to install iPlanet Messaging Server patch 1 after installing the cluster and third party software upgrades and patches.
For details on the cluster upgrade from Sun Cluster 3.0 GA (or Sun Cluster 3.0 Update 1) refer to Chapter 3, "Upgrading Sun Cluster Software" of the "Sun Cluster 3.0 12/01 Software Installation Guide." Also, check "Sun Cluster 3.0 Early Notifier" for the latest information on available patches for cluster and third party software.
iPlanet Messaging Server is supported on the following platforms:
Note | Solaris 2.7 is not a supported platform for iPlanet Messaging Server.
|
The supported Solaris platforms require the following patches.
A list of recommended patches for Solaris 2.6 and Solaris 8 can be found at http://access1.sun.com.
Additionally, ensure that your Solaris setup specifies how to route to hosts that are not on the local subnet. To do this, ensure that:
The HP-UX 11.0 platform requires the following operating system bundles and patches:
A list of recommended patches for HP-UX 11.00 can be found at the following URL: http://us-support.external.hp.com/index.html/
Windows NT 4.0 SP6a (Service Pack 6a) is supported.
iPlanet Messaging Server 5.1 requires the following:
For more information about this product, please see the iPlanet Delegated Administrator for Messaging and Collaboration 1.2 patch 1 Release Notes.
Note |
For iPlanet Web Server, it is strongly recommended that you visit the following site to determine which patches are required: http://docs.iplanet.com/docs/manuals/enterprise/
|
These products are all included on the Messaging Server CD and at the download site at http://www.iplanet.com/downloads/download/.
iPlanet Messaging Server 5.1 patch 1 can be applied to all localized versions of iPlanet Messaging Server 5.1 in order to obtain the latest fixes. The Messenger Express localized user interface remains untouched in this patch.
Please see the README file supplied with the patch binary for details on bug 4616499.
The following bugs have been fixed in iPlanet Messaging Server 5.1 patch 1:
The following sections describe known problems, limitations, and considerations of iPlanet Messaging Server and its components. This section contains the following sub-sections:
Localized Versions of iPlanet Messaging Server 5.1 patch 1
Bugs Fixed in iPlanet Messaging Server 5.1 patch 1
Known Problems and Limitations
The following are known problems, issues, and considerations with the Messaging Server installation and uninstallation.
In iPlanet Messaging Server 5.1 patch 1, besides the Directory Server, servers are not started by the installer.
Note
Note
During installation, special characters (for example, @, #, $, and ;) are accepted when prompted for the Messaging Server instance name. Only alphanumeric characters starting with an alphabetic character should be used as instance names.
This section describes known problems, limitations, and considerations when migrating from earlier versions of Messaging Server.
In order to run the imsdirmig and imsdaaci commands on Windows NT, you must copy the DLL files libyasr.dll and nsldap32v40.dll from server-root\bin\msg\lib to the directory where these commands are located: server-root\bin\msg\migrate\bin.
When migrating directory entries from Netscape Messaging Server 4.x, specify an LDAP filter using the -F argument to imsdirmig that excludes the existing Netscape Messaging Server's postmaster entry. An example of such a filter is -F "(!(cn=postmaster))". This filter will exclude the postmaster entry from the migration processing. If such a filter is not specified, imsdirmig fails to process the entry and exits on the resulting error, unless -c is specified to force imsdirmig to continue processing after it encounters an error.
After adding iPlanet Delegated Administrator for Messaging and Collaboration support, the old Sun Internet Mail Server still appears in certain situations through the iPlanet Delegated Administrator user interface. For example, on the Domain Mail Properties page, creating a user and enabling the mail service for that user will list the old Sun Internet Mail Server mail host. This behavior occurs because migrating from the Sun Internet Mail Server domain preserves the preferredMailHost domain attribute. To fix the problem, change this attribute value to point to the correct mail server.
For information about running the ims_dssetup utility, see the iPlanet Messaging Server Migration Guide, Chapter 3, section titled "Migrating from a Single-Server Netscape Messaging Server System," sub-section titled "Migration Procedures," step 3.
For information about regenerating the index for the above attributes, refer to the iPlanet Directory Server documentation at: http://docs.iplanet.com/docs/manuals/directory/41/admin/
index1.htm#1008974
For information about installing the server, see the iPlanet Messaging Server Migration Guide, Chapter 3, section titled "Migrating from a Single-Server Netscape Messaging Server System," sub-section titled "Migration Procedures," step 7.
Installing iPlanet Delegated Administrator for Messaging and Collaboration against a Directory Server that has the merged.oc.conf and merged.at.conf schema files will result in duplicate, conflicting object class definitions in the merged schema files. As a result, trying to modify the migrated Sun Internet Mail Server domain entry using ldapmodify will create an object class violation error.
To fix this problem, you have to comment out the extra object classes defined in the file instanceroot/config/slapd.user_oc.conf:
inetdomain, inetdomainalias, inetdomainorg, inetdomainauthinfo, maildomain, inetuser, inetsubscriber, ipuser, userpresenceprofile, inetmailuser, inetlocalmailrecipient, inetmailadministrator, inetmailgroup, inetmailgroupmanagement, inetmanagedgroup, pabperson pabgroup, pab, inetadmin, msgvanitydomainuser, icscalendaruser, inetresource, icscalendarresource, icscalendardomain, icsadministrator
The following steps are based on the iPlanet Messaging Server Migration Guide, Chapter 3, section titled "Migrating from a Single-Server Netscape Messaging Server System." However, changes have been made here specifically for migration on a Windows NT platform.
One way to do this is to change the SMTP port number and restart the SMTP server. This allows the server to continue processing any messages in the queue while not accepting messages on the standard SMTP port.
InstanceRoot\configutil -o service.smtp.port -v 901
InstanceRoot\stop-msg smtp
InstanceRoot\start-msg smtp
Refer to "Using Existing Directory Information Trees in the iPlanet Messaging Server" in Appendix B of the iPlanet Messaging Server Migration Guide.
Use configutil to set local.ugldapdeforgdn to o=sesta.com:
InstanceRoot/configutil -o "local.ugldapdeforgdn" -v "o=sesta.com"
o=sesta.com is the DN of the Organization Tree that corresponds to the default domain.
Change the primary store partition path to point at the Netscape Messaging Server 4.x message store path as follows:
NMSServerRoot/mailstore/store/user/
to:
iMSServerRoot/msg-instance/store/user/
(mailstore is the example given in step 5.)
NMSServerRoot/mailstore/store/mboxlist/data.db2
to
iMSServerRoot/msg-instance/store/mboxlist/folder.db
InstanceRoot/configutil -o local.imta.schematag
-v "ims50,nms41"
InstanceRoot/configutil -o local.imta.ugfilter
-v (|(objectClass=inetLocalMailRecipient)
(|(objectClass=mailRecipient) (objectclass=mailGroup)))
The mail server is now available for use. At this time iPlanet Messaging Server is working off the old directory entries in: ldap.sesta.com using multi-schema support. New user and group entries will be created in the new directory nodes.
imsdirmig -b "o=sesta.com" -M nms -D "cn=Directory Manager" -w secret -m both -F "(!(cn=postmaster))"
An error occurs when backing out of the install for iPlanet Messaging Server 5.1 patch 1. This occurs then the user enters a directory that differs in case from what the current directory is set to. The workaround for this is to match the case of each element in the path.
If a user's uid attribute in LDAP contains any upper case characters--for example, the uppercase K in Kolander--after a migration has occurred from SIMS to iPlanet Messaging Server, the user will not be able to access the migrated mailbox.
SIMS stores all mailbox names in lowercase characters, but iPlanet Messaging Server does not. Moreover, SIMS converts LDAP uid attributes to lowercase characters before it searches its message store for a mailbox name that matches that uid; again, iPlanet Messaging Server does not. During a migration, SIMS mailboxes are restored to iPlanet Messaging Server. In this situation, because the mailboxes were migrated from SIMS, they are all in lowercase characters. Since iPlanet Messaging Server does not convert LDAP uid attributes to lowercase, uid attributes that contain uppercase characters will not match the names of the migrated mailboxes. Mail users with uid attributes containing uppercase characters will not be able to access their mailboxes.
To fix this problem, administrators have two options.
This section describes known problems, limitations, and considerations when upgrading iPlanet Messaging Server.
The upgrade process overwrites the Messenger Express HTML files. If you have made customizations, they will be lost. To fix this, make a backup of your customized files before you perform the upgrade process.
After iPlanet Messaging Server is upgraded, the file server-root/msg-instance/html/main.js is not updated with the correct iPlanet Delegated Administrator for Messaging and Collaboration port.
To fix this problem, before upgrade, search for the variable called NDAStartPage in the main.js file. It is a URL containing the iPlanet Delegated Administrator for Messaging and Collaboration host name and port number. The port will be set to 8080 after an upgrade. Change the port number to the correct iPlanet Delegated Administrator for Messaging and Collaboration port that you are using.
With Messaging Server 5.0 patch 3 and later releases, cron jobs are no longer used for scheduling periodic dirsync jobs. After upgrading to iPlanet Messaging Server 5.1, ensure that there are no longer any crontab entries for the Messaging Server dirsync jobs. To alter the frequency of periodic dirsync jobs, edit the appropriate settings in the job_controller.cnf file.
The user is prompted by three separate screens, one prompt per screen. The three items that the user is prompted for are: the host name of the iPlanet Delegated Administrator for Messaging and Collaboration (a fully qualified host name), the Web Server port, and the default domain. The work-around is to provide the requested information as demonstrated by the following example:
Host Name of the server: ims.india.sesta.com
Port number of the server: 80
Default Domain: india.sesta.com
This section describes known problems, limitations, and considerations with iPlanet Messaging Server.
When installing the RTM version of iPlanet Messaging Server 5.1 (Note that this is not iPlanet Messaging Server 5.1 patch 1) on a Pentium 4 Xeon machine, the installation fails.
After attempting the installation, perform the following:
For example, if the c:\temp\iplanet-msg-install.log file contains the following (at the end of the file):
server-root\bin\base\jre -nojit -cp "server-root\bin\msg\imta\classes\imtaconfig.jar" com.siroe.msg.imta.config.InitConfig -d siroe.com -r siroe.com -h msg-server-host.siroe.com -c server-root\msg-instance\imta\config -N
The output should resemble the following:
If you wish to use the program delivery feature, the user under which iPlanet Messaging Server runs must have a home directory, and must have permission to create and write files in the home directory.
The IMAP, POP, and HTTP servers cache the LDAP entries of users who have recently logged in for the amount of time specified in the service.authcachettl configuration parameter. To make the deletion of a user immediately effective, you can run the servers with no authentication cache or turn off the authentication cache by setting service.authcachettl to 0 using the configutil utility and restarting all the services. Note, a setting of 0 will have an impact on performance.
This problem also applies to the Messaging Multiplexor (MMP); however, the MMP does not use configutil. It has a separate AuthCachTTL option in its configuration file.
This affects many searches performed by iPlanet Messaging Server, and is especially apparent when using the dirsync utility. To speed up searches use directory manager credentials to access the directory by using the following commands:
msg-instance/configutil -o local.ugldapbinddn -v "rootdn" -l
msg-instance/configutil -o local.ugldapbindcred -v "rootdn_passwd" -l
where rootdn and rootdn_passwd are the credentials of the Directory Server's administrator.
mgrpErrorsTo attribute does not support multiple values. If you want to specify multiple recipients for error messages, create a mailing list and specify the mailing list address as the value for the mgrpErrorsTo attribute.
For example, the following command returns an error if the expiration rule name does not already exist: configutil -o store.expirerule.name.folderpattern -v pattern
Use Console instead of the command line. After an expiration rule is created, you can modify the parameters by using the configutil utility.
Due to the caching scheme, changing domain properties such as authorized services or status in LDAP does not take effect in IMAP, POP, SMTP, and HTTP until these services are restarted.
If an incremental dirsync is in progress at the time of an HA failover, the alias database will be marked as unsafe. The administrator will be notified of this condition when the messaging server is brought back online. The following message will appear in the log/imta/dirsync.trx-XXXX file:
When this occurs, run the following: imsimta recover-crash
Any updates that occurred since the imsimta dirsync -F command was last run will be lost. After running imsimta recover-crash, run: imsimta dirsync -F
When configuring "Host Names to allow" for the Administration Server, the access control list is case-sensitive. If the DNS server uses mixed-case host names in the IN-ADDR records (used when translating from an IP address to a domain name), the access control list must use the same case. For example, if your host is test.Sesta.Com, then the access control list must include *.Sesta.Com. Due to this bug, *.sesta.com will not suffice.
If Help does not launch from the Administration Console, create a script called "netscape", such as the one given below, and place this script in your path:
On Windows NT, the Administration Console Help does not come up if a browser is already open. If it is not open it brings up a browser and the pages can be viewed. To work around this behavior move server-root\bin\base\viewurl.exe somewhere else, or rename the file, for example rename the file to viewulr.exe.hide.
A login name such as uid@domain is not accepted in certain POP mail clients, such as Netscape Messenger 4.76, Netscape Messenger 6.0, and Microsoft Outlook Express on Windows 2000. The work-around is as follows:
The user needs to become a member of the Service Administrator group in order to have Service Administrator privileges. To make the user a member of the group, you can add the user DN to the uniquemember attribute of the Service Administrator group.
For example, if the user/group base suffix is o=isp, then the DN of the service administrator group is cn=Service Administrators,ou=groups,o=isp. To designate the account uid=ofanning, o=sesta.com, o=isp as a service administrator, you should add the account's DN to the group. In the following modify record, the designated user is added as a group member in the LDIF:
dn: cn=Service Administrators,ou=groups,o=isp
changetype: modify
add: uniquemember
uniquemember: uid=ofanning, o=sesta.com, o=isp
Furthermore, for users to have service administrator privileges, the attribute memberof must be added to the user entry and set to the Service Administrator Group, for example:
For example, you might see an error message such as:
Cluster.PMF.pmfd: Error opening procfs control file
/proc/384/ctl for tag rg.rs.0.svc: No such file or directory
You can ignore these messages.
The instructions to turn on CRAM-MD5/DIGEST-MD5 do not work for "external" SMTP connections (by default all connections not from the local host). However, it works as documented for IMAP/POP and internal SMTP connections. To fix this problem, run:
configutil -o sasl.external.ldap.has_plain_passwords -v 1
To work around this problem, you can deploy separate MMP servers to handle the clients that are excluded from bad guy rules. These servers must have BadGuy turned off.
The Netscape browser might not display some Japanese Kanji characters properly in certain unicode font sizes (10, for example). To fix this, change the browser's unicode font size to 14.
In the quotocheck utility, the -d option for specifying the domain does not work for the default domain. Furthermore, the quotacheck utility returns incorrect error messages when the -u and -n options are specified.
The user should first determine the system's local. For example, the Greek locale might be:
An entry should be added for a locale if the above is not found. The entry should be added in the ServerRoot/bin/msg/bundles/encbylang.properties file.
If users of the MMP see authentication failures and the MMP administrator notices that the MMP log file includes the error "messageid mismatch", they should contact Sun support for a hotfix bundle. Restarting the MMP should temporarily alleviate the problem. This problem is likely to occur if the customer's LDAP server is busy or if the network connection between the MMP and LDAP server fails for any reason.
When upgrading from iPlanet Messaging Server 5.1 to iPlanet Messaging Server 5.1 patch 1, the fix to bug 4661139 causes bug 4708218 to appear. Bug 4661139 caused duplicate messages to be delivered to the mailbox when sieve rules are configured to accept the mail which contains both "sun" and "solaris" in the subject if being filed into the same folder.
For example, if two fileinto commands appear in the sieve rules that "folder" into the same folder, two copies are received into that same folder. For example, if there are two filters (in any order):
Then, if the subject "sun solaris" is received, two copies are received.
Another behavior that may occur is the following:
Because two different folders are specified, two copies are receivedone in each folder. This is the expected behavior if the sieve rules do not contain a stop.
The following are known problems with iPlanet Messenger Express:
When using Netscape Communicator 4.x on Solaris in a Japanese EUC locale, the vcard of a message is displayed as garbage.
A user will not be able to attach files with Japanese file names using Netscape Communicator 4.x browser on Solaris.
If you are using Internet Explorer 5.5, Messenger Express might stop running after the login screen. Use Internet Explorer 5.5 Service Pack 1 (SP1) if you encounter this behavior.
Several minor glitches occur related to either javascript dialog or IMAP folder issues; users who run into these issues may want to use another browser.
This section describes any errors or changes to the iPlanet Messaging Server 5.1 documentation set.
The online version of the Administrator's Guide contains up-to-date changes not found in the CD version: For the online version, see: http://docs.iplanet.com/docs/manuals/messaging.html
Note
To enable single sign-on between Messenger Express and Delegated Administrator, you must perform additional steps as follows:
In Chapter 10, the note in the section "About Message Store Quotas" states: "The server does not consider the size of the message when it is attempting to deliver to an account that is still under quota. If the message causes the user to go over quota, the message is still delivered, but the next message will be held in the queue."
This note is incorrect. The message store strictly enforces hard quotas. When the size of an incoming message is larger than the available space of a mailbox, the message is not delivered. Quota warning notification messages are delivered when the store.quotawarn threshold has exceeded. The quota grace period timer is started at the same time. If you want quota enforcement to start after the mailbox is over quota, set the configuration option local.store.quotaoverdraft to yes. When this option is enabled, quota enforcement, quota notification, and quota grace period timer all start after the user is over quota.
The following updated High Availability instructions supersede the instructions in the iPlanet Messaging Server Installation Guide for UNIX. Some items of note regarding the Messaging Server installation and high availability:
Installing High Availability with Veritas Cluster Server. Refer to your Veritas Cluster Server documentation and the iPlanet Messaging Server Installation Guide to install the cluster server. After doing so, follow these steps:
On the primary node, install Messaging Server and High Availability. To do so, follow these steps:
Installing High Availability with Sun Cluster 2.2. Refer to your Sun Cluster Server documentation and the iPlanet Messaging Server Installation Guide to install the cluster server. After doing so, follow these steps:
On the primary node, install Messaging Server and High Availability. To do so, follow these steps:
Post-Installation Instructions for Sun Cluster 2.2. You must perform the following steps on the secondary node:
scconf cluster_name -l seconds
where cluster_name is the name of the cluster and seconds is the number of seconds you want to set for the timeout value. The number of seconds should be twice the number of seconds needed for the start to complete. For more information, refer to your Sun Cluster documentation.
Installing High Availability for Sun Cluster 3.0. After Step 5 in the section on Installing High Availability for Sun Cluster 3.0 in the iPlanet Messaging Server Installation Guide for UNIX, you should add the following additional steps:
Uninstalling High Availability with Veritas Cluster Server and Sun Cluster 2.2. The High Availability uninstall instructions differ depending on whether you are removing Veritas Cluster Server or Sun Cluster.
To uninstall the high availability components for Veritas Cluster Server follow these steps:
/etc/VRTSvcs/conf/config/MsgSrvTypes.cf
/opt/VRTSvcs/bin/MsgSrv/online
/opt/VRTSvcs/bin/MsgSrv/offline
/opt/VRTSvcs/bin/MsgSrv/clean
/opt/VRTSvcs/bin/MsgSrv/monitor
/opt/VRTSvcs/bin/MsgSrv/sub.pl
Note that you must perform Step a before performing this step.
/opt/SUNWcluster/ha/msg/ims_common
/opt/SUNWcluster/ha/msg/ims_fm_probe
/opt/SUNWcluster/ha/msg/ims_start_net
/opt/SUNWcluster/ha/msg/ims_stop_net
Uninstalling High Availability with Sun Cluster 3.0. To uninstall Messaging Server HA Support for Sun Cluster 3.0, use the following steps. Note that these instructions assume a simple HA configuration. For other configurations, the specific commands may be different but will otherwise follow the same logical order.
To shut down all of the resources in the resource group, issue the command
This shuts down all resources within the resource group (for example, the Messaging Server, LDAP, and the HA logical host name.
Next, remove the resources one-by-one from the resource group with the commands:
# scswitch -n -j ha-ims
# scswitch -n -j ha-ldap
# scswitch -n -j ha-storage
# scswitch -n -j mail
Once the resources have been disabled, you may remove them one-by-one from the resource group with the commands:
# scrgadm -r -j ha-ims
# scrgadm -r -j ha-ldap
# scrgadm -r -j ha-storage
# scrgadm -r -j mail
Once all the resources have been removed from the resource group, the resource group itself may be removed with the command:
In Appendix D of the iPlanet Messaging Server 5.1 Installation Guide for UNIX, the first step in the upgrade instructions should state the following:
1. Shut down all instances of Messaging Server before performing the upgrade. Note that you should not shut down the Directory Server, otherwise the upgrade process will fail.
This section describes any errors or changes to the iPlanet Messenger Express Customization Guide.
The following information should be included in the guide.
The Messenger Express server loads a default set of LDAP attributes for a user at the start of a session. These attributes are as follows:
cn, givenName, mail, mailAlternateAddress, mailAutoReplyMode, mailAutoReplySubject, mailAutoReplyText, mailAutoReplyTextInternal, mailAutoReplyTimeout, mailDeliveryOption, mailForwardingAddress, mailQuota,mailMsgQuota, preferredLanguage, sn, uid, vacationEndDate, vacationStartDate
You might want to obtain other customized LDAP attributes from the server. For example, an ISP might have a custom LDAP attribute assigned to all users called myuserclass. This attribute could denote different types of users that access services, including Messenger Express. Possible values for this attribute are regular and vip. Depending on the type of user (that is, the value of the myuserclass LDAP attribute), different advertisement types will be presented to the user when they log into Messenger Express (Messenger Express is customized to display banner advertisement). If the customized client has access to the myuserclass LDAP attribute, the type of user can be determined and the relevant banner advertisement for that user type can be displayed.
To obtain other customized LDAP attributes from the server, use configutil to modify the service.http.extrauserldapattrs configuration parameter. The attributes are read-only by default. If the customer wants to modify an attribute using the webmail code, that attribute needs to be marked read-write by appending the suffix: w
The example below assumes the customer wants to display banner advertisements depending on the class of the user and that the client program allows the user to edit a link to a homepage: configutil -l -o service.http.extrauserldapattrs -v myuserclass,homepage:w
This code example does not work because the code is not able to take the entry from the i18n_ldap_controls() function in in18n.js. To work around this problem, change the directory server name in the file instanceroot/html/lang_code/lookup_fs.html to the desired directory server name. The name is defined in the function s_SearchCtrl.
This section describes any errors or changes to the iPlanet Messaging Server Migration Guide.
(For more information about 4572521, see the section on changes to the Provisioning Guide.)
In Chapter 1, under "Netscape Messaging Server 4.x Regressions/Changes/Transitions," remove the entire section labeled "Group Attribute mgrpAllowedBroadcaster Does Not Take a Group as a Valid Value." Furthermore, in Chapter 1, under "SIMS 4.0 Regressions/Changes/ Transitions," replace all the text in the section labeled "Allowing or Blocking Access to a Mailing List" with the following:
You can set mgrpAllowedBroadcaster or mgrpDisallowedBroadcaster to the address of a static group, however, nested groups--groups within groups--are not supported. For specific posters, set these attributes to the address of a specific allowed poster or specify as a dynamic group (LDAP search using URL criteria).
In Chapter 1, under "Netscape Messaging Server 4.x Regressions/Changes/Transitions," the following information on authorized senders should be added:
If you try to set an authorized sender, the attribute of mgrpAllowedBroadcaster will be set in LDAP for a mailing list which will disallow everyone else from sending to the mailing list. For example, listing mike as an authorized sender means that mike is the only one who is allowed to send to that mailing list.
In Appendix B, under the section titled "Supporting Multiple Schemas," a location for the two merged schema files, merged.oc.conf and merged.at.conf is given. The location is incorrect; it is listed as: CDRoot/solaris/migrate/schema
The correct locations, which depend upon the operating system, are:
HP-UX: CDRoot/HPUX/ims/msg/msg.zip
Windows NT: CDRoot/ntx86/ims/msg/msg.zip
Solaris: CDRoot/Solaris/ims/msg/msg.zip
In the same section, under the sub-section "Enabling Multi-schema Support on SIMS," in Step 3, the last sentence reads "Note that merged.oc.conf must be included first." It should read: "Note that merged.at.conf must be included first."
In Appendix B, section titled "Using Existing Directory Information Trees in the iPlanet Messaging Server," sub-section titled "Mapping Server Namespace with a Single Domain to an iPlanet Messaging Server Namespace," the following information appears:
This namespace configuration will now support Delegated Administrator and hosted domains. To add Delegated Administrator functionality, run the imsdaaci command (packaged with the migration toolkit). This generates an LDIF file that can be used to create a Delegated Administrator Service Administrator Group and Delegated Administrator Domain Administrator Group along with the required ACIs.
<ServerRoot>/bin/msg/migrate/bin/imsdaaci
Use ldapmodify to add the LDIF file into the DIT. For an explanation of the ACIs refer to the iPlanet Messaging Server Provisioning Guide.
The functionality discussed above is generated during installation and does not require that any further steps be taken; therefore, the information can be ignored.
This section describes any errors or changes to the iPlanet Messaging Server Provisioning Guide.
(For more information about 396008, see the section on changes to the Migration Guide.)
In Chapter 5, under "Creating Posting Restrictions on Mailing Lists," one of the bulleted items reads as follows:
mgrpDisallowedBroadcaster specifies addresses restricted from posting messages to the list. The sender's address is compared against those in this attribute. If there is a match then the message is rejected.
Under this item, add the following note:
In Chapter 5, section titled Tailor File, table 5.19 lists tailor file options; the IMTA_LDAP_SERVER option is no longer valid and should be removed.
In the Schema Reference Manual, Chapter 2, Attributes: the mailSMTPSubmitChannel is improperly defined.
The second sentence in the definition currently reads:
When defined, this attribute tells the MTA that if SMTP is successful, consider the channel named by this attribute to be the effective submission channel.
When defined, this attribute tells the MTA that if SMTP AUTH is successful (that is, if this is an authenticated SMTP session as per RFC 2554), consider the channel named by this attribute to be the effective submission channel.
Also, the example for this attribute is: mailSMTPSubmitChannel: tcp_guaranteed,which is sufficient. However, an example that is more likely to occur is: mailSMTPSubmitChannel: tcp_tas.
If you have problems with iPlanet Messaging Server, contact iPlanet customer support using one of the following mechanisms:
So that we can best assist you in resolving problems, please have the following information available when you contact support:
Useful iPlanet information can be found at the following Internet locations:
Last Updated November 19, 2002