These release notes contain important information available at the time of the version 5.0 patch 3 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 iPlanet Messaging Server.
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 5.0 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 5.0 is a "best of breed" 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 comes from Sun Internet Mail Server.
Because this is an integrated product, Netscape Messaging Server and Sun Internet Messaging Server customers may find that many processes and procedures for those products are different for the iPlanet Messaging Server. For complete information refer to the iPlanet Messaging Server 5.0 documentation at http://docs.iplanet.com/docs/manuals/messaging.html.
iPlanet Messaging Server 5.0 includes the following features:
The following bugs have been fixed in iPlanet Messaging Server 5.0 patch 3:
This section contains important information you should know before installing the product. For complete installation-related information and instructions, refer to the iPlanet Messaging Server 5.0 Installation Guide.
The minimum hardware requirements for iPlanet Messaging Server are:
For Messenger Express access, Messaging Server requires a JavaScript-enabled browser. For optimal performance, iPlanet recommends using the following browsers:
iPlanet Messaging Server is supported on the following platforms:
A list of recommended patches for Solaris 2.6 and Solaris 8 can be found at http://access1.sun.com/patch.public/.
Messaging Server 5.0 requires the following:
These products are all included on the Messaging Server CD and in the archive file. Enterprise Server is required for iPlanet Delegated Administrator.
Both Enterprise Server and Messenger Express use port 80 as the default port; be sure to specify different port numbers for one or both of these servers to avoid any conflicts. Additionally, both sendmail and SMTP use port 25 by default; it is recommended that you stop sendmail before installing the Messaging Server.
It is recommended that you record all of the port numbers you specify during the installation, along with the specific component using that port number.
Tip
Although the Directory Server is included, you may choose to use an existing Directory Server and not install the one that is included with the Messaging Server. If you do so, you must run ims_dssetup against that existing Directory Server prior to installing the Messaging Server. If you do not have an existing Directory Server or you chose to install the one included with the Messaging Server, you do not have to run ims_dssetup.
The Enterprise Server must be installed on the same machine as the Delegated Administrator, but the Messaging Server can be installed on a separate machine. Since the existence of the Enterprise Server is required for the Delegated Administrator, you must install the Enterprise Server before you install the Delegated Administrator.
The Enterprise Server and Delegated Administrator should both be installed immediately after the Messaging Server; if you start to provision the Messaging Server before installing the Delegated Administrator, you may encounter some complications in the Delegated Administrator installation.
Regardless of whether the Messaging Server is installed on the same machine as the Administration Server or the Delegated Administrator, it is recommended that you install the Messaging Server first, then the Enterprise Server, then the Delegated Administrator.
The Messaging Server 5.0 patch 3 suite of products include the problems, limitations and considerations described in the following subsections.
Under certain circumstances, the Messenger Express service will crash with a chance of corrupting the message store when a client tries to authenticate to the Messenger Express server or tries to access messages. You may notice this behavior when you use iPlanet Messaging Server 5.0 patch 3. Whether or not you have experienced this behavior, it is strongly recommended that you contact technical support to apply hotfix mshttpd-50P3-sol26-538048.tar.gz as soon as possible (538048).
The following are known issues with the Messaging Server installation:
In the Messaging Server installation, if you point to an existing Directory Server as the Users/Groups Directory Server, and that server had been set up for replication, the installation will fail. The work-around to this is to install the message server before setting up the replication.
You must install the Messaging Server in an empty directory or a directory which does not already exist. Moreover, this directory cannot contain any subdirectories which serve as mount points.
Once you complete the Messaging Server installation, you can create mount points as desired.
The installation does not automatically check for required OS patches. A list of recommended patches for Solaris 2.6 and Solaris 8 can be found at http://access1.sun.com/patch.public/.
The Solaris patch 106980-10 for Solaris 2.7 is required for the MTA to function properly. Please note that Solaris 2.7 is not a supported platform for iPlanet Messaging Server.
Note
Occasionally, error messages appear in the installation log even if the installation was successful. A successful install ends with the following message: "Go to /usr/iplanet/server5 and enter startconsole to begin managing your servers."
During a new installation process, all existing instances are shut down. After the installation, only the new instance is restarted.
If a service administrators group already exists, adding a second Messaging Server fails to add its own service administrator into the group. As a work-around, manually add the second service administrator user to the service administrator group.
Cron jobs are no longer used for scheduling periodic dirsync jobs. This is now handled by the Job Controller. After upgrading to iPlanet Messaging Server 5.0 patch 2, 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.
When multiple administrative domains existed in a directory server installation, iPlanet Messaging Server 5.0 could only be installed using the first administrative domain. For example, the messaging server would not recognize user-defined administrative domains created using the administration console.
All instances of Messaging Server 5.0 create an LDAP account in the user/group directory and use the account credentials to access user/group data from the LDAP directory.
This account, created at install time, is permitted read access to necessary directory data. This access is granted via access control items (ACI) in the directory. The ACI grants access to members of the Messaging End User Administrator group. This group is located in the 'ou=3DGroups' branch of the default domain's organization subtree. The DN of the Messaging End User Administrator Group is 'cn=3DMessaging End User Administrators Group, ou=3DGroups, o=3Dsiroe.com, o=3DISP', where:
This problem affects second and all subsequent Messaging Server 5.0 installations that share a common LDAP user/group directory. ACIs in the directory permit access to the directory data to members of the group referenced above, but only the first Messaging Server 5.0 servers account is added as a member of this group. Installer creates the account for other servers and stores their credentials in the following pair of attributes: local.ugldapbasedn and local.ugldabindcred. However, the installer fails to add this account as a member of the Messaging End User Administrator Group thereby preventing Messaging Server from accessing the necessary data from the user/group directory server.
To fix this problem from affecting the proper functioning of Messaging Server 5.0, you must add the DN of the Messaging Server account as a member of the Messaging End User Administrator Group, as follows:
dn: cn=3DMessaging End User Administrators Group, ou=3DGroups, o=3Dsiroe.com,
o=3DISP
changetype: modify
add: uniquemember
uniquemember: uid=3Dmsg-admin-2, ou=3DPeople, o=3Dsiroe.com, o=3DISP
To install iPlanet Messaging Server 5.0 on a hardened Solaris machine, create a dummy file called libx11.so.4 and add it to the LD_LIBRARY_PATH prior to installation.
Upgrading from 5.0 to 5.0 patch 3 erases mappings file contents. (524317)
The upgrade process can overwrite the server-root/msg-instance/msg/imta/config/mappings configuration file. This is caused by an error in the earlier package that introduced an empty template mappings file (server-root/bin/msg/install/templates/msg-inst/msg/imta/config/mappings) onto the system. Note that this bug only occurs when upgrading from the iPlanet Messaging Server 5.0 version and the iPlanet Messaging Server 5.0 patch 1 version. It does not occur when upgrading from iPlanet Messaging Server 5.0 patch 2.
Work-around: Before attempting to upgrade the system, delete the empty template mappings file. This should prevent the active mappings file from being overwritten.
After uninstalling the iPlanet Messaging Server product, you may get an error during re-installation if you use the same server-root directory that was previously uninstalled.
Work-around: Use a new server-root directory when performing the re-installation.
During the uninstallation program, the sendmail program is not restored because it is renamed as sendmail.bk during the original installation process.
Work-around: Rename the sendmail.bk file back to its original name prior to running the uninstallation program.
When you attempt to upgrade the iPlanet Messaging Server to newer release versions, the upgrade will fail in a Sun Cluster 2.2 environment or a Veritas Cluster Server 1.1 or later. The failure will occur at the point where the install tries to run stop-msg.
/opt/SUNWcluster/bin/hareg -n your_data_service
-For Veritas Cluster Server 1.1 or later:
/opt/VRTSvcs/bin/hares -offline your_mail_resource -sys physical_hostname
-In Sun Cluster 2.2, rename the hareg command located in:
-In Veritas Cluster Server 1.1 or later, rename the hares command located in:
/opt/SUNWcluster/bin/hareg -y your_data_service
-For Veritas Cluster Server 1.1 or later:
/opt/VRTSvcs/bin/hares -online your_mail_resource -sys physical_hostname
To manually upgrade the HA software, unzip msg/msgha.zip and copy /msg/bin/msg/ha/sc/agent/* to /opt/SUNWcluster/ha/msg on both machines.
Work-around: You will need to save the job_controller.cnf and dispatcher.cnf files prior to the upgrade. At the completion of upgrade, you should restore the files.
MMP will change the pipe channel permissions if it is installed on the same machine as iPlanet Messaging Server. The program delivery function will not work if the pipe channel does not have the correct privileges.
Work-around: If you install iPlanet Messaging Server and MMP on the same machine, you should run the installation program to first install the iPlanet Messaging Server. You should then run the installation program again to install MMP. Be sure to use different server-roots for each installation.
If you upgrade from the Beta version of iPlanet Messaging Server 5.0 to the RTM or later version of iPlanet Messaging Server 5.0, you need to perform the following tasks:
The following are known problems with the Messaging Server:
When the primary directory server resumes after a failover, the LDAP queries are still directed to the failover Directory Server.
By default, the authentication cache is on; you must restart all the services on the server to make the deletion of a user immediately effective.
To eliminate this behavior, turn off the authentication cache by setting service.authcachettl to zero using the configutil utility and restarting all the services.
Because non-anonymous LDAP searches can take a long time (up to ten times as long as anonymous LDAP searches), dirsync will take a very long time to run as well.
A work-around is to 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.
From this release forward, the mgrpErrorsTo attribute will not support multiple values. If you want to specify multiple recipients for error message, create a mailing list and specify the mailing list address as the value for the mgrpErrorsTo attribute.
To provision users, use the iPlanet Delegated Administrator and/or its command line utilities, or the Users/Groups tab in the Administration Console.
The password you specify when requesting an SSL certificate in the Administration Console certificate wizard for encrypting the private key in the trust database is not saved to sslpassword.conf.
The work-around is to either use the default password "netscape!" or manually edit the sslpassword.conf file and specify the password of your choice.
After installing Messaging Server 5.0, you should disable end user access to the Administration Server by opening the Administration Server Console and unchecking the checkbox for "Enable End User Access" in the Configuration->Access tab.
While all iPlanet Messaging Server products require an sslpassword.conf file to enable SSL, the format used by the MMP is different from the format used by the other Messaging Server servers. The MMP requires the file to contain the following:
Communicator Certificate DB:password
The rest of the Messaging Server servers use:
Internal (Software) Token:password
In the above examples, password should be replaced with the password you selected when installing your certificate.
These servers cache the LDAP entries of the users who have recently logged in for the time specified in the configuration parameter service.authcachettl.
The Job Controller listens on all interfaces, so it is necessary to change the tcp_port option in the job_controller.cnf file when performing an HA installation.
It is not possible to configure an expire rule through the command line. For example, the following command returns an error:
configutil -o store.expirerule.name.folderpattern -v pattern
The work-around is to use the console. After an expire rule is created, the parameters can be modified through the configutil utility.
Due to the caching scheme, changing domain properties like authorized services or status in LDAP does not take effect in IMAP, POP, and HTTP until these services are restarted.
In order for the imsimta dirsync utility to work efficiently, the following lines need to be added to the slapd.ldbm.conf file:
index modifytimestamp eq
index createtimestamp eq
In the console, if you specify a % character in the expire rules, it changes to \r. For example, if you specify user/%/Trash, looking up the store.expirerule.*.folderpattern, it displays user/\rrash. As a work-around, if you want a % character in the expire rules, perform this function using the configutil command.
The sslpassword.conf file is not created when an SSL certificate is created from the console. This occurs when only the console, administration server, and MMP are installed (no Messaging Server or Directory Server).
When running an upgrade on a multiple-instance installation, if the Directory Server installation is selected, the upgrade fails. The installer prompts for directory manager information twice and fails after the second time.
In order to avoid running out of address space in a single process the following procedures should be done:
max_users * avg_message / 200000
max_users is the maximum number of simultaneously connected users and avg_message is the average number of messages per user.
The hold_master program under server_root/bin/msg/imta/bin does not work if that program is not setuid. The work-around is to execute the following:
chmod 4750 server_root/binmsg/imta/bin/hold_master
The MMP configuration files are case sensitive. This means that parameter names must use the capitalization shown in the documentation or they will be ignored.
If an incremental dirsync is in progress at the time of a high availability 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, execute the following:
Any updates which occurred since the imsimta dirsync -F command was run will be lost. After executing imsimta recover-crash, execute:
The imsimta recover-crash utility was not documented in the iPlanet Messaging Server 5.0 Reference Manual. See the "Reference Manual" section in "Documentation Changes" for a description and syntax of this command.
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.Siroe.Com, then the access control list must include *.Siroe.Com. Due to this bug, *.siroe.com will not suffice.
When a quota database is corrupted and removed, the reconstruct -m command will re-create it, but it does not receive the user quota from LDAP. The quota is set to NO LIMIT. Quota enforcement does not function.
When you create a user or group through the Administration Console, ensure that you are selecting the correct organizational unit (ou) under which you want to create a user or group. To do so, use the drop-down list to choose New Organizational Unit; then click Create.
In the Select Organizational Unit window, select the directory subtree (ou) to which the organizational unit will belong. Placing your cursor on any of the directory subtrees will reveal the complete DN of the organizational unit.
When creating a new user in the Administration Console in a localized environment, you may not be able to enter 8-bit characters (i.e. Ë) in the First Name, Last Name, and Common Name fields.
Work-around: Enter the 8-bit character into a non-Console application, copy the character, and then paste it into the Administration Console, using <Control> + V.
In order for configutil to work properly under ja_JP.PCK locale, you should check encbylang.properties in server-root/msg-serverID/bin/msg/bundles to see if the setting is correct. Edit encbylang.properties in server-root/msg-serverID/bin/msg/bundles and the specify character set associated with LANG environment variable. There is a typographical error with ja_JP.PCK.
To provide different classes of service to your users, you can use the Class of Service Plug-in that is packaged with the iPlanet Directory Server DSRK and works with the Netscape Directory Server 4.1 or higher. Instructions on setting up and configuring Class of Service are located at http://home.netscape.com/eng/server/directory/DSRK/4.1/cos.htm.
Please note that with iPlanet Messaging Server, the attribute inetCOS (from the ipUser object class) is the value to be used in the cosSpecifier attribute when creating a COS scheme as described in the COS documentation.
An example of a COS scheme entry using iPlanet Messaging Server is as follows:
dn: uid=3DmailQuotaScheme,ou=3DCOS,o=3Dsiroe.com
objectclass: top
objectclass: cosDefinition
cosTemplateDn: ou=3DMailSchemeTemplates,ou=3DCOS,o=3Dsiroe.com
cosTargetTree: o=3Dsiroe.com
cosSpecifier: inetCOS
cosAttribute: mailQuota
The following are known problems with iPlanet Delegated Administrator for Messaging.
If a domain is added down a list of subdomains, it is best to create each subdomain before creating the target domain. The reason for this is that if the target subdomain is created without the intervening domains, those domains will be created without a container and it is not possible to add a container to those domains in the future.
In the Change Password screen, if you enter a new password that contains spaces, you will receive an error message. Hitting the Shift and Reload keys simultaneously will get rid of the error message, as will closing down the browser and then restarting it again. It is suggested that you do not use spaces in your passwords.
It is not possible to create a user with the same user ID as a deleted user until the user has been purged from the system.
The MTA's SMTP AUTH facility does not support mail filtering (usually set with the Delegated Administrator console). If a mail filter is set on a user or domain, then SMTP AUTH access will be rejected for that user or domain.
Work-around: You are required to shift the focus from the field most recently edited field to another field on the same form (by using the Tab key or mouse) before clicking on OK.
It is possible to remove the Top-Level Administrator priviledges from any Top-Level Administrator session, even if only one Top-Level Administrator exists in the system.
Work-around: Do not remove Top-Level Administrator privileges for any user when only one Top-Level Administrator exists in the system.
In any domain, it is possible to create subdomains, user accounts, and mail lists beyond the specified maximum limit.
After performing the uninstall for iPlanet Delegated Administrator, the iPlanet Delegated Administrator for Messaging class patch still resides in the web server configuration file. This can cause problems if the user is trying to install the new iPlanet Delegated Administrator for Messaging into a different Delegated Administrator root.
Work-around: Install the iPlanet Delegated Administrator for Messaging into the same location as the previous version or modify the jvm12.conf file to refer to the correct location.
When performing an upgrade of the iPlanet Delegated Administrator for Messaging from the 5.0 version to the patch 2 version, the upgrade installation process fails.
The imsdaaci command adds empty ACIs and Service Administrators groups to the directory. 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 OSI root is "o=3DISP", then the DN of the service administrator group is "cn=3DService Administrators,ou=3DGroups,o=3DISP". To designate the account "uid=3Dofanning, o=3Dsiroe.com, o=3DISP" 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:
If you specify the DN of the DC tree as the DN of the organization node when you create a new domain, iPlanet Delegated Administrator for Messaging does not set the inetDomainBaseDN to point back to the same node.
For example, if you want the users/groups of budgie.siroe.com to be located under dc=3Dbudgie, dc=3Dsiroe, dc=3Dcom, o=3Dinternet, iPlanet Delegated Administrator for Messaging does not set the inetDomainBaseDN in dc=3Dbudgie, dc=3Dsiroe, dc=3Dcom, o=3Dinternet to point back to the same node.
Work-around: New options have been added to the imadmin domain create utility so inetDomainBasedDN can point back to the same node when you specify the DN of the DC tree as the DN of the organization node. The new non-mandatory options are:
These options are mutually exclusive; in other words, only one option can be used at a time.
Currently, you can provide multiple vacation messages in different languages only the Administration Console. iPlanet Delegated Administrator does not yet have language options for vacation messages.
Work-around: End users may contact the administrator to set additional vacation messages in their respective languages through the Administration Console.
The ja_JP.PCK locale is not supported by iPlanet Delegated Administrator for Messaging. Instead, it is recommended that you should use the ja locale.
For the most updated iPlanet Delegated Administrator for Messaging release notes, refer to the latest iPlanet Messaging Server release notes at: http://docs.iplanet.com/docs/manuals/messaging.html
When you save the information that you entered in the Vacation Auto-Responder tab for the first time, the next window will have an awkward layout.
Work-around: If you refresh the page, the layout will return to normal. Or, if you choose another tab option and then choose the Vacation Auto-Responder, the page will return to normal.
The following are known problems with iPlanet Messenger Express:
When the MTA attempts to authenticate to SMTP, Messenger Express drops the message without forwarding an error message. The following parameters have been added:
These parameters allow someone using Messenger Express to receive the same authenticated SMTP messages that they would normally receive using Netscape Communicator. In order for this to work, the user ID and password given to the mshttpd must be a store administrator; they must exist in the store.admins list (for example, admin and admin). After setting these parameters, any mail received from a local user should have the word "Internal" appearing next to the "From:" header in the Message View window.
From the Personal Address Book page, if you resize the browser window, you are taken back to the message list and you also receive a JavaScript error.
This problem only occurs with Netscape Navigator and appears to be fixed in the 6.0 release of Navigator.
Note
Work-around: Ensure that another server is not running that uses the same port (80 by default) or SSL port (443 by default). If necessary, the SSL port can be disabled by the following command:
configutil -o service.http.enablesslport -v 0
In a Japanese EUC locale, the vcard of a message is displayed as garbage when using a Netscape Communicator 4.x browser on a Solaris platform. Additionally, a user will not be able to attach Japanese text files to messages using a Netscape Communicator 4.x browser on a Solaris platform.
It is recommended that you use 7-bit ASCII-only letters in your default cn (common name), and specify your native name under appropriate language version of your cn.
However, if the cn is not in 7-bit ASCII format, the Administrator may disallow a non-ASCII cn in the "From:" header of outgoing messages, by setting the following new configutil parameter to 1:
local.service.http.forceasciifrom (Default: none).
When the new parameter is set to 1, the outgoing message will display the email address in the "From:" header instead of the non-ASCII formatted cn.
If you are using Internet Explorer 5.5, Messenger Express may stop running after the login screen.
Work-around: Use Internet Explorer 5.5 Service Pack 1 (SP1) if you encounter this behavior.
The new language setting is saved in the LDAP authentication cache; the changes may not take effect for up to approximately fifteen minutes.
This section describes any errors or changes to the iPlanet Messaging Server 5.0 documentation set.
This section describes any errors or changes to the iPlanet Delegated Administrator for Messaging Installation and Administration Guide.
In Chapter 2 "Installation Instructions", Step 5: Install Delegated Administrator, Install Screen 4—Enable Purge Command states:
CGI Path—use the default. Typically this is
<machine name>/Tasks/operation
These instructions only apply if you are installing iPlanet Delegated Administrator for Messaging on the same machine in which you have installed the messaging server. The correct instructions are:
CGI Path—use the default. Typically this is
msg-instance/Tasks/operation
msg-instance represents the server instance (or default host machine name) on which you installed iPlanet Delegated Administrator for Messaging. For example, if you installed it on the machine siroe, the path is: msg-siroe/Tasks/operation.
In Appendix B "Installing the Messaging Multiplexor", the section "Post-Installation Procedures" states:
"The recommended method for doing so [binding to authenticate users against the Directory Server] is to copy the values for local.ldapsiedn and local.ldapsiecred from a Messaging Server installation to the BindDN and BindPass options in an MMP installation."
The actual values to copy from a Messaging Server installation are local.ugldapbinddn and local.ugldapbindcred, not local.ldapsiedn and local.ldapsiecred as incorrectly noted in the MMP documentation.
This section describes any errors or changes to the iPlanet Messaging Server 5.0 Administrator's Guide.
In chapter 10, "Managing the Message Store," the section "Using the stored Utility" states:
"The stored utility automatically performs cleanup and expiration operations once a day at midnight."
The cleanup and expire operations are actually performed at 11:00 pm.
The following information should be added to the "Configuring SMTP Relay Blocking" section of chapter 9, "Mail Filtering and Access Control."
The iPlanet Messaging Server is by default configured to block attempted SMTP relays; that is, it rejects attempted message submissions to external addresses from unauthenticated external sources (external systems are any other system than the host on which the server itself resides). This default configuration is quite aggressive in blocking SMTP relaying in that it considers all other systems to be external systems.
IMAP and POP clients that attempt to submit messages via the iPlanet Messaging Server system's SMTP server destined for external addresses, and who do not authenticate using SMTP AUTH (SASL), will find their submission attempts rejected. Thus, you will likely want to manually modify your configuration so that it recognizes your own internal systems and subnets from which relaying should always be accepted.
Which systems and subnets are recognized as internal is normally controlled by the INTERNAL_IP mapping table, which may be found in the file server-instance/imta/config/mappings.
For instance, on an iPlanet Messaging Server system whose IP address is 123.45.67.89, the default INTERNAL_IP mapping table would appear as follows:
INTERNAL_IP
<blank line>
<space> $(123.45.67.89/32) $Y
<space> 127.0.0.1 $Y
<space> * $N
Here the initial entry, using the $(IP-pattern/signicant-prefix-bits) syntax, is specifying that any IP address that matches all 32 bits of 123.45.67.89 should match and be considered internal. The second entry recognizes the loopback IP address 127.0.0.1 as internal. The final entry specifies that all other IP addresses should not be considered internal.
You may add additional entries by specifying additional IP addresses or subnets before the final $N entry. These entries must specify an IP address or subnet (using the $(.../...) syntax to specify a subnet) on the left side and $Y on the right side. Or you may modify the existing $(.../...) entry to accept a more general subnet.
For instance, if this same sample site has a class-C network, that is, it owns all of the 123.45.67.0 subnet, then the site would want to modify the initial entry so that the mapping table appears as follows:
INTERNAL_IP
<blank line>
<space> $(123.45.67.89/24) $Y
<space> 127.0.0.1 $Y
<space> * $N
Or if the site owns only those IP addresses in the range 123.45.67.80-123.45.67.99, then the site would want to use:
Note that the server-instance/imsimta test -match utility can be useful for checking whether an IP address matches a particular $(.../...) test condition. The imsimta test -mapping utility can be more generally useful in checking that your INTERNAL_IP mapping table returns the desired results for various IP address inputs.
After modifying your INTERNAL_IP mapping table, be sure to issue the server-instance/imsimta refresh command so that the changes take effect.
Further information on the mapping file and general mapping table format, as well as information on imsimta command line utilities, can be found in the iPlanet Messaging Server Reference Manual.
In Chapter 1, under "Netscape Messaging Server 4.x Regressions/Changes/Transitions," the second sentence reads, "You cannot use a group name as a value for the group attribute, mgrpAllowedBroadcaster".
It should read, "The group attribute, mgrpAllowedBroadcaster will support a group value, however, it will not support a nested group."
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.
Two new options have been added to the MoveUser utility to accommodate users under hosted domains. The options are:
The syntax usage for MoveUser is now:
MoveUser -s srcmailhost[:port] -x proxyuser -p password -d destmailhost[:port]
[-u uid | -u uid -U newuid | -l ldapURL -D binDN -w password
[-r DCroot -t defaultDomain]]
In chapter 5, "MTA Configuration," the section "Dispatcher" states:
"When using the Dispatcher, it is possible to have several multithreaded SMTP, POP3, and IMAP servers running concurrently."
The Dispatcher does not control POP3 and IMAP servers in iPlanet Messaging Server 5.0.
In chapter 3, "Delegated Administrator Command-line Utilities, the syntax for imadmin domain purge should show the -d domain (the domain to be purged) as an non-mandatory option. The syntax should be as follows:
Both imsbackup and imsrestore have been updated to make -f a required parameter.
As a result, you will not see garbage on the console when data is backed up. Updated usages are listed below:
The imsimta recover-crash utility was not documented in the iPlanet Messaging Server 5.0 Reference Manual. The following is the syntax and description for the imsimta recover-crash command:
Syntax: imsimta recover-crash [-i]
Description: The imsimta recover-crash command removes the apparently corrupted databases and restores them from the backup, if available. An incremental dirsync will be run if the backup is available. If the backup is not available, then the administrator is advised to run a full dirsync.
The option for this command is:
The documentation for the MTA SDK is included in the iPlanet Messaging Server 5.0 packaging. The documentation and man pages included were originally developed for Sun Messaging Server 3.5 and were not updated for iPlanet Messaging Server 5.0. The name and path references may be out of date, but the technical information is still valid.
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 14, 2001