Release Notes for iPlanet Messaging Server

• On Windows NT, two commands require DLL files to be copied. (4554830)

  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.

• On Windows NT, the imsdirmig -l option does not work. (4554958)

• When migrating directory entries from Netscape Messaging Server 4.x, an LDAP filter must be specified. (4554984)

  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.

• Migration from Sun Internet Mail Server does not reset the default host used for provisioning. (no bugid)

  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.

• Migrating Personal Address Book (PAB) entries from Netscape Messaging Server 4.15 to iPlanet Messaging Server 5.1 patch 1 requires the following steps: (4557878)
  1. When enabling multi-schema support, comment out ns-pab-schema.conf in the ns-schema.conf file.

  2. After you run the ims_dssetup utility, you must regenerate the index for the following attributes on the directory server that holds the PAB entries:
     1. memberOfPAB [index type pres,eq]

     2. memberOfPABGroup [index type pres,eq]

     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

  3. After you install iPlanet Messaging Server, you will need to turn on the PAB migration as follows: configutil -o local.service.pab.migrate415 -v on

     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.

• iPlanet Delegated Administrator for Messaging and Collaboration install breaks the merged schema support. (4557739)

  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

• Migration procedures from Netscape Messaging Server to iPlanet Messaging Server 5.1 patch 1 on Windows NT are not specified in the iPlanet Messaging Server Migration Guide. (4538480)

  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.

  1. (Step 1) Ensure that all messages in the SMTP server queues are processed and that the queues are empty.

     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

     Wait for the queue to empty.

  2. (Step 2) Run perl ims_dssetup.pl against the Netscape Messaging Server LDAP server; when prompted by ims_dssetup.pl to update the DS schema, chose to update the schema.

  3. (Step 3) Enable multi-schema support (SIMS/Netscape Messaging Server/iPlanet Messaging Server) by adding the merged schema files (merged.oc.conf and merged.at.conf) to the directory server. Refer to "Supporting Multiple Schemas" in Appendix B of the iPlanet Messaging Server Migration Guide. Also, comment out any include directives for the following schema files added in the previous step: um50-common-schema.conf and ims50-schema.conf by adding a # before the include keyword and following the steps outlined in that step.

     See the iPlanet Messaging Server Installation Guide for details.

  4. (Step 4) Uninstall Netscape Messenger Server only, and choose to preserve the user mail store. Do not uninstall Directory Server.

  5. (Step 5) Rename the msg-instance directory (where the user mail store is located) to another name, such as "mailstore".

  6. (Step 6) Re-implement Netscape Messaging Server vanity domains in iPlanet Messaging Server.

  7. (Step 7) Install iPlanet Messaging Server in the same server directory where Netscape Messaging Server is located. Choose NOT to install Directory Server. For the following install prompt, Default Organization DN [o=siroe.com,o=OldDirRoot], use the default value (o=siroe.com,o=OldDirRoot). Note that this is not where the Netscape Messaging Server user entries reside. The entries will remain in the current namespace for now.

  8. (Step 8) Stop all server processes:
     InstanceRoot/stop-msg

  9. (Step 9) Map or modify the existing Netscape Messaging Server directory namespace to the iPlanet Messaging Server directory namespace.

     Refer to "Using Existing Directory Information Trees in the iPlanet Messaging Server" in Appendix B of the iPlanet Messaging Server Migration Guide.

  10. (Step 10) Set the default Organization Tree.

      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.

  11. (Step 11) Migrate the Netscape Messaging Server message store to iPlanet Messaging Server message store.

      Change the primary store partition path to point at the Netscape Messaging Server 4.x message store path as follows:

      1. Use the iPlanet Messaging Server Administration Console to change the message store configuration to point to all the Netscape Messaging Server 4.x mail store partitions (mailstore is the example given in step 5).

      2. Remove the user subscriptions directory.

      3. Copy the Netscape Messaging Server message store:

         NMSServerRoot/mailstore/store/user/
         to:
         iMSServerRoot/msg-instance/store/user/

         (mailstore is the example given in step 5.)

      4. Copy the mboxlist file:

         NMSServerRoot/mailstore/store/mboxlist/data.db2
         to
         iMSServerRoot/msg-instance/store/mboxlist/folder.db

      5. Copy the quota files:

         NMSServerRoot/mailstore/store/quota.db2
         to
         iMSServerRoot/msg-instance/mboxlist/quota.db

      6. Do not copy any other files!

  12. (Step 12) Configure dirsync to support the new multi-system schema by using configutil to add the following two parameters:

      InstanceRoot/configutil -o local.imta.schematag
         -v "ims50,nms41"
      InstanceRoot/configutil -o local.imta.ugfilter
         -v (|(objectClass=inetLocalMailRecipient)
         (|(objectClass=mailRecipient) (objectclass=mailGroup)))

  13. (Step 13) Run a full dirsync to pick up the user and group entries:
      InstanceRoot/imsimta dirsync -F

  14. (Step 14) Restart iPlanet Messaging Server. You can now see the Netscape Messaging Server 4.x user mailboxes.

      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.
      
      

      ---

      Note

      The default configuration of the newly installed iPlanet Messaging Server blocks all SMTP relaying. To align default configuration to your site policy, refer to the iPlanet Messaging Server Migration Guide, Chapter 1, section titled "Netscape Messaging Server 4.x Regressions/Changes/Transitions," sub-section titled "SMTP Relay Function."

      ---

      
      
      

  15. (Step 15) Upgrade the quota database to enable new features. Run the following as a mail server user:

      cd iMSServerRoot/bin/msg/admin/bin
      reconstruct -q

  16. (Step 16) Once the new server is up, upgrade all user and group directory entries to the iPlanet Messaging Server schema using imsdirmig:

      imsdirmig -b "o=sesta.com" -M nms -D "cn=Directory Manager" -w secret -m both -F "(!(cn=postmaster))"

  17. (Step 17) Disable multi-schema support.

      Once all the directory entries have been upgraded to iPlanet Messaging Server schema, multi-schema support is no longer needed. Using configutil, delete the following two parameters:

      InstanceRoot/configutil -o local.imta.schematag -v ""
      InstanceRoot/configutil -o local.imta.ugfilter -v ""

