Netscape Messaging Server 3.5 Release Notes
Netscape Messaging Server 3.5
This file was last updated on December 20, 1999.
Important Product Alert: Root Certificate Expiration
If you are are using SSL with Netscape Messaging server, you need to
be aware of important information related to root certificate expiration
by the end of 1999. At a minimum, you may need to ask your users to
upgrade their browsers to Communicator 4.7. Depending on how you are
using SSL, you may also need to update the root certificate in your server.
For important and urgent information on root certificate expiration, see
Digital Certificate Security Alert.
Thank you for choosing Netscape Messaging Server 3.5. These release
notes contain caveats, known problems, and other important information
about the product. Please read these notes before using the product. For
installation instructions, see the README
file.
NOTE: If you are installing Netscape Messaging Server 3.5, you should
also install the 3.52 patch. For more information on how to download and
install the 3.52 patch, see the patch
release notes.
Contents
What's new in Messaging
Server 3.5
Netscape Messaging Server 3.5 offers a variety of new
features and enhancements for your electronic mail (email) system:
Support for Fortezza hardware-based
encryption (Fortezza only)
The Fortezza version of Messaging Server 3.5 supports the use of Fortezza
PCMCIA card-based encryption for IMAP4 sessions. New administration forms
under the Encryption tab allow you to enable and disable Fortezza ciphers,
and set up the Messaging Server to use Fortezza.
Additional LDAP Routing configuration options
A new LDAP Routing Configuration form allows you to specify:
-
Alternate search methods
-
Envelope rewrite methods
Enhanced support for plug-in configuration
Messaging Server 3.5 provides new administration forms for managing server
plug-ins, allowing you to turn plug-ins on and off, and configure available
plug-ins.
Unsolicited Bulk Email (UBE) filters
Messaging Server 3.5 provides a means of controlling unsolicited bulk email
(UBE). By using the UBE Filters form, you can create filters that
prevent the Messaging Server from delivering UBE's.
Full support for LDAP version
3
Messaging Server 3.5 provides full support for Lightweight Directory Access
Protocol (LDAP) version 3, which allows you to enter attributes in multiple
languages.
Flexible postmaster address assignment
Messaging Server 3.0 required that one mail group handle mail addressed
to "Postmaster" for all installed Messaging Servers. With Messaging
Server 3.5, this is no longer the case. It is no longer required
that you have one mail group handling Postmaster email for all Messaging
Servers (although this continues to be the default setup). Messaging
3.5 now allows different mail user accounts and/or a mail group to handle
the Postmaster mail on behalf of the respective installed Messaging Servers.
It is even possible to delete the Postmaster group entirely, if desired,
as long as there is some mail user account or mail group designated for
each Messaging Server to receive mail addressed to "Postmaster."
Support for multiple mail hosts
In Messaging Server 3.0, you can associate a server with only one host
name. Consequently, all mail accounts on a given server must have the same
mailHost value in the LDAP directory. However, with Messaging Server 3.5
you can associate a single server with multiple host names by editing the
MessageHostName parameter in the netscape.mail.conf file. (On
Unix, the path to this file is /etc/netscape.mail.conf. Windows
NT users must use Notepad to create this file in server-root\bin\mail\Server\etc,
where server-root is the base directory where your SuiteSpot
servers are installed.) Consequently, the mailHost value for a given user's
LDAP entry can be set to any of the values specified in the MessageHostName
parameter.
Selective email address lookups
When the Messaging Server searches the directory for a given email address
to see which LDAP entry it belongs to (that is, to find out which LDAP
person or group a given message is being sent to), we now consider only
those LDAP entries that are of object class 'mailRecipient' (a mail user
account) or 'mailGroup' (a mail group). This allows administrators
to have other LDAP entries with a "mail" attribute set for the purpose
of providing contact information only, without creating confusion as to
whether such LDAP entries represent mail user accounts or mail groups.
Support for multiple post
offices (Unix only)
On Unix platforms, Messaging Server 3.5 supports the use of multiple post
offices. For information about this feature, see Netscape
Messaging Server 3.5 Performance Tips.
What's new in Messaging Server
3.0x
Simplified account administration
Netscape Messaging Server 3.0 supports the Lightweight Directory Access
Protocol (LDAP) standard, allowing the messaging server to integrate
with local or centralized directory services flexibly. A centralized directory
service gives server administrators a single point where they can add,
change, and delete users. That user information can be shared across all
Netscape SuiteSpot Servers, including Netscape Messaging Server.
Authenticated SMTP
Netscape Messaging Server 3.0 supports authenticated Simple Mail Transfer
Protocol (SMTP) for greater security in sending messages over the SMTP
channel. When enabled in the user's mail client, authenticated SMTP requires
users to enter their password before being allowed to send messages. Recipients
can determine whether a message has been sent by an authenticated sender:
the sender's name is followed by an indication that the message is internal.
IMAP encryption and authentication (Unix
only)
Netscape Messaging Server 3.0 lets you specify the level of encryption
and authentication for receiving messages with Internet Message Access
Protocol (IMAP) clients. It provides a variety of options for encryption
using Secure Sockets Layer (SSL) and authentication with passwords
and client certificates.
Remote network management
Messaging Server also includes Simple Network Management Protocol (SNMP)
support for unified network management with any SNMP-compatible network
management tool.
Message quotas
Netscape Messaging Server 3.0 supports message quotas. With the quota system
enabled, server administrators can limit users to a maximum mailbox size
by setting disk size. In this way, administrators have a manageable mechanism
with which to control their potentially explosive messaging growth.
Delivery status notification
Netscape Messaging Server 3.0 can confirm message delivery, whether messages
are sent within the enterprise or across the Internet. The messaging server's
delivery-status notification feature is based on the prevailing Internet
standards (RFCs 1891 through 1894). Consequently, email users are apprised
of message delivery not only by Netscape Messaging Server but by other
internal or Internet messaging systems that also support these standards.
Single copy message store
Netscape Messaging Server 3.0 provides a single copy message store option
in which the messaging server stores a single copy of any message sent
to multiple recipients, rather than one copy per recipient. The advantage
of turning on single-copy message store is that it conserves disk space.
If the single-copy message store option is turned off, messages are delivered
normally, with a copy stored in each recipients' mailbox; the advantage
in this case is better performance.
Messaging Server plug-in API
Netscape Messaging Server 3.0 provides an application program interface
(API) that allows third parties to "plug in" site-specific functionality
in the Messaging Server. It is intended for developers who wish to extend
the functionality of Messaging Server 3.0 for site-specific reasons.
How to get more information
An online version of the Messaging Server 3.0 Administrator's Guide,
updated for Messaging Server 3.5, is provided with Messaging Server 3.5
software. Click the Help button on any Messaging Server or Administration
Server form to access the online Help. (The online version of the Administrator's
Guide is also provided in the online
database for Messaging Server 3.5.)
Some additional documents relating to Messaging Server 3.5:
-
Click here
for information on migrating from sendmail to Messaging Server 3.5.
-
Click here
for information on improving Messaging Server performance.
You can also search our online
database for more fact-filled documents relating to Messaging Server
3.5.
How to report problems
If you are a test-drive customer and are having problems with Messaging
Server 3.5, click here
to send an email to our technical support staff. If you are affiliated
with an educational institution and you are using the product for free,
click here. You can also
search our online
database for answers to your questions.
If you have purchased Messaging Server 3.5, you can either search our
online
database for answers to your questions or use the up-to-date contact
information and support phone numbers provided there to contact our technical
support staff.
Limitations,
caveats, and known problems with this release
This section describes the limitations, caveats, and know problems with
this release:
Restarting the Messaging
Server after configuration changes
After making any configuration changes for the Messaging Server, to ensure
that the changes have taken effect, Netscape recommends that you shut down
the server, wait at least one minute, and then restart the server.
Note: The first time you stop and restart the Messaging
Server after enabling IMAP4 encryption using the Encryption|IMAP Encryption
form, you see a dialog box containing the message: "Warning: Can not determine
secure IMAP pid." You can ignore this message; it does not indicate a problem.
Running the Administration
Server as root
It is strongly recommended that you run the Administration Server as root.
Problems converting 2.x certificate database
(Unix only)
This is a problem with the version of the Administration Server bundled
with Messaging Server 3.5. When you use the Keys and Certificates|Convert
2.0 Certdb form of this Administration Server to convert 2.x certificate
and key-pair databases, the resulting certificate and key-pair database
files have incorrect ownership and permissions.
To work around this problem, after running the conversion from the form,
perform the following steps:
-
Log into your server machine as root
-
cd server-root/alias
where server-root is the base directory where
your SuiteSpot servers are installed.
-
chown server-user alias-cert.db alias-key.db
where server-user is the user identity used
by the SuiteSpot server that will use the certificate and key-pair databases
(for Messaging Server 3.5 with Fortezza, this should be the Messaging Server
user specified during installation) and alias is
the alias name you specified on the conversion form.
-
chgrp suitespot-group alias-cert.db alias-key.db
where suitespot-group is the SuiteSpot group
identified in server-root/install/ssusers.conf.
-
chmod 640 alias-cert.db alias-key.db
Some effects
of upgrading from Mail Server 2.x
Here's what you might expect users to experience after an upgrade from
Mail Server 2.X to Messaging Server 3.5, and why:
-
For users retrieving their mail with POP, and who regularly leave their
messages on the server, be aware that all messages will be downloaded again
after the server has been upgraded to Messaging Server 3.5. This may cause
messages to be duplicated in the user's client mailbox, or messages which
the user has deleted on the client will reappear. Netscape strongly recommends
that such users switch to IMAP, preferably before the upgrade, and deal
with all of the old messages on the server (either by deleting them if
they are no longer needed or by setting the POP preference "leave messages
on server" to OFF and then downloading messages from the server). If it
is not possible or practical for a user to switch to IMAP, the user will
have to clean up his or her client mailbox manually.
-
Users might notice a delay when opening a folder for the first time after
the Messaging Server has been upgraded. The reason is that message formats
are being upgraded to a more efficient format. (The delay is especially
long for folders with many messages--for instance, for POP users who have
left a lot of mail on the server.) This delay is greatly reduced the next
time you open the folder.
-
Because there are a lot of people logging in for the first time, the Messaging
Server is very busy converting folders and may therefore be a bit sluggish
for everybody. You can expect this to improve in the first few days after
the upgrade, after everyone has logged in and has had their folders converted.
-
IMAP users will probably see all of the message headers emptied out, then
getting redrawn the first time they open the upgraded mailbox. Internally,
the server reassigns unique message identifiers (UIDs) under certain circumstances.
This is especially likely for users who have used IMAP on multiple machines.
Some
settings are lost when upgrading from Messaging Server 3.0x
When you upgrade to Messaging Server 3.5 from Messaging Server 3.0x, some
configuration settings are lost. You can find the previous settings, however,
in the time-stamped backup file /etc/netscape.mail.conf.bak.timestamp
Settings that are lost during the upgrade include:
-
MessageHostName
-
security related variables (IMAP/SSL)
-
proxyauthuser
-
LDAP user
-
forkfunctions
-
AccountURL
POP3 connections over slow
dialup lines
Some slow connections can cause the POP3 server to report a failure to
the client. If you are using a slow connection (28.8 baud or lower),
Netscape recommends that you disable buffered transmissions from the POP3
server.
To disable buffered transmissions:
-
Open the NT registry using regedit.exe.
-
Navigate to HKEY_LOCAL_MACHINE\Software\Netscape\Messaging Server\3.0\POP3-Server\Config.
-
Double-click the UseBufferedTransmit entry in the right-hand pane.
-
Change the yes on the right-hand side to no.
-
Exit regedit.
-
Restart the Messaging Server for the change to take affect.
About the default
location for postmaster account
The Messaging Server 3.5 installation program creates two entities in the
Directory Server: the postmaster account and the SIE (server instance entry).
The default locations/distinguished names for these entities are based
on the Directory Server information you supplied during the installation
process. To make changes to these locations/distinguished names, you must
use LDAP-modify. See the Messaging
Server FAQ for more information.
Choosing a post office directory
(Unix only)
On Unix platforms, using the top-level directory of a file system as your
post office directory can prevent the server from starting because of the
permissions on the lost+found subdirectory. If you want to use
an entire file system for your post office directory, create a subdirectory
of the top-level directory. For example, if your file system were mounted
on /disk2, you could create /disk2/po and use it as your
post office directory.
SNMP
statistics are invalid when using multiple post offices
When running Messaging Server 3.5 with multiple post offices, SNMP statistics
are invalid; these statistics reflect only the main post office.
Some notes on SMTP channel aliases
SMTP channel aliases are supported in Messaging Server 3.5. However, Netscape
strongly encourages the use of LDAP functionality over SMTP channel aliases
in routing messages between messaging servers. Netscape strongly recommends
that you not attempt to import more than 200 channel aliases at at a time.
Note: If you experience any problems using channel aliases, please
check the syntax of your entries and resubmit.
Important: Importing SMTP channel aliases may take some time.
(For example, 1,000 channel aliases may take hours.) During that process,
be sure to keep your browser window open, and wait for confirmation that
the SMTP channel aliases have been successfully imported.
When creating user and group mail accounts, the Administration Server
verifies that the addresses entered into user and group directory entries
have not been used by other accounts; however, the Administration Server
does not check to see whether SMTP channel aliases use these addresses.
In other words, the Administration Server will accept an address as unique
when that address may in fact be used in an SMTP channel alias.
To avoid this situation, follow Netscape's general recommendation of
using LDAP functionality over SMTP channel aliases for routing messages
between messaging servers. You might also want to maintain a list of SMTP
channel aliases as a separate file for quick reference.
IMAP Encryption
form doesn't indicate the active alias
The IMAP Encryption form allows you to select an IMAP alias. However, the
form does not indicate the active alias after you choose one from the list
of available aliases. Regardless of the lack of feedback, the alias you
choose is active. (To verify your choice, you can look in netscape.mail.conf
(On Unix, /etc/netscape.mail.conf; On Windows NT, server-root\bin\mail\Server\etc\netscape.mail.conf)
Some notes on secure IMAP (SIMAP)
(Unix only)
When you shut down the Messaging Server, SIMAP processes are not stopped
automatically. Make sure you stop all SIMAP processes manually. You will
need to restart the SIMAP process manually; see "Starting a secure IMAP4
server" in the online help.
The Administrator's Guide states that the default port for SIMAP
is port 220. Changes in the product were made subsequent to producing these
pieces of documentation; the default port is now port 993. This
is correctly stated in the online help.
Client certificate
authentication is not working correctly
In order for client certificate authentication to work correctly, you need
to manually edit the certmap.conf file. Information about the
certmap.conf file is available in Managing Netscape Servers.
Mailbox
paths must exist prior to specifying them as message stores
When specifying message stores, be sure the location of the mailboxes that
you input already exist. Mailbox paths must exist prior to specifying
them as message stores, and must be owned by the Unix username for the
Messaging Server.
Message store path must
be absolute path
When performing an ldif import, make sure the message store path is an
absolute path, and not a relative path.
Using vacation mode
To ensure correct operation of vacation mode, use a Netscape Directory
Server with "Track Modifies" enabled. When this option is disabled, a vacationing
user's notification will be sent to his or her correspondents once only,
and not for subsequent vacations (unless the user changes the vacation
text for each vacation).
Extending
LDAP schema extensions in Directory Server 3.0b2
Messaging Server 3.5 provides the means of controlling mail routing
on a per-user basis. However, before using this feature, you will need
to extend the LDAP schema extensions in Directory Server 3.0b2.
Mail Routing in Messaging Server 3.5 can be influenced by a mail attribute
in a user or group directory entry called mailRoutingAddress. To
extend the schema extensions in Directory Server 3.0b2, you must edit the
schema.config file by adding the mailRoutingAddress to the mailRecipient
and mailGroup lists of allowed attributes.
Only the first eight characters
are significant in CRYPT-encoded user passwords
If you are using CRYPT encoding for user passwords, only the first eight
characters of a password is significant. A user can therefore log into
the POP3 or IMAP4 server supplying a password with extraneous characters
at the end; so long as the first eight characters of the supplied password
are correct, authentication succeeds.
Plugins are not available
on AIX
Messaging Server 3.5 does not support plugins on the AIX platform. UBE
filters, therefore, are also not available on this platform.
Send
Error To field does not allow multiple addresses
On the Mail Group Information form, the Send Error To field does not allow
multiple email addresses. Currently, however, the form silently fails without
generating an error message if you enter more than one email address in
this field.
Moving user
accounts from Unix to Windows NT
When using the MoveUser utility to move user accounts from a Unix system
to a Windows NT system, you must use Unix-style slashes ('/')
in pathnames given on the command line.
Excessive resource
consumption can occur after quick server stop and restart
If you stop and quickly restart Messaging Server, the server sometimes
begins consuming a high percentage of system resources. To prevent this,
wait at least one minute between stopping the server and restarting it;
this assures that all server components are completely stopped before they
are restarted.
Online
documentation on the processq command is incomplete
The section "Delivering mail in the queue" in Appendix D, "Command-line
operations and utilities" in the online documentation omits information
about the processq command. This section provides the missing
information.
If you want to process only the mail queued for a particular domain,
use the -R option to processq:
processq -Rdomain
where domain is the name of the domain
for which you want to process queued mail. This command leaves the rest
of the mail queue unaffected.
When
using MoveUser utility, the IMAP4 server can crash (Unix only)
On Unix systems, if you run the MoveUser utility while the IMAP4
server is running, the IMAP4 server sometimes crashes, generating a core
file. The work-around is to set your Directory Server time-out to at least
8 hours before running MoveUser.
Mail sent to the server
can bounce if you use a non-default domain (Unix only)
When the Messaging Server is installed, the installer infers the fully
qualified host name of the server machine using the server's primary DNS
domain. On some system configurations, this does not reflect the domain
for which the server is to process mail; this prevents the server from
delivering and relaying mail correctly. The workaround is to set the parameter
MessageHostName in the file /etc/netscape.mail.conf to
the correct value.
For example, for a server named mail that is supposed
to handle mail for onething.com, but has a primary DNS domain
of another.com, you must explicitly set the value of MessageHostName
to mail.onething.com.
sendmail emulator not working
on HP-UX
The sendmail emulator provided in this release of Messaging Server 3.5
does not work HP-UX.
Disk-space requirements
on HP-UX
Before installing Messaging Server on HP-UX, you must make sure you have
at least 15 kilobytes free space in your / and /usr partitions
for storing temporary files. If you don't do this, the Messaging Server
3.5 installation will fail without displaying any error or warning messages.
Misleading message
displayed when installing on AIX
When performing a "clean" installation of Messaging Server 3.5 on AIX (installing
on a machine where no version of the Messaging Server is currently installed),
the following misleading message is displayed:
Restoring previous LocalMailDomain configuration...
This message is spurious; you can ignore it.
Disabling the POP3 server
If you want to disable client logins using the POP3 protocol, you can do
the following:
-
Stop the Messaging Server
-
In the directory suitespot_dir\bin\mail\server\network,
where suitespot_dir is the base directory where your SuiteSpot
servers are installed, rename the file POP3-Server to POP3-Server.disabled.
-
Restart the Messaging Server
Command line utilities
Messaging Server 3.5 provides the following command line utilities:
Important: (Windows NT only) To operate on the message store,
these utilities need to impersonate the Windows NT account you chose to
run the service as. This ability to impersonate is off by default
in Windows NT. If you receive an error message that the system is
unable to grant privileges, you do not have this option set. This
option must be on for any user who wishes to run the utilities. To
set the neccessary privileges:
-
Open the User Manager application (under Administrative Tools).
-
Choose Policies|User Rights.
-
Enable the Show Advanced User Rights checkbox.
-
Choose Act as part of the operating system.
-
Select the user or users to whom you want to grant the right and click
Add.
-
Click OK.
You will have to log off and back on for the rights to take effect.
CheckPO
The CheckPO command line utility checks the messaging server post office
for message inconsistencies, searches for "orphaned" mailboxes, and fixes
message corruptions if needed.
Synopsis:
CheckPO [-h] [-u userid | -p maildrop] [-f] [-d filename
| -m filename] [-l filename] object
Description:
The CheckPO utility will detect inconsistencies in the Netscape Messaging
Server 3.5 post office. Message inconsistency could be caused by restoring
files from backup, or program bugs, or file corruptions, or by accidently
removing a mailbox without using a proper tool.
Also, because of LDAP, users' mail attributes can be changed independently
from the Messaging Server's operations. Consequently, a physical mailbox
can become "orphaned" (that is, mail is no longer delivered/retrieved to/from
the mailbox) when the owner's mailhost or maildrop path is changed via
LDAP.
Note: The user who runs this utility must have system administrator's
privileges.
Important: The Messaging Server must be stopped before CheckPO
can be run.
The utility expects one parameter specifying the post office's object
that the tool will check for inconsistency. The following are valid values
for the object parameter:
This parameter is not case-sensitive; that is, the value can be in mixed
cases. When "mailbox" is specified, the utility will check for orphaned
mailboxes. When "message" is specified, the utility will check for inconsistencies
in all messages. When "all" is specified, the utility will check for both
orphaned mailboxes and inconsistencies in all messages.
There are several options that can be specified with the CheckPO utility:
-h
When this option is specified, a detailed description of the utility will
be displayed.
-u userid
When this option is specified, the utility will perform its tasks for the
user specified by the userid. The userid is the id that a user uses to
logon to the post office. This value is used to map to a physical mailbox
in this post office.
If either "mailbox" or "all" is specified, the utility will search for
any mailbox in the current mailhost that matches the userid. When found,
the utility will check if the mailbox is orphaned or not. That is, the
utility will check if the owner of the mailbox exists in the directory,
still has the same mailhost, and if the user's messaging store path is
the same as the mailbox's current path. If this option and the -p option
are not specified, the default behaviour is to check all mailboxes in the
post office.
If either "message" or "all" is specified, the utility will scan all
messages in the mailbox that matches the userid and check for inconsistencies
such as:
-
A reference message points to a single copy message that does not exist.
-
A zero size message ( could be a reference message or the single copy message,
or a non-single-copy message).
-
Missing back link file.
-
A reference message file name does not exist in the back link file.
-
Mismatched reference count of a single copy message.
-
A message that does not have a message header.
If this option and the -p option are not specified, the default behaviour
is to scan all messages in all mailboxes in the post office.
Note: This option cannot be used in conjunction with the -p option.
-p maildrop
When this option is specified, the utility will perform its tasks within
the specified maildrop path. A maildrop is the physical path on the system
where a group of mailboxes are located. There is always a default maildrop
which is specified during installation. The administrator also has the
option of specifying a different message store path for each user via the
admin interface.
If either "mailbox" or "all" is specified, for each mailbox that is
in the specified maildrop path, the utility will check if its owner exists
in the directory, still has the same mailhost, and if the messaging store
path attribute is the same as the mailbox's current path. If this option
and the -u option are not specified, the default behaviour is to check
all mailboxes in all of the post office's maildrop paths.
If either "message" or "all" is specified, the utility will scan all
messages in all mailboxes within the specified maildrop path and check
for inconsistencies such as:
-
A reference message points to a single copy message that does not exist.
-
A zero size message ( could be a reference message or the single copy message,
or a non-single-copy message).
-
Missing back link file.
-
A reference message file name does not exist in the back link file.
-
Mismatched reference count of a single copy message.
-
A message that does not have a message header.
If this option and the -u option are not specified, the default behaviour
is to scan all messages in all mailboxes in the post office.
Note: This option cannot be used in conjunction with the -u option.
-f
When this option is specified with either "message" or "all", the utility
will attempt to fix any message inconsistency it finds by deleting corrupted
files, adjusting reference count, and so on. If this option is not specified,
the utility will only generate a report of the inconsistencies.
The utility will never attempt to fix orphaned mailbox problems. Hence,
this option will be ignored if the object is "mailbox".
-d filename
When this option is specified, the utility will output a DelMbx command
for each orphaned mailbox that it locates into the file specified by the
filename. Later, the administrator can turn this file into a script file
and run the commands to delete the orphaned mailboxes. If this option and
the -m option are not specified, the default behaviour is to write the
DelMbx commands to standard output.
If the object is "message", this option will be ignored.
Note: This option cannot be used in conjunction with the -m option.
-m filename
When this option is specified, the utility will output a MoveUser command
and a DelMbx command for each orphaned mailbox that it locates into the
file specified by the filename. Later, the administrator can turn this
file into a script file and run the commands to move the orphaned mailboxes
to new mailhosts or maildrop paths. The MoveUser command will copy the
contents of the mailbox (all messages and folders) from the old mailhost's
location to the new mailhost's location or from the old maildrop path to
the new maildrop path. Since the MoveUser does not remove the old mailbox,
the DelMbx command is issued to cleanup the old mailbox. Together, the
MoveUser command and the DelMbx command constitute the move mailbox action.
If the owner of a mailbox cannot be found in the directory or the owner's
mailhost cannot be determined, the utility will output only the DelMbx
command to delete the orphaned mailbox, even though -m is specified since
there is no destination that the mailbox can be moved to.
If this option and the -d option are not specified, the default behaviour
is to write the commands to standard output. If the object is "message",
this option will be ignored.
Note: This option cannot be used in conjunction with the -d option.
-l filename
If this option is specified, all log messages will be written to the file
specified by the filename. Log messages consists of all error messages,
reports of message inconsistencies and orphaned mailboxes, as well as some
other information messages. If this option is not specified, the default
behaviour is to write the log messages to standard output.
DelMbx
The DelMbx command line utility deletes a user mailbox when the mailbox
is no longer in use.
Synopsis:
DelMbx [mailbox path]
where mailbox path is the full path name of the mailbox directory.
Description:
This utility will scan all the messages in the designated directory
and delete all messages, and the message reference count will be adjusted
correctly. All files and sub directories are deleted in the process.
Important: Use this utility instead of the operating system command
rm -r directory. Because of the single-copy message feature
in Messaging Server 3.5, the reference count will become corrupted, and
the master copy message never gets deleted.
MoveUser
The MoveUser command line utility moves messages in users' mailboxes from
one messaging server to another.
Synopsis:
MoveUser -s srcmailhost -x proxyuser -p password -u uid -o srcmaildrop
-m destmaildrop [-l ldapurl -D bindDN -w bindpassword [-f localB path]]
[options]
Description:
When user accounts are moved from one messaging server to another, it is
also necessary to move user's mailboxes (folders) from one server to the
other. This utility moves messages in a user's mailbox from one server
to the other. It also updates entries in the associated LDAP directory
server to reflect the user's new mailhost name and message store path.
This utility makes use of Netscape's PROXYAUTH extensions IMAP4 protocol.
There are several arguments that can be used with the MoveUser utility:
| Arguments |
Explanation |
| -l ldapURL |
ldap://<hostname>:<port>/<base_dn>?<attributes>?<scope>?<filter> |
| -D bindDN |
bind dn |
| -w password |
bind password (for simple authentication) |
| -f localDBpath |
path of the local database to use, if any |
| -u uid |
uid for the user whose mailbox needs to be moved
Not to be used with -l option
|
| -s srcmailhost |
source mail server |
| -x proxyuser |
ProxyAuthUser for source mail server |
| -p password |
password for ProxyAuthUser of srcmailhost |
| -d destmailhost |
destination mail server |
| -a proxyuser |
ProxyAuthServer for destmailhost |
| -v password |
password for ProxyAuthUser on destmailhost |
| -o srcmaildrop |
message store path on srcmailhost |
| -m destmaildrop |
message store path for destmailhost |
| -F |
specifies that messages be deleted only after all messages in a folder
are successfully moved; if this option is not specified, each message is
deleted individually immediately after it is moved |
| -n |
the number of messages to be moved at once |
| -h |
display usage information |
Requirement:
In /etc/netscape.mail.conf file, on a 3.5 server there should be an entry
as follows:
ProxyAuthUser="authorized user"
"Authorized user" may be the administrator of the messaging server.
The utility uses this name and access permission to gain access to mailboxes
for all users.
Components of LDAP URL:
LDAP URLs have the following syntax:
ldap://<hostname>:<port>/<base_dn>?<attributes>?<scope>?<filter>
| <hostname> |
Name of the ldap server |
| <port> |
Port number for the ldap server. If no port is specified, the standard
LDAP port(389) is used. |
| <base_dn> |
Distinguished name of an entry in the directory. This component is
required. |
| <attributes> |
The attributes to be returned. If no attributes are specified, all
attributes are returned. |
| <scope> |
Scope of search.
-
base retrieves information only on the distinguished name (<base_dn>)
specified in the URL.
-
one retrieves information one level below the <base_dn>. The base entry
is not included.
-
sub retrieves information on all entries below the <base_dn>. Base entry
is included in this scope.
|
| <filter> |
Search filter to apply to entries within specified scope of search.
If no filter is specified, (objectclass=*) is used. |
bindDN:
Specifies the distinguished name with which to authenticate to the server.
The value must be a DN recognized by the Directory Server, and it must
also have the authority to modify the entries.
bindDN password:
Specifies the password associated with the bind DN.
Examples:
To move all users from host1 to host2, based on account information in
LDAP:
MoveUser -l "ldap://your.domain.com:389/ou=development,o=writable,c=us?mail?one?(mailhost=host1.domain)"
-D "cn=Directory Manager," -w password -s host1 -x administrator -p password
-d host2 -a administrator -v password -o /var/mail/spool/mailbox -m /nsmail/mail/spool/mailbox
-F
To move one user from host1 to host2, based on account information in
LDAP:
MoveUser -l "ldap://your.domain.com:389/ou=development,o=writable,c=us?mail?one?(uid=user)"
-D "cn=Directory Manager," -w password -s host1 -x administrator -p password
-d host2 -a administrator -v password -o /var/mail/spool/mailbox -m /nsmail/mail/spool/mailbox
-F
To move groups of users from host1 to host2, based on account information
in LDAP:
MoveUser -l "ldap://your.domain.com:389/ou=development,o=writable,c=us?mail?one?(&(mailhost=host1.domain)(uid=s*))"
-D "cn=Directory Manager," -w password -s host1 -x administrator -p password
-d host2 -a administrator -v password -o /var/mail/spool/mailbox -m /nsmail/mail/spool/mailbox
-F
In this example, note (uid=s*). This indicates move all users with uid
starting with s.
To move one user's mailboxes from host1 to host2 when the uid is specified
(for use with the CheckPO utility):
MoveUser -u uid -s host1 -x administrator -p password -d host2 -a administrator
-v password -o /var/mail/spool/mailbox -m /nsmail/mail/spool/mailbox -F
MTA-migrate
This section describes how to use the MTA-migrate utility for migrating
Mail Server 2.x user accounts to Messaging Server 3.5. You can also
use the MTA-migrate utility in upgrading from Messaging Server 3.0 or 3.01
to Messaging Server 3.5 to move LDAP user accounts between different LDAP
hosts or local databases.
The MTA-migrate utility:
-
Migrates users accounts used by a previous Messaging Server version to
the LDAP directory or local database used by your current installation
of the Messaging Server
-
Migrates user mailboxes
-
Migrates SMTP channel aliases (only applicable when
migrating from Mail Server 2.0x)
-
Migrates mailGroups (only applicable when migrating
from Messaging Server 3.0x)
MTA-migrate options
| Option |
Explanation |
Example |
| -n * |
previews what would be migrated in LDIF |
-n |
| -v * |
verbose mode with diagnostic information |
-v |
| -D binddn |
bind dn to ldaphost |
-D "cn=Directory Manager, o=Ace Industry, c=US" |
| -w passwd |
bind password to ldaphost |
-w password |
| -b basedn |
base dn for migration
(defaulted to administration server setting) |
-b "ou=Sales, o=Airius.com" |
| -h host |
hostname of LDAP directory server
(defaulted to administration server setting) |
-h heman |
| -p port |
port number of LDAP directory server
(defaulted to administration server setting) |
-p 389 |
| -C cfgfile |
specifies migration with local database instead of LDAP host
(defaulted to administration server setting) |
-C /usr/netscape/suitespot/userdb/ldap/config/lcache.conf |
| -f format |
optional DN, distinguished name, format string
Format parameters:
%uid, %cn, %mailhost, %basedn
|
-f "cn=%cn, %basedn"
-f "cn=%cn (%uid), %basedn"
-f "uid=%uid, %basedn"
-f "mail=%uid@%mailhost, %basedn"
-f "uid=%uid at %mailhost, %basedn"
|
| -u |
puts uid in dn to avoid duplicate cn |
|
| -P postmtr |
mailgroup or person (defaulted to mailgroup) |
-P mailgroup
-P person |
| -x mbx |
skips migration of mailboxes. Only migrates users to the LDAP directory
server or the local directory database. |
|
| -x dir |
skips migration of directory. Only migrates mailboxes. |
|
| -x alias |
skips migration of SMTP channel aliases. |
|
| -a |
only migrates SMTP channel aliases. Equivalent to "-x mbx -x
dir" |
|
| -m mode |
Three modes of operation allowed:
-m create
-m update
-m delete
create: This is the DEFAULT mode that creates LDAP entries based on
the user accounts found in your previous Messaging Server.
update: This is the update mode that updates existing LDAP entries with
user accounts found in your previous Messaging Server.
delete: This mode will allow the program to delete LDAP entries found
in LDAP server or local database. Use this option with caution as this
delete operation will undo the "create" operation in deleting all LDAP
entries previously migrated.
Remember to run MTA-migrate with -n and -v options that help you preview
the migration.
|
-m create [-n] [-v]
-m update [-n] [-v]
-m delete [-n] [-v] |
| -l yes |
Required option for 3.0x to 3.5 upgrade
This option is not required for migration from 2.0x to 3.x. Use this
option to migrate from 3.x to your new Messaging Server installation.
When you specify this option, you must also specify several additional
options to identify your previous Messaging Server installation:
-h previous LDAP host
-p previous LDAP port number
-b previous LDAP base dn
-C previous local database config file name
-D bind dn of previous LDAP host
-w bind password of previous LDAP host
-O previous Messaging Server post office directory
-M previous Messaging Server mailbox directory
|
-l yes |
| -O post office |
Specifies the previous post office directory if different from the
current setting. |
-O /var/spool/postoffice.2x |
| -M mailbox |
Specifies the 2.x mailbox directory if different from the current setting. |
-M /var/spool/mailbox.2x |
| -H |
Displays usage information. |
-H |
| -? |
Displays usage information for NT |
-? |
* Most examples in this document specify the options -n and -v in
brackets. These options are used for preview and diagnostic purposes
and should be entered without the brackets in actual usage.
Preview with -n option
The -n option allows you to preview the migration results in LDIF file
format. When you specify this option, MTA-migrate does not migrate any
user accounts or mailboxes.
You can use this LDIF output with the LDAP command line tool ldapmodify.
For example,
MTA-migrate -b "ou=demo, o=Ace Industry, c=US" -D "cn=Directory
Manager, o=Ace Industry, c=US" -w password -n >testrun
ldapmodify -D "cn=Directory Manager, o=Ace Industry, c=US" -w password
-f testrun -c
You must provide a proper distinguished name and password for ldapmodify
to use in logging into the LDAP Directory Server to modify the LDAP directory.
Customization of distinguished name
By default, MTA-migrate formats the distinguished name as follows:
cn=John Smith, ou=People, o=Ace Industry, c=US
You can use the following options to customize the distinguished name in
migration.
-u
Formats the distinguished name by adding (uid) to the distinguished name:
cn=John Smith (jsmith), ou=People, o=Ace Industry, c=US
-f format
This option formats the distinguished name according to uid, cn, mailhost,
and basedn
-f formats
| Format |
Example |
| -f "cn=%cn, %basedn" |
cn=John Smith, ou=People, o=Ace Industry, c=US |
| -f "cn=%cn (%uid), %basedn" |
cn=John Smith (jsmith), ou=People, o=Ace Industry, c=US |
| -f "uid=%uid, %basedn" |
uid=jsmith, ou=People, o=Ace Industry, c=US |
| -f "mail=%uid@%mailhost, %basedn" |
mail=jsmith@my.host.com, ou=People, o=Ace Industry, c=US |
| -f "uid=%uid at %mailhost, %basedn" |
uid=jsmith at my.host.com, ou=People, o=Ace Industry, c=US |
Upgrading from Mail Server 2.0x to Messaging Server 3.5 using a directory
server
After installing Messaging Server 3.5 with an LDAP directory server, your
administration server's Global Settings should reflect all the configuations
related to your directory server or local database. The MTA-migrate
program will take all the administration server settings as defaults in
identifying the destination LDAP host or local database. For
example:
MTA-migrate -D "cn=Directory Manager" -w password
[-n] [-v]
If you do not specify the rootdn of the directory server, MTA-migrate
uses the LDAP Bind Account and Password specified in Messaging Server's
System Configuration.
If the post office and mailbox directories of your previous Messaging
Server are located in directories different from those used by your current
installation, you can use the -O and -M options to specify the previous
post office and mailbox directories. For example,
MTA-migrate -D "cn=Directory Manager" -w password
-O /var/spool/postoffice20 -M /var/spool/mailbox20 [-n] [-v]
looks for your user accounts and mailboxes in the specified directories.
You can also use the options -h, -p, and -b to overwrite the current
Administration Server settings. For example,
MTA-migrate -D "cn=Directory Manager" -w password
-h ldaphost -p 1234 -b "ou=newou, o=Airius.com"
specifies ldaphost, ldapport, and basedn values different from the settings
in Administration Server's Global Settings.
If your administration server already points to a directory server and
you want to migrate user accounts to a local database for backup purposes,
you can use the -C option to specify the local database config file.
For example,
MTA-migrate -C "/usr/netscape/suitespot/userdb/ldap/config/lcache.conf"
-x mbx -x alias [-n] [-v]
migrates the user accounts to a local database instead of the LDAP server
specified by the Global Settings form in the Administration Server.
The options "-x mbx" and "-x alias" direct MTA-migrate to skip the migration
of mailboxes and channel aliases as the backup only involves the user accounts
migration.
Upgrading from Mail Server 2.0x to Messaging Server 3.5 using a local
database
When migrating to Messaging Server 3.5 using a local database, MTA-migrate
does not require bind dn and bind password. After installation, you
can migrate to the local database as in the following example:
MTA-migrate [-n] [-v]
You can specify -O and -M options to direct MTA-migrate to look up old
user accounts and mailboxes in directories different from those of the
newly installed Messaging Server.
MTA-migrate -O c:\netscape\server\mailserver\spool
-M c:\netscape\server\mailserver\mailbox [-n] [-v]
If you want to specify a local database configuration file different
from that specified in Administration Server Global Settings, you can use
the -C option to overwite the default. For example:
MTA-migrate -O c:\netscape\server\mailserver\spool
-M c:\netscape\server\mailserver\mailbox -C c:\temp\lcache.conf [-n] [-v]
Upgrading from Messaging Server 3.0x to 3.5
Caution: If you are performing an "in-place" upgrade from Messaging
Server 3.0 or 3.01 to 3.5 satisfying the following conditions, do
not use MTA-migrate or any other tools to perform upgrade, as the format
of LDAP user entries and mailboxes do not change in 3.5:
-
Post office and mailbox directories in your 3.5 installation remain the
same as in your previous 3.0 or 3.01 installation
-
ldaphost, ldapport, basedn remain the same in your 3.5 installation as
in your previous 3.0 or 3.01 installation
-
The local database from your previous 3.0 or 3.01 installation is re-used
by the new installation
If your new installion is not "in-place", you can use MTA-migrate to migrate
your user accounts and mailboxes from your previous LDAP host or local
database; use the special option "-l yes", specifying the options required
to identify your previous Messaging Server installation:
MTA-migrate -l yes
-
-h previous LDAP host
-
-p previous LDAP port number
-
-b previous LDAP base dn
-
-C previous local database config file name
-
-D bind dn of previous LDAP host
-
-w bind password of previous LDAP host
-
-O previous Messaging Server post office directory
-
-M previous Messaging Server mailbox directory
1. Example upgrade from 3.0 using a directory Server to 3.5 using a directory
server (3.0 DS -> 3.5 DS)
MTA-migrate -l yes -D "cn=Directory Manager,
o=Ace Industry, c=US" -w password -h ldaphost3.0 -p 389 -b "o=Ace Industry,
c=US" [-n] [-v]
The bind dn and bind password specified by the -D
and -w options refer to the 3.0x installation. If your bind dn and
password for your 3.5-installed LDAP host are different, you will be prompted
for the new bind dn and bind password for your 3.5 LDAP host.
2. Example upgrade from 3.0 using a local database to 3.5 using a directory
server (3.0 LDB -> 3.5 DS)
MTA-migrate -l yes -D "cn=Directory Manager"
-w password -C "/usr/netscape/suitespot30/userdb/ldap/config/lcache.conf"
-O /var/spool/postoffice30 -M /var/spool/mailbox30 -b ""
[-n] [-v]
The option -b "" is required to specify an empty
basedn if the 3.0 local database uses an empty basedn. The options
-O and -M are used when post office and mailbox directories are different
in the new installation.
3. Example upgrade from 3.0 using a local database to 3.5 using a local
database and the same post office and mailbox directories (3.0 LDB ->
3.5 LDB )
MTA-migrate -l yes -C "/usr/netscape/suitespot30/userdb/ldap/config/lcache.conf"
-b ""
There is no need to use -D and -w as binding is not required when using
local database.
4. Example upgrade from 3.0 using a directory server to 3.5 using a
local database (3.0 DS -> 3.5 LDB)
MTA-migrate -l yes -D "cn=Directory
Manager, o=Ace Industry, c=US" -w password -h ldaphost -p 389 -b "o=Ace
Industry, c=US"
All specified options in -D, -w, -h, -p and -b refer to the previous
ldaphost installed for the 3.0x Messaging Server.
Copyright 1997 Netscape Communications Corporation. All rights
reserved.