This appendix provides information on how to operate certain Netscape Messaging
Server 3.0 functions from the Unix command line. It also presents a variety
of command-line utilities that you can use with Netscape Messaging Server
3.0.
The Unix version of the messaging server provides certain operations that you can perform from the command line: starting up and shutting down the system and checking and delivering the mail queue.
Note
For utilities that you can run from the command line, see "Command-line utilities" later in this appendix for more information.
Once installed, the messaging server normally starts up when the computer is turned on and runs continuously until the computer is shut down. (The startup script uses usr/lib/sendmail -bd to start the Messaging Server in daemon mode.) If for some reason you need to manually start the system, type the following command:
NscpMail start
The specific path to the command depends on where the system is installed. Default Unix installations are in the directory /etc/NscpMail.
The messaging server is usually shut down automatically with boot scripts. If it's necessary to manually shut down the program, use the following command:
NscpMail shutdown
Wait five to ten seconds. (Use the ps command to find the NscpMail process, if it still exists.)
% kill -9 <PID-Of-NscpMail-Server>
To check the mail queue, type mailq at a command prompt. If there are no queued messages, that fact will be reported:
% mailq
Mail queue is empty.
%
If there are queued messages, each host that has queued messages waiting to be delivered will be listed, along with the number of pending deliveries. For example, output might look like this:
% mailq
Queued Messages Destination Host
--------------- ----------------
2 math.csusj.edu
3 expertelligence.com
%
In this example, five messages are waiting for delivery. Delivering all of them should require two connections to other machines because the messaging server attempts to deliver all queued mail for a host before disconnecting.
The queue is automatically processed at regular intervals, so you normally never need to deliver the queue manually. Of course, you can use the Queue form to process the queue; however, if you want to process the entire queue manually at the command line, use the processq command:
/usr/lib/processq
To attempt to deliver all queued mail for a specific host, use this command:
/usr/lib/processq hostname
The hostname can be the full name of the host as reported by mailq, or any pattern contained in the name. If the pattern matches more than one hostname, each match will have its queue processed.
The following sections describe a variety of command line utilities that you can use with Messaging Server 3.0.
The CheckPO command line utility checks a message store for message inconsistencies, searches for "orphaned" mailboxes, and fixes message corruptions if needed.
CheckPO [-h] [-u userid | -p maildrop] [-f] [-d filename | -m filename] [-l filename] object
The CheckPO utility will detect inconsistencies in the Netscape Messaging Server 3.0's 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:
When this option is specified, a detailed description of the utility will be displayed.
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 post office. This value is used to map to a physical mailbox in this message store.
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 behavior is to check all mailboxes in the message store.
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:
If this option and the -p option are not specified, the default behavior is to scan all messages in all mailboxes in the post office.
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 Administration Server 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 behavior 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:
If this option and the -u option are not specified, the default behavior is to scan all messages in allmailboxes in the post office.
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...etc.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".
When this option is specified, the utility will output a DelMbx command for each of the 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 behavior 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.
When this option is specified, the utility will output a MoveUser command and a DelMbx command for each of the 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 behavior 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.
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 behavior is to write the log messages to standard output.
The DelMbx command line utility deletes a user mailbox when the mailbox is no longer in use.
DelMbx [mailbox path]
where mailbox path is the full path name of the mailbox directory.
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.0, the reference count will become corrupted, and the master copy message never gets deleted.
The MoveUser command line utility moves messages in users' mailboxes from one Messaging Server to another.
MoveUser-s srcmailhost -x proxyuser -p password -u uid -o srcmaildrop -m destmaildrop [-l ldapurl -D bindDN -w bindpassword [-f localB path]] [options]
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 mailhostname 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:
In /etc/netscape.mail.conf file, on a 3.0 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.
LDAP URLs have the following syntax:
ldap://<hostname>:<port>/<base_dn>?<attributes>?<scope>?<filter>
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.
Specifies the password associated with the bind DN.
Following are some examples of how to use the MoveUser utility:
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
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
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
In this example, note (uid=s*). This indicates move all users with uid starting with s.
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
This section provides instructions for MTA-migrate utility for migrating users from MTA-Accounts in a 2.x Mail Server to Messaging Server 3.0. The MTA-migrate utility
The following options allow you to specify the LDAP Directory Server that your MTA-Accounts are migrated to.
Specifies the distinguished name used 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 under the given basedn. If -D and -w parameters are not specified, default is binding as anonymous person.
Specifies the password associated with the distinguished name specified in the -D option. If -w is not specified in command line option, user will be prompted for password if -D option is used in the command line.
Specifies the name of the host on which the LDAP Directory Server is running. If -h parameter is not specified, default is using the settings in Administration Server. If Administration Server is not installed, default is localhost.
Specifies the port number that the LDAP Directory Server uses. If -p parameter is not specified, default is using the settings in Administration Server. If Administration Server is not installed, default is 389.
MTA-migrate can work with a local directory database. The -C parameter is specific for migration to a local directory database; all other options remain the same for the local directory database.
Specifies the complete file name of the configuration file for Local DB such as
/usr/netscape/suitespot/userdb/ldap/config/lcache.conf.
Allows user to preview the migration results in LDIF file. Once this option is used, MTA-migrate will merely display the migration results in LDIF file format. It will not migrate any user accounts or mailboxes.
Essentially, output of MTA-migrate, when used with -n option, can be used 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
A proper distinguished name and password are required for ldapmodify to authenticate with the LDAP Directory Server for modification privilege.
By default, MTA-migrate will choose to format the distinguished name as follows:
n=John Smith, ou=People, o=Ace Industry, c=US
You can use the following options to customize the distinguished name in migration.
Formats the distinguished name by adding (uid) to the distinguished name:
n=John Smith (jsmith), ou=People, o=Ace Industry, c=US
You can use the optional -f parameter to format the distinguished name according to uid, cn, mailhost, and basedn
Specifies the directory for 2.x post office if different from 3.0 post office. This option is required if a 3.0 post office is installed in a directory different from the 2.x post office directory
Specifies the directory for 2.x mailbox if different from 3.0 mailbox. This option is required if 3.0 mailbox resides in a directory different from the 2.x mailbox directory.
Migration of Postmaster By default, MTA-migrate will migrate Postmaster as a mailGroup in 3.0 MailServer.
Specifies migration of Postmaster as a person. This will preserve all the forwarding addresses and mail delivery options for Postmaster as a person as in 2.x MTA-Accounts.
Specifies migration of Postmaster as a mailGroup. This will include all the forwarding addresses to Postmaster in the member list of a mailgroup. All the forwarding addresses will be created in rfc822MailMember of a mailGroup objectClass.
This option allows the program to skip the migration of mailboxes. This option is useful when you want to migrate the 2.x user accounts to an LDAP Directory Server or a local directory database without upgrading the 2.x mailboxes.
This option allows the program to skip the migration of user accounts to an LDAP Directory Server or a local directory database. This option is useful when you want to migrate mailboxes without creating LDAP accounts. This assumes that you have manually created the LDAP accounts and that they contain all the mail attributes required by the Messaging Server.
MTA-migrate -D "cn=Directory Manager, o=Ace Industry, c=US" -w password
This example migrates 2.x accounts to the LDAP Directory Server with port number and base dn settings specified in the Administration Server.
MTA-migrate -b "ou=People ,o=Ace Industry, c=US" -D "cn=Directory Manager, o=Ace Industry, c=US" -w password
Similar to the first example, this example migrates 2.x accounts to the specified basedn "ou=People, o=Ace Industry, c=US"
MTA-migrate -D "cn=Directory Manager, o=Ace Industry, c=US" -w password -O /var/spool/postoffice.2x -M /var/spool/mailbox.2x
This example migrates accounts found in /var/spool/postoffice.2x with mailboxes specified in /var/spool/mailbox.2x to the LDAP Directory Server with settings specified in the Administration Server.
MTA-migrate -C "/usr/netscape/suitespot/userdb/ldap/configlcache.conf" -O /var/spool/postoffice.2x -M /var/spool/mailbox.2x
Similar to the previous example, this example migrates 2.x accounts to a local directory database.