• Backing out of iPlanet Messaging Server 5.1 patch 1 fails. (4704258)

  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.

• After a migration from SIMS, complications arise when uid attributes in LDAP include uppercase characters. (no bugid)

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.

1. In most situations, this is the preferred option. During migration, instead of using the default imsrestore command line utility, use imsrestore with the rename option. Identify which characters in a user's mailbox name (the characters will all be in lowercase) need to be changed to uppercase in order to match the user's uid in LDAP and change them to uppercase. Notice, when using the rename option, DO NOT change the case of the domain portion of the user ID, for example sesta.com. It must remain in lowercase or the mailbox name will not be recognized when a user logs in. Refer to the iPlanet Messaging Server Reference Manual for information on renaming users with imsrestore.

2. Change LDAP uid attributes to all lowercase characters. However, for many sites LDAP is required for several different applications and changing the uid attribute could negatively affect those other applications.

Upgrade

This section describes known problems, limitations, and considerations when upgrading iPlanet Messaging Server.

• During the upgrade process, any customizations made to the Messenger Express user interface are lost. (no bugid)

  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 upgrade, the link from Messenger Express to iPlanet Delegated Administrator for Messaging and Collaboration is broken. (4538205)

  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.

• Directory synchronization is now scheduled by the Job Controller. (4586968)

  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.

• During the upgrade process, you are unnecessarily prompted for the following information about iPlanet Delegated Administrator for Messaging and Collaboration. (4538472)

  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

iPlanet Messaging Server

This section describes known problems, limitations, and considerations with iPlanet Messaging Server.

