Chapter 1   SIMS 4.0 and Netscape Messaging Server 4.x Changes, Regressions, and Transitions to the iPlanet Messaging Server


The iPlanet Messaging Server is a "best of breed" integration of the Netscape Messaging Server and Sun Internet Messaging Server (SIMS). The most robust and highest performing components of each product have been combined to produce the iPlanet Messaging Server. Because of its dual heritage, Netscape Messaging Server and SIMS customers may find that many processes and procedures are different in the iPlanet Messaging Server.

This chapter describes the major differences between the Netscape Messaging Server and SIMS systems and iPlanet Messaging Server, as well as other factors that affect migration to the iPlanet Messaging Server. This chapter contains the following sections:

• "Evolution of Messaging Components"

• "Changes in Directory Support"

• "SIMS 4.0 Regressions/Changes/Transitions"

• "Netscape Messaging Server 4.x Regressions/Changes/Transitions"

• "Migrating SIMS/Netscape Messaging Server on a High-Availability Cluster"

Evolution of Messaging Components

---

The iPlanet Messaging Server is an evolution of the Netscape Messaging Server and SIMS products. The following iPlanet Messaging Server components are based on components in Netscape Messaging Server 4.x, and thus use similar data formats and configuration information:

• Mail access (IMAP and POP) servers.

• Web browser mail access (Messenger Express)

• Directory service (Netscape Directory Server)

• GUI Administration through the Netscape Console

The following iPlanet Messaging Server components are based on the equivalent components in Sun Internet Mail Server 4.0:

• Mail transfer agent (MTA)

• Basic administrative methods for delegated administration of hosted domains (with additional architecture and implementation from iPlanet Delegated Administrator for Messaging)

• Directory Architecture for hosted domains.

Although iPlanet Messaging Server includes equivalent components to those of its predecessors, the administration procedures and data are not completely upwardly compatible. Table 1-1 itemizes some major differences between SIMS, Netscape Messaging Server and the iPlanet Messaging Server.

Table 1-1    Differences between SIMS 4.0/Netscape Messaging Server 4.x and the iPlanet Messaging Server 5.x

Messaging Component	5.x Changes from SIMS 4.0	5.x Changes from Netscape Messaging Server 4.x
MTA	Uses updated version of the SIMS MTA. Administration, configuration, and customization processes are almost identical. For new options see Administration Guide.	Netscape Messaging Server MTA replaced with a new MTA. Administration, configuration, and customization processes are different.
Message Store	Different message store. Some administration commands are retained.	Netscape Messaging Server message store as used. Additional utilities added.
Provisioning1	Uses SIMS provisioning CLI. New Delegated Administrator provides GUI provisioning. New Provisioning Guide.	New CLI provided. New Delegated Administrator provides GUI provisioning. New Provisioning Guide
System Admin CLI	Some similar commands, but most commands are different.	Some similar commands, but many different. configutil is still used.
System Admin GUI	Old GUI replaced with Netscape Admin Console	No Change. Uses Netscape Admin GUI
LDAP Directory	Sun Internet Directory Server replaced with Netscape Directory Server	No Change. Uses Netscape Directory
Schema	Different schema used, but supports old schema.	Different schema used, but supports old schema.

1 If you have custom provisioning tools for creating and modifying user and group directory entries based on data provided by account management systems, you must modify these tools before migrating entries to the new directory schema. See the iPlanet Messaging Server Provisioning Guide for details

Changes in Directory Support

---

This section discusses changes in directory support in iPlanet Messaging Server.

Directory Servers

Table 1-2 shows the directory servers supported by iPlanet Messaging Server and its predecessors. At a minimum, installations using Sun Directory Server or earlier versions of Netscape Directory Server should upgrade to Netscape Directory Server 4.12 before migrating to iPlanet Messaging Server.

Table 1-2    Directory Server Support

Messaging Server	Supports Sun Directory Server 3.1	Supports Netscape Directory Server 4.12
Netscape Messaging Server 4.x	No	Yes
Sun Internet Mail Server 4.0	Yes	Yes
iPlanet Messaging Server	No	Yes

Directory Information Trees

The iPlanet Messaging Server default DIT is different from the Netscape Messaging Server and SIMS directory DIT. The three DITs are shown below.

