Chapter 2
Configuring General Messaging Capabilities
This chapter describes the general Messaging Server tasks—such as starting and stopping services and configuring directory access—that you can perform by using Netscape Console (hereafter called Console) or by using command-line utilities. Tasks specific to individual Messaging Server services—such as POP, IMAP, HTTP, and SMTP—are described in subsequent chapters. This chapter contains the following sections:
|
Note
|
End-user account information and domain-specific information is managed primarily through the Delegated Administrator for Messaging interface. For more information, see the Delegated Administrator for Messaging Installation and Administration Guide and the online help that comes with Delegated Administrator.
|
Viewing Basic Server Information
You can review some of the basic information about an installed Messaging Server by viewing its Information form in Console.
To display the Information form:
In Console, open the Messaging Server whose information you want to view.
Select the server's icon in the left pane.
Click the Configuration tab in the left pane.
Click the Information tab in the right pane, if it is not already frontmost.
-
The Information form appears. It displays the server name, server root directory, installation directory, and instance directory.
Starting and Stopping Services
Services are started and stopped differently depending on whether they are installed in an HA environment or note.
Starting and Stopping Services in an HA Environment
While the Messaging Server is running under HA control, you cannot use the normal Messaging Server start, restart, and stop commands to control individual Messaging Server services. Doing so will cause the HA control to think that one or more services have unexpectedly stopped at which point it will either attempt to restart all of Messaging Server or fail it over to another cluster node.
The appropriate start, stop and restart commands are shown in the tables below. Note that there are no Sun Cluster commands to start, restart, or stop a single Messaging Server service (for example, SMTP). Sun Cluster's finest granularity is that of an individual resource. Since Messaging Server is known to Sun Cluster as a resource, scswitch commands affect all Messaging Server services as a whole.
Table 2-1 Start, stop, restart in a Sun Cluster 3.0 environment
|
Action
|
Individual Resource
|
Entire Resource Group
|
|
Start
|
scswitch -e -j <resource>
|
sscswitch -Z -g <resource-group>
|
|
Restart
|
scswitch -n -j <resource>
scswitch -e -j <resource>
|
scswitch -R -g <resource-group>
|
|
Stop
|
scswitch -n -j <resource>
|
scswitch -F -g <resource-group>
|
Table 2-2 Start, stop, restart in a Sun Cluster 2.2 environment
|
Action
|
Individual Data Service
|
All Registered Data Services
|
|
Start
|
hareg -y <data_service>
|
hareg -Y
|
|
Restart
|
hareg -n <data_service>
hareg -y <data_service>
|
hareg -N
hareg -Y
|
|
Stop
|
hareg -n <data_service
|
hareg -N
|
Table 2-3 Start, stop, restart in Veritas 1.1 environment
|
Action
|
Individual Resource
|
Entire Resource Group
|
|
Start
|
hares -online <resource> -sys <system>
|
hagrp -online <group> -sys <system>
|
|
Restart
|
hares -offline <resource> -sys <system>
hares -online <resource> -sys <system>
|
hagrp -offline <group> -sys <system>
hagrp -online <group> -sys <system>
|
|
Stop
|
hares -online <resource> -sys <system>
|
hagrp -online <group> -sys <system>
|
Starting and Stopping Services in a non-HA Environment
You can start and stop services from Console or from the command line.
You only need to run the services that your server actually uses. For example, if you are temporarily using a particular instance of Messaging Server solely as a message transfer agent (MTA), you can turn on the MTA alone. Or, if maintenance, repair, or security needs require shutting down the server, you may be able to turn off just the affected service. (If you never intend to run a particular service, you should disable it instead of just turning it off.)
Important: If a server process crashes, other processes will hang as they wait for locks held by the server process that crashed. Therefore, if any server process crashes, you should stop all processes, then restart all processes. This includes the POP, IMAP, HTTP, and MTA processes, as well as the stored (message store) process, and any utilities that modify the message store, such as mboxutil, deliver, reconstruct, readership, or upgrade.
Console.
Console provides a form that allows you to start and stop individual services and view status information about each service.
For each service—IMAP, POP, SMTP, and HTTP—the form displays the service's current state (on or off). If the service is running, the form shows the time at which the service was last started up, and it can also display other status information.
To start up, shut down, or view the status of any messaging services:
From Console, open the Messaging Server whose services you want to start or stop.
Get to the Services General Configuration form in either of these two ways:
Click the Tasks tab, then click "Start/Stop Services".
Click the Configuration tab and select the Services folder in the left pane. Then click the General tab in the right pane.
The Services General Configuration form appears.
-
The left column of the Process Control field lists the services supported by the server; the right column gives the basic status of each of the services (ON or OFF, plus—if it is ON—the time it was last started).
To view status information about a service that is currently on, select the service in the Process Control field.
-
The Service Status field displays status information about the service.
-
For POP, IMAP, and HTTP the field shows the last connection time, the total number of connections, the current number of connections, the number of failed connections since the service last started, and the number of failed logins since the service last started.
-
The information in this field helps you to understand the load on the server and the reliability of its service, and it can help spotlight attacks against the server's security.
To turn a service on, select it in the Process Control field and click Start.
To turn a service off, select it in the Process Control field and click Stop.
To turn all enabled services on or off simultaneously, click the Start All or Stop All button.
Command Line.
You can use the start-msg and stop-msg commands to start or stop any of the messaging services (pop, imap, http, smtp, store), as shown in the following example:
server-root/msg-instance/start-msg imap
server-root/msg-instance/stop-msg pop
server-root/msg-instance/stop-msg smtp
|
Note
|
The start-msg smtp and stop-msg smtp commands start and stop all of the MTA services—not just the SMTP server. If you want more granular control when starting or stopping the MTA services, use the imsimta start and imsimta stop commands. For more information, see the Messaging Server Reference Manual.
|
Configuring a Greeting Message
Messaging Server allows you to create a greeting message to be sent to each new user.
Console.
To create a new-user greeting by using Console:
In Console, open the Messaging Server whose new-user greeting you want to configure.
Click the Configuration tab. If the server's icon in the left pane is not already highlighted, select it.
Click the Miscellaneous tab in the right pane.
Create a new-user greeting or make changes, as needed.
-
You must format the greeting as an email message, with a header (containing at least a subject line), then a blank line, then the message body.
-
When you create a message, specify its language with the drop-down list above the message field. You can create several messages in several languages, if desired. The server attempts to send the correct language version of the message to the new user based on the information described in "Configuring Languages for Auto-Reply Messages."
Click Save.
Command Line.
To create a new-user greeting by using the command line:
configutil -o gen.newuserforms -v value
Configuring Languages for Auto-Reply Messages
This section describes how, for notices and messages sent by the server, the server selects the language-specific version to send. It also describes how users specify a preferred language and how you can specify a default server-site language.
Users can create messages for the server to send automatically under certain specified conditions. For example, an "I am on vacation" message as an automatic reply to all incoming mail. When users create messages of this kind, they can specify that the message is written in a particular language. This allows users to create different, language-specific versions of messages that the server is to send.
Users can also specify a preferred language that indicates in which language they wish to receive automatic reply messages—if that language version is available.
The server selects the language-specific version of a message to send according to the following rules:
If the user to whom the message is being sent has chosen a preferred language (see Choosing a User-Preferred Language) and a language-specific version of that message exists, the server sends that version of the message. For example, if the user has chosen Japanese, and there is a Japanese version of the message, the Japanese version is sent.
If the user has not chosen a preferred language, or has chosen a preferred language but there is no version of the message in that language, the version that matches the default server-site language (see Configuring a Server Site Language) is sent. For example, if the default site language is Spanish and the user has chosen French but there is no French version of the message, the Spanish version is sent.
If there is no version of the message that matches either the user's preferred language or the default site language, but there is an English-language version, the English version is sent. For example, if the default site language is Spanish and the user has chosen German but there are only French and English versions of the message, the English version is sent.
If there is only one version of the message, regardless of language preference or site language, that is the version that is sent.
|
Note
|
Although Delegated Administrator top-level administrators can set a default language for a hosted domain, Messaging Server does not use this setting when determining which language version of a message to send.
|
Choosing a User-Preferred Language
Users can choose a preferred language by using the Delegated Administrator for Messaging interface. Some mail clients also allow users to specify a preferred language. If the preferred language is set using Delegated Administrator, the information is stored in Directory Server.
When the server sends messages to users outside of the server's administrative domain it does not know what their preferred language is unless it is responding to an incoming message with a preferred language specified in the incoming message's header. The header fields (Preferred-Language or X-Accept-Language) are set according to attributes specified in the user's mail client.
If there are multiple settings for the preferred language—for example, if a user has a preferred language attribute stored in the Directory Server and also has a preferred language specified in their mail client—the server chooses the preferred language in the following order:
The Preferred-Language header field of the original message
The X-Accept-Language header field of the original message
The preferred language attribute of the sender (if found in the LDAP directory)
Configuring a Server Site Language
You can specify a default site language for your server as follows. The site language will be used to send language-specific versions of messages if no user preferred language is set.
Console.
To specify a site language from Console:
Open the Messaging Server you want to configure.
Click the Configuration tab.
In the right pane, click the Miscellaneous tab.
From the site language drop-down list, choose the language you wish to use.
Click Save.
Command Line.
You can also specify a site language at the command line as follows:
configutil -o gen.sitelanguage -v value
where value is one of the local supported languages:
af Afrikaans
ca Catalan
da Danish
de German
en English
es Spanish
fi Finnish
fr French
ga Irish
gl Galician
is Icelandic
it Italian
ja Japanese
nl Dutch
no Norwegian
pt Portuguese
sv Swedish
Enabling Single Sign-On (SSO)
Single sign-on allows an end user to authenticate once to use multiple applications. For example, a user can log on to Messenger Express then use Delegated Administrator for Messaging without authenticating again.
To enable single sign-on between applications, you must configure each application. This section describes how to enable single sign-on between Messenger Express and Delegated Administrator. See "Messenger Express and Delegated Administrator for Messaging".
Messenger Express SSO Configuration Parameters
You can modify the single sign-on configuration parameters for Messenger Express, shown in Table 2-4, by using the configutil command. For more information about configutil, see the Messaging Server Reference Manual.
Table 2-4 Messenger Express Single Sign-On Parameters
|
Parameter
|
Description
|
|
local.webmail.sso.enable
|
Enables or disables all single sign-on functionality, including accepting and verifying SSO cookies presented by the client when the login page is fetched, returning an SSO cookie to the client on successful login and responding to requests from other SSO partners to verify its own cookies.
If set to any non-zero value, the server performs all SSO functions.
If set to zero, the server does not perform any of these SSO functions.
The default value is zero.
|
|
local.webmail.sso.prefix
|
The string value of this parameter is used as the prefix value when formatting SSO cookies set by the HTTP server. Only SSO cookies with this prefix will be recognized by the server; all other SSO cookies will be ignored.
A null value for this parameter effectively disables all SSO functionality on the server.
The default value is null.
|
|
local.webmail.sso.id
|
The string value of this parameter is used as the application ID value when formatting SSO cookies set by the HTTP server.
The default value is null.
|
|
local.webmail.sso.
cookiedomain
|
The string value of this parameter is used to set the cookie domain value of all SSO cookies set by the HTTP server.
The default value is null.
|
|
local.webmail.sso.
singlesignoff
|
The integer value of this parameter, if set to any non-zero value, clears all SSO cookies on the client with prefix values matching the value configured in local.webmail.sso.prefix when the client logs out.
If set to zero, Messenger Express will clear its own SSO cookie when the client logs out.
The default value is zero.
|
|
local.sso.appid.verifyurl
|
Sets the verify URL values for peer SSO hosts. appid is the application ID of a peer SSO host whose SSO cookies are to be honored. For example, the appid for Delegated Administrator is nda45.
There should be one parameter defined for each trusted peer SSO host. The standard form of the verify URL is:
http://nda-host:port/VerifySSO?
|
So to enable single sign-on for Messenger Express, you would set the configuration parameters as follows (your default domain is eng.siroe.com)
|
configutil -o local.sso.appid.verifyurl -v "http://nda-host:port/verifySSO?"
configutil -o local.webmail.sso.enable -v 1
configutil -o local.webmail.sso.prefix -v ssogrp1
configutil -o local.webmail.sso.id -v msg50
configutil -o local.webmail.sso.cookiedomain -v ".siroe.com"
configutil -o local.webmail.sso.singlesignoff -v 1
|
|
Messenger Express and Delegated Administrator for Messaging
To enable single sign-on between Messenger Express and Delegated Administrator, you must perform additional steps as follows:
Configure Directory Server
Create a proxy user account entry in the Directory Server
Create an ACI (Access Control Instructions) for proxy authentication
Configure Delegated Administrator
Add the proxy user credentials
Add the single sign-on cookie information
Add the participating servers verification URL
Restart the Enterprise Server
To configure Directory Server, you will use the ldapmodify utility. For more information about this utility, see your Directory Server documentation.
To configure Delegated Administrator, you will modify the following configuration files:
DA-server-root/nda/classes/netscape/nda/servlet/resource.properties
Enterprise-Server-Root/https-instancename/config/servlets.properties
Enterprise-Server-Root/https-instancename/config/contexts.properties
Step 1a. Create a Proxy User Account
The proxy user account allows users to bind to the Directory Server for proxy authentication. You must create this account (using the ldapmodify utility) in a base suffix other than the Delegated Administrator base suffix (osiroot). For example, the following is an example of a proxy user account entry (we will assume that osiroot is at o=isp):
|
dn: uid=proxy, ou=people, o=siroe.com, o=mailqa
objectclass: top
objectclass: person
objectclass: organizationalperson
objectclass: inetorgperson
uid: proxy
givenname: Proxy
sn: Auth
cn: Proxy Auth
userpassword: proxypassword
|
|
Step 1b. Create an ACI for Proxy Authentication
Next, using the ldapmodify utility, create an ACI for the suffixes you created at install time:
osiroot - The suffix you entered to store the user data
dcroot - The suffix you entered to store the domain information
osiroot - The suffix you entered to store the configuration information (the default is osiroot)
For example, the following is an example of an ACI entry:
|
dn: o=isp
changetype: modify
add: aci
aci: (target="ldap:///o=isp")(targetattr="*")(version 3.0; acl
"proxy";allow (proxy) userdn="ldap:///uid=proxy, ou=people,
o=siroe.com, o=mailqa";)
|
|
Step 2a. Add the Proxy User Credentials to the resource.properties File
To configure Delegated Administrator for proxy authentication, uncomment and modify the following entries in the Delegated Administrator resource-properties file:
LDAPDatabaseInterface-ldapauthdn=Proxy-Auth-DN
LDAPDatabaseInterface-ldapauthpw=Proxy-Auth-Password
For example:
LDAPDatabaseInterface-ldapauthdn=uid=proxy, ou=people,o=siroe.com, o=mailqa
LDAPDatabaseInterface-ldapauthpw=proxypassword
Step 2b. Add the Single Sign-On Cookie Information
To add the single sign-on cookie information, define a context identifier for Delegated Administrator and specify a cookie name for the context, as follows:
To define a context identifier, edit the Enterprise Server servlets.properties file and uncomment all lines containing the text servlet.xxxxx.context=ims50.
To specify a cookie name for the context in the Delegated Administrator configuration, add the following entry to the Delegated Administrator resource.properties file:
-
NDAAuth-singleSignOnId=ssogrp1-
NDAAuth-applicationId=nda45
To specify a cookie name for the context in the Enterprise Server configuration, add the following entry to the Enterprise Server contexts.properties file:
-
context.ims50.sessionCookie=ssogrp1-nda45
Step 2c. Add the Participating Servers Verification URL
To verify a single sign-on cookie it received, Delegated Administrator must know who to contact. You must provide a verification URL for all known participating servers.
For purposes of the following example, assume Messenger Express is installed and its application ID is msg50. Edit the Delegated Administrator resource.properties file and add an entry such as:
verificationurl-ssogrp1-msg50=http://<webmail_hostname>:port/
VerifySSO?
verificationurl-ssogrp1-nda45=http://<nda_hostname>:port/
VerifySSO?
Step 3. Restart the Enterprise Server
After you've made the configuration changes described in steps 1a through 2c, you must restart the Enterprise Server for the changes to take effect.
Customizing Directory Lookups
iPlanet Messaging Server cannot function without an LDAP-based directory system such as the iPlanet Directory Server. Messaging Server and Console require directory access for three purposes:
When you first install a Messaging Server, you enter configuration settings for the server. These settings are stored in a central configuration directory. Part of the installation process includes configuring the connection to that directory.
When you create or update account information for mail users or mail groups, the information is stored in a directory called the user directory. Your server group's Administration Server is configured at installation so that when you access Users and Groups, Console connects by default to the user directory that defines your administrative topology—the set of iPlanet servers that all share the same configuration directory and user directory.
When routing messages and delivering mail to mailboxes, Messaging Server looks up information about the sender or recipients in the user directory. By default, Messaging Server looks in the same user directory that its Administration Server has been configured to use.
You can modify each of these directory-configuration settings in the following ways:
The Administration Server interface of Console lets you change the connection settings for the configuration directory. (For more information, see the Administration Server chapter of Managing Servers with Netscape Console.)
The Users and Groups interface of Console lets you temporarily connect to a different user directory from the default when making changes to user and group information. (For more information, see the Users and Groups chapter of Managing Servers with Netscape Console.)
The Messaging Server interface of Console lets you configure your Messaging Server to connect to a different user directory from the default defined by the Administration Server. This is the configuration task discussed in this section.
Reconfiguring your Messaging Server to connect to a different user directory for user and group lookups is strictly optional. In most cases, the user directory that defines your server's administrative domain is the one used by all servers in the domain.
|
Note
|
If you specify a custom user directory for your Messaging Server lookups, you must also specify that same directory whenever you access the Users and Groups interface of Console to make changes to the directory's user or group information. For more information, see Chapter 3 "Managing Mail Users and Mailing Lists."
|
Console.
To modify the Messaging Server LDAP user-lookup settings by using Console:
From Console, open the Messaging Server whose LDAP connection you want to customize.
Click the Configuration tab.
Select the Services folder in the left pane.
Select the LDAP tab in the right pane. The LDAP form appears.
-
The LDAP form displays the configuration settings for both the configuration directory and the user directory. The configuration-directory settings, however, are read-only in this form. See the Administration Server chapter of Managing Servers with Netscape Console if you need to change them.
To change the user-directory connection settings, click the box labeled "Use messaging server specific directory settings".
Update the LDAP configuration by entering or modifying any of the following information (for explanations of directory concepts, including definitions of terms such as distinguished name, see the Directory Server Administrator's Guide):
-
Host name: The name of the host machine on which the directory containing your installation's user information resides. This is typically not the same as the Messaging Server host, although for very small installations it might be.
-
Port number: The port number on the directory host that Messaging Server must use to access the directory for user lookup. This number is defined by the directory administrator, and may not necessarily be the default port number (389).
-
Base DN: The search base—the distinguished name of a directory entry that represents the starting point for user lookups. To speed the lookup process, the search base should be as close as possible in the directory tree to the information being sought. If your installation's directory tree has a "people" or "users" branch, that is a reasonable starting point.
-
Bind DN: The distinguished name that your Messaging Server uses to represent itself when it connects to the directory server for lookups. The bind DN must be the distinguished name of an entry in the user directory itself that has been given search privileges to the user portion of the directory. If the directory allows anonymous search access, you can leave this entry blank.
To change the password used, in conjunction with the Bind DN, to authenticate this Messaging Server to the LDAP directory for user lookups, click the Change Bind password button. A Password-Entry window opens, into which you can enter the updated password.
-
Your own security policies should determine what password you use in this situation. Initially, the password is set to no password. The password is not used if you have specified anonymous access by leaving the Bind DN field blank.
-
This step updates the password stored in server configuration, but does not change the password in the LDAP server. This account is also used for PAB lookups by default. The following two steps need to be performed after the password has been changed.
Modify the password for the user specified in the configuration attribute local.ugldapbinddn. This user account exists in the directory server specied in configuration attribute local.ugldaphost.
If the same account is used for PAB access, specified in the attributes local.service.pab.ldapbinddn and local.service.pab.ldaphost, then the password stored in local.service.pab.ldappasswd must also be updated.
To return to using the default user directory, uncheck the "Use messaging server specific directory settings" box.
Command Line.
You can also set values for the user-directory connection settings at the command line as follows. Be sure to also set the LDAP and PAB password as described in the steps 8 and 9 above.
To specify whether to use messaging server specific directory settings:
configutil -o local.ugldapuselocal -v [ yes | no ]
To specify the LDAP host name for user lookup:
configutil -o local.ugldaphost -v name
To specify the LDAP port number for user lookup:
configutil -o local.ugldapport -v number
To specify the LDAP base DN for user lookup:
configutil -o local.ugldapbasedn -v basedn
To specify the LDAP bind DN for user lookup:
configutil -o local.ugldapbinddn -v binddn
Encryption Settings
You can use Console to enable Secure Sockets Layer (SSL) encryption and authentication for Messaging Server and to select the specific encryption ciphers that the server will support across all of its services.
Although this task is a general configuration task, it is described in the section "Enabling SSL" in Chapter 11 "Configuring Security and Access Control" which also contains background information on all security and access-control topics for Messaging Server.
-