• Job Controller does not start - system error 1067 (4527385)

  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:

  1. Go to the config directory (server-root\msg-instance\imta\config).

  2. Run a command from the tail of the c:\temp\iplanet-msg-install.log file. This is the jre command to run the imtaconfig.jar file.

  3. Add -nojit to the jre command.

     The command begins with "jre -cp ..." It also indicates the cmdpath and the runpath. The cmdpath is the path to the command and should be pre-pended to the "jre -cp ..." command indicated above. The runpath is the directory in which to run the command.

  For example, if the c:\temp\iplanet-msg-install.log file contains the following (at the end of the file):
  
  

  MESSAGE: running command jre -cp "server-root\bin\msg-instance\imta\classes\imtaconfig.jar" com.siroe.msg.imta.config.InitConfig -d siroe.com -r siroe.com -h siroe.com -c sever-root\msg-instance\imta\config -N cmdpath: server-root\bin\base\jre\bin runpath: server-root\msg-instance\imta\config

  
  
  

  1. Then execute the command as follows (note that -nojit is added after jre):

     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:
     
     

     Utils.IMTA_CHANNEL_DEFAULTS = ChannelDefaults.opt imta: File:server-root\msg-instance\imta\config\mappings does not exist. IMTA initial configuration files generated

     
     
     

  2. Run the following commands:

     cd server-root\msg-instance

     imsimta cnbuild

  3. Proceed with a normal installation:

     start-msg

     imsimta dirsync -F

• The program delivery function requires the Messaging Server user to have a home directory. (4560660)

  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.

• For a short period of time (default is 15 minutes), it might be possible to log in to the account of a user marked for deletion. (4588068, 4576530)

  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.

• LDAP search performance is significantly impacted by ACIs in Directory Server version 4.x. (4534356)

  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.

• The mgrpErrorsTo attribute is a single-valued attribute.(4543159)

  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.

• Group attribute mgrpMsgRejectAction does not work. (4543187)

  The mgrpMsgRejectAction attribute is not supported in iPlanet Messaging Server.

• Anonymous login for IMAP is not supported. (4543259)

• Cannot create expiration rules through the command line. (4542514)

  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.

• The% character does not work correctly in expiration rules. (4542729)

  A possible work-around is to use * instead.

• Domain cache does not refresh. (4542726)

  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.

• Incremental dirsync and HA. (4566005)

  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:

  WARNING: sync_init: .dirsync_unsafe exists; database may be corrupted

  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

• Administration Server access control host names are case-sensitive. (4541448)

  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.

• On a Solaris client with a Netscape browser, Administration Console can only launch Help if a browser is already open. (4541748, 4539844)

  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:
  
  

  NETSCAPE=/usr/dt/bin/netscape # or whatever the path to the real netscape is

  EXITCODE=0

  if [ "$1" = "-remote" ]

  then

  $NETSCAPE $@ 2>/tmp/_netscape_remote_$$

  if [ $? -ne 0 -o -s /tmp/_netscape_remote_$$ ]; then EXITCODE=1 ; fi

  rm /tmp/_netscape_remote_$$

  exit $EXITCODE

  else

  $NETSCAPE $@

  fi

  
  
  

• On Windows NT, Administration Console does not launch Help if a browser is already open. (4539844)

  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.

• As of iPlanet Messaging Server 5.1 patch 1, SMTP logging to mail.log_current is turned off by default. (4564207)

  Refer to the Administration Guide on how to enable SMTP logging.

• Some POP mail clients will not accept @ in a user ID. (4540050)

  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:

  1. Configure the server to use both + and @. This change can be implemented with the following command: configutil -o service.loginseparator -v "@+"

  2. Inform POP client users that they should log in with + as the login separator, not @.

• The imsdaaci command does not create the Service Administrator user entry. (4562225, 4558040)

  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:

  dn: uid=ofanning, o=sesta.com, o=isp
  changetype: modify
  add: memberof
  memberof: cn=Service Administrators, ou=groups, o=isp
  

• On Solaris, upon startup, Console might display spurious error messages related to the Sun Cluster environment. (4562861)

  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.

• CRAM-MD5/DIGEST-MD5 do not work with external SMTP connections. (4540532)

  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

• SMTP does not support SSL client certificate authentication. (4560035)

• The MMP BadGuy configuration parameter, BGExcluded, does not work. (4538273)

  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.