Figure 1-1    Example Directory Information Trees (DIT)

As installed, the iPlanet Messaging Server namespace consists of two directory trees, an Organization Tree and a domain component tree (DC Tree). Organization trees (additional Organization Trees can be added to support a system) contain the user and group entries. The DC Tree mirrors the local DNS structure, and is used by the system as an index to the data entries (see Figure 1-1). The DC Tree also specifies the various domain's operating parameters such as smart hosts, routing, hosts, domain disk quota, and so on.

The iPlanet Messaging Server fully supports the SIMS-style namespace, Netscape Messaging Server migration has some limitations at this time. These are described in the next section.

Netscape Messaging Server 4.x Directory Namespace Limitations

To use the Netscape Messaging Server directory namespace in the iPlanet Messaging Server the Netscape Messaging Server Directory Information Trees (DIT) must be mapped to the iPlanet Messaging Server DC Tree. The procedure for doing this will depend upon whether your current system supports virtual domains and how the UIDs are specified. UID specification can limit your ability to migrate to the iPlanet Messaging Server. UID specifications can be divided into roughly four categories:

• No virtual domains. UIDs of the form LocalPart (where there is only one domain). Examples:

  uid: wallyc
  uid: ofanning

• Contains virtual domains. UID separated by @. Fully qualified domain names (FQDN) to the right of @. UIDs are of the form LocalPart@FQDN. Examples:

  uid: wallyc@varrius.org
  uid: ofanning@siroe.com

• Contains virtual domains. Uses an @ separator. Part to the right of @ is not an FQDN. Examples:

  ofanning@siroe
  havlicek@sesta
  barkley@florizel

  Systems using this form of UID cannot be migrated at this time.

• Contains virtual domains with UIDs using something other than @ as the separator. Examples:

  ofanning#siroe
  eddie#sesta
  barkley#florizel.com

  imsdirmig, does not fully support this style of UID at this time. However, you have the option of using vanity domains to migrate this type of deployment to iPlanet Messaging Server with the restriction that domain-level administration is not supported (no Delegated Administrator).

  In order to support this style of UID do the following:

  • Include all users/groups in the default domain. This is done by setting the inetDomainBaseDN attribute of the default domain node in the DC Tree to the root suffix of the Organization Tree. For dc=siroe,dc=com, o=internet set inetDomainBaseDN to the root suffix o=siroe.com. This includes users/groups of all the virtual domains in the default domain.

  • Add the object class msgVanityDomainUser to all user entries and set the attribute msgVanityDomain to the fully qualified domain name of the user's virtual domain. The user's virtual domain is the domain part of the user's mail address. For example, the value of msgVanityDomain for the entry uid=eddie#sesta would be sesta.com since sesta.com is the domain part of the mail address eddie@sesta.com. (See Figure 1-2.)

  Refer to the iPlanet Messaging Server Provisioning Guide for information on setting the inetDomainBaseDN to the Root Suffix. For information on mapping Netscape Messaging Server namespaces to iPlanet Messaging Server namespaces refer to "Using Existing Directory Information Trees in the iPlanet Messaging Server".

Figure 1-2    Using Vanity Domains for Virtual Domain Support

iPlanet Messaging Server Schema

To support various features such as hosted domains and the iPlanet Delegated Administrator, the iPlanet Messaging Server has introduced a number of extensions and changes to the directory schema. These changes, however, are optional, and the iPlanet Messaging Server will support both the Netscape Messaging Server and SIMS schemas.

To take advantage of all new iPlanet Messaging Server features, however, you must upgrade directory objects to the new schema. We recommend that you upgrade the data entries to the iPlanet Messaging Server schema to take advantage of the new features. Features requiring the iPlanet Messaging Server schema are:

• The iPlanet Delegated Administrator for Messaging command line utilities

• iPlanet Delegated Administrator for Messaging GUI tool

• Server-side filtering rules

• Vacation attributes

• Support for hosted domains

Migration to the new schema can be done incrementally and without any service interruption. However, once this migration is done for a group or user it is difficult to move that group or user back to a host running the old messaging server. Migrate only when you're sure you won't want to return to the old servers. A complete description of the schema can be found in the iPlanet Messaging Server Schema Reference Manual.

