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 5.0/Netscape Messaging Server 4.x and the iPlanet Messaging Server 5.0

Messaging Component	5.0 Changes from SIMS 4.0	5.0 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

You cannot set mgrpAllowedBroadcaster or mgrpDisallowedBroadcaster to the address of a static group in the iPlanet Messaging Server. mgrpAllowedBroadcaster and mgrpDisallowedBroadcaster attributes should be set instead either to the address of a specific allowed poster, or specified 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.

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 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 <InstanceRoot>/imta/config/mappings file.

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    $(123.45.67.89/32)   $Y    127.0.0.1   $Y    *   $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. Note that all entries must be preceded by at least one space.

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 by changing the number of bits used in matching the address. In the mapping table below, we change from 32 bits to 24 bits. This allows all clients on the class-C network to relay mail through this SMTP relay server.

INTERNAL_IP    $(123.45.67.89/24)   $Y    127.0.0.1   $Y    *   $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:

INTERNAL_IP ! Match IP addresses in the range 123.45.67.80-123.45.67.95    $(123.45.67.80/28)   $Y ! Match IP addresses in the range 123.45.67.96-123.45.67.99    $(123.45.67.96/30)   $Y    127.0.0.1   $Y    *   $N

Note that the <InstanceRoot>/imsimta test -match utility can be useful for checking whether an IP address matches a particular $(.../...) test condition. The <InstanceRoot>/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 <InstanceRoot>/imsimta restart command (if you are not running with a compiled configuration) or the <InstanceRoot>/imsimta refresh command (if you are running with a compiled configuration) 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.

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 mgrpAllowedBroadcaster Does Not Take a Group as a Valid Value
You cannot use a group name as a value for mgrpAllowedBroadcaster. The workaround is to add each group member's email. This is expected to be fixed in the next release (5.1).

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.

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.

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 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 <server-instance>/imta/config/mappings file.

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    $(123.45.67.89/32)   $Y    127.0.0.1   $Y    *   $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. Note that all entries must be preceded by at least one space.

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 by changing the number of bits used in matching the address. In the mapping table below, we change from 32 bits to 24 bits. This allows all clients on the class-C network to relay mail through this SMTP relay server.

INTERNAL_IP    $(123.45.67.89/24)   $Y    127.0.0.1   $Y    *   $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:

INTERNAL_IP ! Match IP addresses in the range 123.45.67.80-123.45.67.95    $(123.45.67.80/28)   $Y ! Match IP addresses in the range 123.45.67.96-123.45.67.99    $(123.45.67.96/30)   $Y    127.0.0.1   $Y    *   $N

Note that the <InstanceRoot>/imsimta test -match utility can be useful for checking whether an IP address matches a particular $(.../...) test condition. The <InstanceRoot>/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 <InstanceRoot>/imsimta restart command (if you are not running with a compiled configuration) or the <InstanceRoot>/imsimta refresh command (if you are running with a compiled configuration) 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.

Allowing SMTP Relaying for External Sites
All internal IP addresses should be added to the INTERNAL_IP mapping table as discussed above. 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.

If you don't quite wish to consider these as true internal systems/sites, (for instance, if for logging or other control purposes you wish to distinguish between true internal systems versus the friendly non-internal systems with relay privileges), there are other ways to configure the system.

One approach is to set up a special channel for receiving messages from such friendly systems. Do this by creating a tcp_friendly channel akin to your existing tcp_internal channel with official host name tcp_friendly-daemon, and a FRIENDLY_IP mapping table akin to your INTERNAL_IP mapping table that lists the friendly system IP addresses. Then right after the current rewrite rule:

! Do mapping lookup for internal IP addresses []
$E$R${INTERNAL_IP,$L}$U%[$L]@tcp_intranet-daemon

add a new rewrite rule:

! Do mapping lookup for "friendly", non-internal IP addresses []
$E$R${FRIENDLY_IP,$L}$U%[$L]@tcp_friendly-daemon

An alternate approach is to add to your ORIG_SEND_ACCESS mapping table above the final $N entry, new entries of the form

  tcp_local|*@siroe.com|tcp_local|*    $Y

where siroe.com is the name of a friendly domain, and to add an ORIG_MAIL_ACCESS mapping table of the form:

ORIG_MAIL_ACCESS

   TCP|*|25|$(match-siroe.com-IP-addresses)|*|SMTP|MAIL|    \
tcp_local|*@siroe.com|tcp_local|*     $Y
   TCP|*|*|*|*|SMTP|MAIL|tcp_local|*|tcp_local|*    $N

table, where the $(...) IP address syntax is the same syntax described in the previous section. The ORIG_SEND_ACCESS check will succeed as long as the address is ok, so we can go ahead and also do the ORIG_MAIL_ACCESS check which is more stringent and will only succeed if the IP address also corresponds to an siroe.com IP address.

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]

The line breaks in the above example are syntactically significant in such mapping entries. The backslash character is a way of legally continuing on to the next line.

The dns_verify image can also be used to check incoming connections against things like the RBL, MAPS, DUL, or ORBS lists as another attempt to protect against UBE. As with the new mailfromdnsverify keyword, there's also a separate "simpler to configure" approach one can use for such checks rather than doing the dns_verify callout. The simpler approach is to use the DNS_VERIFY_DOMAIN option in the dispatcher.cnf file. For example, in the [SERVICE=SMTP] section, set instances of the option to the various lists you want to check against:

[SERVICE=SMTP]
PORT=25
! ...rest of normal options...
DNS_VERIFY_DOMAIN=rbl.maps.vix.com
DNS_VERIFY_DOMAIN=dul.maps.vix.com
!...etc...

The disadvantage of this simpler approach is that it does the checks for all normal incoming SMTP messages including those from internal users. This is less efficient and potentially problematic if your Internet connectivity goes down. An alternative is to call out to dns_verify from a PORT_ACCESS mapping table or ORIG_MAIL_ACCESS mapping table. In the PORT_ACCESS mapping table, you can have an initial entry or entries that don't check for local internal IP addresses or message submitters and a later entry that does the desired check for everyone else. Or, in an ORIG_MAIL_ACCESS mapping table, if you only apply the check on messages coming in the tcp_local channel then you're skipping it for messages coming from your internal systems/clients. Examples using the entry points to dns_verify are shown below.

PORT_ACCESS

! Allow internal connections in unconditionally
  *|*|*|*|* $C$|INTERNAL_IP;$3|$Y$E
! Check other connections against RBL list
  TCP|*|25|*|*    \
      $C$[<server-root>/bin/msg/imta/lib/dns_verify,  \
dns_verify_domain_port,$1,rbl.maps.vix.com]EXTERNAL$E

ORIG_MAIL_ACCESS

  TCP|*|25|*|*|SMTP|*|tcp_local|*@*|*|*    \
      $C$[<server-root>/bin/msg/imta/lib/dns_verif,    \
      dns_verify_domain,$1,rbl.maps.vix.com]$E

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.