• On a Solaris client with a Netscape browser, certain fonts for Japanese Kanji characters might not display properly. (4558408)

  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.

• To take effect, changes made using configutil often require a restart of the affected server or servers. (4538366)

• Messaging Server does not support multiple instances under the same server root. (4555122)

• Some options in the quotacheck utility are not working properly. (4555153)

  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.

• mboxutil utility incorrectly converts Greek and Central European mailbox names. (4687437)

  The user should first determine the system's local. For example, the Greek locale might be:

  [mailsrv@sesta]%locale
  LANG=el

  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.

• Authentication fails when logging in through MMP (timeout received). (4707864)'

  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.

• Duplicate messages are delivered according to the sieve rule. (4708218)

  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):

  if subject="sun" fileinto folder sunstuff

  if subject "solaris" fileinto folder sunstuff

  Then, if the subject "sun solaris" is received, two copies are received.

  Another behavior that may occur is the following:

  if subject="sun" fileinto folder sunstuff

  if subject="solaris" filinto folder sun-other

  Because two different folders are specified, two copies are received—one in each folder. This is the expected behavior if the sieve rules do not contain a stop.

• Change in behavior with imsimta dirsync command: stored process must be running. (4748550)

  Starting with the iPlanet Messaging Server 5.1 Patch 1 release, the stored process must be running when you use the imsimta dirsync command. If you want to run imsimta dirsync without starting up all the services, the stored process should be started up before running imsimta dirsync.

iPlanet Messenger Express

The following are known problems with iPlanet Messenger Express:

• When using Netscape Navigator 4.x with Messenger Express, any window resize causes the session to return to the Inbox message list. (4579429)

• Japanese EUC locale issues when using Netscape Communicator browser on Solaris. (4561469, 4561550)

  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.

• For Messenger Express, if using Internet Explorer, you should use Internet Explorer E 5.5 SP1. (4562547)

  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.

• Messenger Express with Greek on Netscape Communicator creates various issues. (4560999)

  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.

• On Internet Explorer 5.0, very large messages are truncated when placed into the Sent folder. (4558055)

  Due to timing issues in Internet Explorer builds before 5.5 SP1, very large messages are truncated on slower machines with small amounts of memory. Use the recommended build of Internet Explorer 5.5 SP1.

---

Documentation Changes

This section describes any errors or changes to the iPlanet Messaging Server 5.1 documentation set.

Administrator's Guide

• Supporting documentation for Enabling Single Sign-On between Messenger Express and Delegated Administrator for Messaging should contain information to Enable UTF8 Parameter Encoding in the Enterprise Server configuration. (4651940)

  To enable single sign-on between Messenger Express and Delegated Administrator, you must perform additional steps as follows:

  1. Configure Directory Server.
     1. Create a proxy user account entry in the Directory Server.

     2. Create an ACI (Access Control Instruction) for proxy authentication.

  2. Configure iPlanet Delegated Administrator for Messaging and Collaboration.
     1. Add the proxy user credentials.

     2. Add the single sign-on cookie information.

     3. Add the participating servers verification URL.

     4. Enable UTF8 Parameter Encoding in the Enterprise Server configuration.

        To enable UTF8 Parameter Encoding in the Enterprise Server configuration:

     5. Go to the directory where the file context.properties is stored:

        iWS_root/https-instancename/config

     6. In the file contexts.properties, add the following entry:

        context.ims50.parameterEncoding=utf8

  3. Restart the Enterprise Server.

• User quotas enforced. (no bugid)

  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.

Installation Guide for UNIX