Upgrading to the iPlanet Messaging Server schema is done with the imsdirmig utility, and is described in each of the migration scenarios. imsdirmig is available with the migration toolkit.

SIMS 4.0 Regressions/Changes/Transitions

---

SIMS 4.0 MTA Regressions and Changes

Although the iPlanet Messaging Server is using the same MTA as was used in SIMS, it is a more advanced version, and there are a few changes to be noted. These are described in this section.

Vacation Functions

The vacation attributes are different in the iPlanet Messaging Server. Unless you convert the user LDAP entries to iPlanet Messaging Server schema, the vacation function does not work.

imta startup

The imsimta startup and imsimta restart commands no longer automatically compile the configuration. The iPlanet Messaging Server can choose whether or not to use a compiled configuration. (Using a compiled configuration is recommended for performance and is required in order for dirsync operations to succeed. However, running without a compiled configuration may be temporarily useful, for example, on test systems.) If you wish to compile the configuration, you must issue an explicit imsimta cnbuild command or use the imsimta refresh command which is equivalent to doing imsimta cnbuild and imsimta restart.

Allowing or Blocking Access to a Mailing List

mgrpAllowedBroadcaster or mgrpDisallowedBroadcaster can be set to the address of a static group in the iPlanet Messaging Server, however, nested groups—groups within groups—are not supported. For specific posters, set mgrpAllowedBroadcaster and mgrpDisallowedBroadcaster to the address of a specific poster or specify as a dynamic group (LDAP search using URL criteria).

Adding SMTP Relaying

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. To add SMTP Relaying, refer tothe iPlanet Messaging Server Administrators Guide.

SIMS 4.0 Message Store Regressions/Changes

Existing SIMS 4.0 message stores are not compatible with the new iPlanet Messaging Server formats. You must convert the SIMS 4.0 message stores to the new message store format. This is described in the following chapter.

In SIMS, message store configuration and administration was done by modifying configuration files using the SIMS Admin Console or by running some command line utilities. The iPlanet Messaging Server does not use configuration files, but instead stores its configuration parameters in the directory. These parameters are modified using Administration Console and the configutil command. In addition, many of the message store command line utilities have been retained in the iPlanet Messaging Server. Below are a few of the changes encountered in migrating from SIMS. For more details refer to the iPlanet Messaging Server Administrators Guide and the iPlanet Messaging Server Reference Manual.

• The iPlanet Messaging Server has a message store daemon that automatically executes functions previously handled by imexpire and impurge. This daemon also automatically manages message store locks and transaction logs. This daemon must always be running.

• Backup and restore is similar to SIMS 4.0.

• No /var/mail message access.

• imsrestore does not have an interactive mode.

• imcheck is replaced by reconstruct.

• No IMAP IDLE command.

• imdeluser is replaced by mboxutil -d.

• imexpire, iminitquota, and impurge are no longer need or supported.

• imquotacheck is now quotacheck.

• No POP before SMTP. (This functionality is available using the directory to control aspects of how UIDs are interpreted.)

• No AUTH API.

Netscape Messaging Server 4.x Regressions/Changes/Transitions

---

Netscape Messaging Server 4.x MTA Regressions/Changes

The iPlanet Messaging Server uses a completely different MTA than Netscape Messaging Server and therefore there are many changes. Below are a few of the changes encountered. For more details refer to the iPlanet Messaging Server Administrators Guide and the iPlanet Messaging Server Reference Manual.

Plug-ins

iPlanet Messaging Server does not support messaging plug-ins, although many of the most common plug-in functions have equivalents in the iPlanet Messaging Server MTA. Some Netscape Messaging Server options and customizations, however, may have no direct replacement in the iPlanet Messaging Server, especially undocumented features and custom plug-ins. Since iPlanet Messaging Server channel programs are not compatible with the Netscape Messaging Server plug-in APIs, this requires re-coding Netscape Messaging Server plug-ins as a custom channel program for the iPlanet Messaging Server. Any such new programs should be developed and tested before migration begins.

Sending Notifications Regarding Bad Mailing List ErrorsTo Addresses to the Postmaster

In Netscape Messaging Server, if a mail list has an invalid member and invalid ErrorsTo address, then a message sent to the group resulted in two error messages sent to the postmaster: one error message about the invalid group member, and another message about the invalid ErrorsTo address. In the iPlanet Messaging Server, by default, the postmaster only receives one message about the invalid group member. By default, the postmaster does not receive notice about any bounces of attempted notification messages, such as for instance notification of an invalid ErrorsTo address.

The sendpost keyword can instead be used by those sites that want the postmaster to get copied even on bounces of notification messages (for example, bounces of bounces, such as the bounce of the attempted notification to the ErrorsTo address.)

Group Attribute Migration Issues

The following group attributes/values are not supported

Group Attribute mgrpMsgRejectAction Not Supported
Group attributes mgrpMsgRejectAction and mgrpMsgRejectText are not supported at this time. These attributes allowed you to specify an action to be taken if a message to the group is rejected. These attributes are allowed, but will not be supported until a future version.

Group Attribute Value `mgrpBroadcasterPolicy=PASSWD_REQUIRED' Not Supported
Group attribute mgrpBroadcasterPolicy will not act on a value of PASSWD_REQUIRED. It will be implemented in a later release.

Group Attribute mgrpErrorsTo Does Not Work If a Group is Specified as a LDAP Value
You can specify the value as a mailto address. Example:

mgrpErrorsTo: mailto: baseball@siroe.com

You cannot specify an LDAP value. Example:

mgrpErrorsTo: ldap:///cn=baseball,ou=Groups,o=siroe.com,o=siroe.com

This will not be fixed.

Setting Authorized Senders

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. See the iPlanet Messaging Server Schema Reference Manual for the syntax for using mgrpAllowedBroadcaster.

SMTP Relay Function

In Netscape Messaging Server, the "anti-relay" function (where mail sent from an external domain will not be relayed to another external domain) was provided by a plug-in. In iPlanet Messaging Server this function is provided by the MTA. The initial default configuration of the iPlanet Messaging Server is 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. To add SMTP Relaying, refer to the iPlanet Messaging Server Administrators Guide.

Allowing SMTP Relaying for External Sites
All internal IP addresses should be added to the INTERNAL_IP mapping table. If you have friendly or companion systems/sites from which you wish to allow SMTP relaying, the simplest approach is to include them along with your true internal IP addresses in your INTERNAL_IP mapping table. This is described in the iPlanet Messaging Server Administrators Guide.

DNS Lookups Including RBL Checking

In the Netscape Messaging Server, to ensure that all mail accepted for delivery or forwarding comes from an address with a valid DNS name, administrators used the MTA configuration parameter service.smtp.domainnotallowed with the filter ALL: UNKNOWN.

In the iPlanet Messaging Server, this functionality can be achieved in different ways. The simplest way is to put the mailfromdnsverify channel keyword on the tcp_local channel.

The iPlanet Messaging Server also provides the dns_verify program which allows you perform the same functionality with the following rule in ORIG_MAIL_ACCESS:

ORIG_MAIL_ACCESS   TCP|*|*|*|*|SMTP|MAIL|*|*@*|*|*    \      $[server_root/bin/msg/imta/lib/dns_verify,     \ dns_verify,$6|$$y|$$NInvalid$ host:$ $$6$ -$ %e]

DNS Lookups are described in the iPlanet Messaging Server Administrators Guide.

Unauthorized Bulk Email (UBE) Filtering

Refer to the previous section for anti-relay information. Refer to the iPlanet Messaging Server Administrators Guide System Administration Guide for instructions on server-side mailbox filter. Filtering incoming messages based on message headers can be done using the iPlanet Delegated Administrator for Messaging.

Netscape Messaging Server 4.x Message Store Regressions/Changes

The message store data format used by iPlanet Messaging Server is based on that of Netscape Messaging Server 4.x. Existing Netscape Messaging Server message stores are automatically converted to the new iPlanet Messaging Server format, though a simple conversion step is required. This is described in the next chapter.

Migrating SIMS/Netscape Messaging Server on a High-Availability Cluster

---

The scenarios described in this book can be used to upgrade email systems on High-Availability Clusters. Details such as upgrading the cluster software itself and the specifics of how to split a clustered node, are beyond the scope of this book. Refer to the documentation provided by the cluster vendor.