• Updated High Availability instructions. (no bugid)

  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:

  • High availability for the Messaging Server is not installed by default; be sure to select High Availability Components from the Custom Installation menu if you install Sun Cluster 2.2 or Veritas Cluster Server 1.1 or later.

  • When you are asked for the fully-qualified domain name of the messaging server host, be sure to specify the fully-qualified HA logical host name for the messaging server. During the install, TCP connections using this logical hostname will be attempted.

  • The HA fault monitor agent requires the tcpclnt binary file in Sun Cluster 2.2 SUNWscpro package. It is mandatory to install this probing feature; otherwise, unresponsive messaging servers will not be detected.

  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:

  1. Run the setup program on the primary node to start the Messaging Server installation:

     ./setup

  2. Select Custom installation from the list of installation types.

  3. Select the Sun Cluster 2.2/Veritas HA component in addition to the Messaging Server components you are installing on the primary node.

     On the secondary node, you should only install High Availability. To do so, follow these steps:

  4. Conduct a failover to the secondary node.

  5. Run the setup program on the secondary node to start the Messaging Server installation:

     ./setup

  6. From the list of installation types, select Custom installation, then select just the Sun Cluster 2.2/Veritas HA component from the iPlanet Messaging Applications.

     During the Messaging Server installation, the setup program checks to see if the Veritas Cluster Server has been installed and properly configured. If so, then the appropriate high availability files are installed.

  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:

  1. Run the setup program on the primary node to start the Messaging Server installation:

  ./setup

  1. Select Custom installation from the list of installation types.

  2. Select the Sun Cluster 2.2/Veritas HA component in addition to the Messaging Server components you are installing on the primary node.

     On the secondary node, you should only install High Availability. To do so, follow these steps:

  3. Switch the logical_IP and shared disk to the secondary node.

  4. Run the setup program on the secondary node to start the Messaging Server installation:

     ./setup

  5. From the list of installation types, select Custom installation, then select just the Sun Cluster 2.2/Veritas HA component from the iPlanet Messaging Applications.

  Post-Installation Instructions for Sun Cluster 2.2. You must perform the following steps on the secondary node:

  1. Conduct a failover to the secondary node.

  2. Copy the server-root/bin/msg/ha/sc/config/ims_ha.cnf file to your administrative file system disk mount point directory for this logical host (for example, $LOGICAL_HOSTNAME.

  3. Additionally, you must first register the Messaging Server data service before using it by running the hareg -Y command.

  4. If you want to change the logical host timeout value, use the following command:

     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:

  • Start the messaging servers with the start-msg command in the msgserver-root directory.

  • Run the ha_ip_config script to bind the IP addresses for the msg-instance on the servers. For instructions on running the script, see "Binding IP Addresses for Single and Multiple Messaging Server Instances on a Server" in the section on Installing High Availability for Sun Cluster 3.0.

  • Run stop-msg ha in the msgserver-root directory to stop the messaging servers.

  • Stop the directory and administration server processes with the following commands:

msgserver-root/slapd-instance/stop-slapd

msgserver-root/stop-admin

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:

1. Bring the iMS5 service group offline and disable its resources.

2. Remove the dependencies between the mail resource, the logical_IP resource, and the mountshared resource.

3. Bring the iMS5 service group back online so the sharedg resource is available.

4. If you are using the dirsync option, remove the dirsync entries from the cron job table on both nodes.

5. Delete all of the Veritas Cluster Server resources created during installation.

6. Stop the Veritas Cluster Server and remove following files on both nodes, if no more instances exist:

   /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

7. Remove the Messaging Server entries from the /etc/VRTSvcs/conf/config/main.cf file on both nodes.

8. Remove the /opt/VRTSvcs/bin/MsgSrv/ directory from both nodes.

9. If the directory server is installed in the same server-root directory as messaging server, be sure the directory server is running.

10. Perform the normal uninstall procedures as described in Appendix B, "Running the Uninstall Program" of the iPlanet Messaging Server Installation Guide for UNIX.

11. Remove the instance entry from the /etc/msgregistry.inf file on both nodes if multiple instances are installed; otherwise, remove the /etc/msgregistry.inf file on both nodes.

To uninstall the high availability components for SunCluster follow these steps:

1. Run the following command to stop all processes:

   hareg -n

2. If the directory server is installed in the same server-root directory as messaging server, be sure the directory server is running.

3. Perform the normal uninstall procedures as described in Appendix B, "Running the Uninstall Program" of the iPlanet Messaging Server Installation Guide for UNIX.

4. Remove the instance entry from the /etc/msgregistry.inf file on both nodes if multiple instances are installed; otherwise, remove the /etc/msgregistry.inf file on both nodes.

5. Run the following command:

   hareg -u ims50

   Note that you must perform Step a before performing this step.

6. Remove the following:

   /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

7. Remove the ims_ha.cnf file from your system disk mount point directory for the logical host (for example, /$LOGICAL_HOST).

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.

1. Become the root user.

   All of the following Sun Cluster commands require that you be running as user root.

2. Bring the resource group offline.

   To shut down all of the resources in the resource group, issue the command

   # scswitch -F -g IMS-RG

   This shuts down all resources within the resource group (for example, the Messaging Server, LDAP, and the HA logical host name.

3. Disable the individual resources.

   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

4. Remove the individual resources from the resource group.

   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

5. Remove the resource group.

   Once all the resources have been removed from the resource group, the resource group itself may be removed with the command:

   # scrgadm -r -g IMS-RG

6. Remove the resource types (optional).

   Should you need to remove the resource types from the cluster, issue the commands:

   # scrgadm -r -t SUNW.ims
   # scrgadm -r -t SUNW.nsldap
   # scrgadm -r -t SUNW.HAStorage

Step 1 of upgrade instructions should be clarified. (4556317)

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.

Messenger Express Customization Guide

This section describes any errors or changes to the iPlanet Messenger Express Customization Guide.

• Customizing users' default LDAP attributes. (4571687)

  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

• Code Example 3-12, Altering Address Window Text, does not work. (4538955)

  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.

Migration Guide

This section describes any errors or changes to the iPlanet Messaging Server Migration Guide.

• mgrpAllowedBroadcaster: Group value not working. (4572521)

  (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).

• Setting an Authorized Sender in a Mailing List. (4566646)

  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.

• Locating schema files and enabling Multi-schema Support on Sun Internet Mail Server. (4538155)

  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."

• Functionality is enabled during installation making documentation unnecessary. (no bugid)

  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.

Provisioning Guide

This section describes any errors or changes to the iPlanet Messaging Server Provisioning Guide.

• Using Nested Groups in Mailing List Restrictions. (4572521)

  (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:
  
  

  ---

  Note

  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).

  ---

  
  
  

• Feature not to be implemented until iPlanet Messaging Server 5.2. (no bugid)

  In Chapter 2, section titled Domain Tasks, the sub-section titled Setting a Welcome Message for a Domain is a description of a feature that is not available in iPlanet Messaging Server 5.1 patch 1; it will be available in 5.2.

Reference Manual

• Listed option is no longer valid. (4556601)

  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.

• Missing option in imadmin user purge command description. (4709493)

  In Chapter 3, the section describing the imadmin user purge command is missing the description for the -P option. The -P option is a preview only option. No purge is performed when this option is specified.

Schema Reference Manual

• Information on mailSMTPSubmitChannel is incomplete. (4537949)

  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.

  It should read as follows:

  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.

---

How to Report Problems

If you have problems with iPlanet Messaging Server, contact iPlanet customer support using one of the following mechanisms:

• iPlanet online support web site at http://www.iplanet.com/support/online/.

  From this location, the CaseTracker and CaseView tools are available for logging problems.

• The telephone dispatch number associated with your maintenance contract.

So that we can best assist you in resolving problems, please have the following information available when you contact support:

• Description of the problem, including the situation where the problem occurs and its impact on your operation.

• Machine type, operating system version, and product version, including any patches and other software that might be affecting the problem.

• Detailed steps on the methods you have used to reproduce the problem.

• Any error logs or core dumps.

• Output of the imsimta version command.

---

For More Information

Useful iPlanet information can be found at the following Internet locations:

• iPlanet release notes and other documentation — http://docs.iplanet.com/docs/manuals/

• iPlanet product status — http://www.iplanet.com/support/technical_resources/

• iPlanet Professional Services information — http://www.iplanet.com/services/professional_services_3_3.html

• iPlanet developer information — http://developer.iplanet.com/

• iPlanet learning solutions — http://www.iplanet.com/learning/index.html

• iPlanet product data sheets — http://www.iplanet.com/products/index.html

Last Updated November 19, 2002