This chapter discusses Netscape Messaging Server configuration. Although
the minimum set of mandatory configuration decisions are taken care of
during installation, some refinements can enhance your email system by
optimizing the Messaging Server for your specific needs.
This chapter provides information on the forms found in the Messaging Server's System Settings menu of forms. They include:
The Messages form allows you to compose and enable default messages for host finger information; vacation, reply and echo auto-reply; and error actions such as when message quotas are exceeded. Some of these default messages can be replaced when users provide their own messages--for instance, when using the User Management form to compose their own vacation message.
If the AutoReply handler is enabled and you do not have entries in this default form, users will be required to enter their own messages to activate the vacation feature. Also, server administrators will be required to specify messages for all accounts using the reply or echo feature.
The following sections describe the fields on the Messages form.
This field contains the information provided to finger queries that don't include a username (and are therefore addressed more generally to your company or organization). This field is a good place to put miscellaneous information about your company and contact names and email addresses.
This field contains the vacation message that will be used if users forget to write a personalized message. If this field is left blank, the account manager won't accept a User Management form if the vacation feature is selected and no vacation message is included.
Anyone who sends messages to a user's account while the vacation setting is activated will receive one notice about the user's absence. Any subsequent messages that person sends are ignored.
Warning!
In most cases, server administrators should not replace a user's current delivery with the vacation setting when they set up the AutoReply handler for that user's account. If they do this, the user will return from vacation only to find that all of his or her email has been thrown away. Rather, the vacation setting should be used in addition to the normal delivery method, so the mail is held for the user to retrieve upon his or her return. (Users are prevented from making this mistake because the Messaging Server doesn't accept Information forms with a delivery of "Vacation" only.)
This field typically contains a generic message for users sending messages to this address. A common use of the echo feature is to return mail addressed to people who have moved on and left no forwarding address. If this field is left blank, the account manager will require that an echo message be included when the echo feature is selected on a Mail User Information form.
The echo feature generates a message to anyone who sends a message to the account. In addition, it returns the mail (as a MIME attachment) that was sent to the account, so that the sender gets back the original message as well as the message that you entered.
The echo feature, like the vacation feature, is intended to inform people about the status of the account they have contacted.
You can use this field to specify a message that can be used to advise the sender to contact the server administrator. If this field is left blank, the account manager will require a reply message when the reply feature is selected. It's usually best to leave this field blank.
The reply feature is useful for special accounts that are created to disseminate information of one kind or another. You can create a place where people can get files, analogous to a File Transfer Protocol (FTP) site on the Internet.
You can use this field to specify a message to advise senders that mail is undeliverable because the recipient's mailbox has reached its quota.
If all mail systems in your organization are Netscape Messaging Servers, and all use a common LDAP Directory Server, then the information in the Directory Server's user and group entries are sufficient for internal mail routing within an organization. In other cases, there are two recommended ways for the Messaging Server to route mail to dissimilar mail systems: SMTP channel aliases and Forward Delivery (an option in the Mail User Information form).
If you are using the LDAP Directory Server to administer multiple Messaging Servers in your mail system, the recommended procedure for forwarding messages from one host to another is to use the Addresses for Forward Delivery field in the Administration Server's Mail User Information form. There are two advantages to using this approach. First, forwarding information is centralized. You don't have to replicate the information in each Messaging Server configuration. Second, forwarding is automatic in the sense that you enter the forwarding address while setting up a user's mail account, and messages are forwarded without any further intervention.
The alternative to using the LDAP Forward Deliver option is to use an SMTP channel alias. SMTP channel aliases also handle incoming messages that are forwarded to another Messaging Server on a different host. However, SMTP channel aliases are not centralized: you must set up aliases on a per-server basis. Nor are SMTP channel aliases automatic: once you set up a user's mail account, you still need to create the aliases for that user "by hand."
SMTP channel aliases are required in mail systems that do not take advantage of a centralized LDAP Directory Server, or in a "mixed" mail system that includes non-LDAP-aware mail servers, such as sendmail.
SMTP channel aliases are specific to the SMTP channel. Whenever a message enters the Messaging Server system destined for one of the listed SMTP channel aliases, the address is immediately rewritten and the message delivered to the new address at a remote host. The message is delivered to the remote machine without ever being seen by the Account handler. SMTP channel aliases are used extensively when a site sets up a mail hub through which all incoming messages are routed before being delivered to the intended user's host machine.
Figure 2.1 shows an SMTP channel alias in action. In the figure, someone of the XYZ organization occasionally sends mail to Jane Doe at Dispatch.com. Let's say, however, that Jane has recently left Dispatch.com to move to another building. To help Jane continue to receive her mail, an SMTP channel alias was set up for her using the SMTP Channel Aliases form:
<Jane.Doe@Dispatch.com> <Jane@Corp.com>
Whenever a message arrives addressed to Jane.Doe@Dispatch.com, the address is replaced with her new address. The message is then forwarded to its new destination, Corp.com.
You can use the SMTP Channel Aliases form to set up aliases for the SMTP mail channel. To reach this form, choose System Settings | Aliases.
To set up an SMTP channel alias address, fill out the incoming and outgoing addresses and submit the form. Each line is a separate alias where you enter first the address for which the SMTP channel will accept messages followed by the address to which it will redirect these messages.
You must set up aliases one address at a time. For example, if Jane Doe leaves Dispatch.com to take a higher position in Washington, D.C., and her account at Dispatch.com has the following primary and alias addresses (all of which she uses), you will have to set up an alias for each of these addresses:
The SMTP Aliases form also provides the option of specifying a simple text file with which to import Channel Alias data in the form of a list of entries, instead of entering the data directly on the form. The text file must contain entries in the same syntax as if you were entering the data directly in the SMTP Aliases form.
Note
The filename you enter in the Import Channel Alias Table field should be an absolute path to a file on the system on which the Administration Server is running.
It does not matter if the field not selected has any content. For example, if the manual input option is selected and a filename is present in the Filename field, the input will not be taken from the file listed.
You can use the SMTP Channel Options form to configure the SMTP mail channel. This form is used to configure a variety of options specific to the SMTP channel but is not used to set channel aliases. This form includes configuration for the most common Messaging Server error, Unknown Local Account. It also includes the SMTP Mail Routing table.
The following sections describe the fields on the SMTP Channel Options form.
Use this parameter to prevent infinite mail loops. Usually a mail loop is caused by having two email accounts on different machines that forward mail to one another. Fortunately, these loops can be detected and stopped because each MTA stamps all incoming messages as "Received." By counting the number of Received lines in the message header, the MTA can determine how many "hops" the message took to get there. If the number of hops exceeds the maximum specified in this field, the server administrator receives an error report. The recommended range for this parameter is 30 or more.
Note
This error action can be customized with the Unknown Local Account field.
This field is used to determine when mail is delivered. Normally, when a message needs to be delivered to another machine over the Internet, the Messaging Server attempts to deliver it immediately and queues it only if there is a problem. Setting this option to Yes causes the Messaging Server to instead queue all outgoing mail and attempt delivery only when it processes the queue. The Messaging Server processes the queue on intervals that you indicate in the Queued Mail Processing Interval field of the System Configuration form. This feature is useful if your system has only intermittent access to the Internet.
This field is used to verify each recipient's address when accepting messages. When this option is set to Yes, the Messaging Server verifies each address listed as a recipient. Non-local addresses and addresses in mailing lists are not verified. The default setting for this option is No.
Mail can be routed to a machine other than the destination in the address using this optional field. This is done with a routing table. Normally rerouting is used only when a firewall prevents direct access to the destination mail server or when mail needs to be sent through a gateway to another network, such as a Unix to Unix Copy Protocol (UUCP) network.
The routing table is consulted only after the Messaging Server has determined--first through Channel Aliases, then an LDAP lookup, and finally NIS--that the address is not for a local mail account. The SMTP Mail Routing table is consulted before DNS/MX records.
The format for table entries is
An asterisk is used as a wildcard that will match any string of characters. In the example above all mail addressed to any machine or subdomain (because of the *) within the domain is routed to gateway.other_domain instead. The gateway then sends the mail to the machine indicated by the address. For example, to configure the Messaging Server to route mail to a UUCP gateway, you might use the following entry:
(You should, of course, substitute the actual address for your UUCP gateway in the place of uucp.gateway.host.)
Similarly, to route mail to a Fidonet gateway, you would use an entry similar to this:
*.fidonet:fidonet.gateway.host
You can set up a default route so that all mail goes to a single machine by using a single asterisk, as in this example:
Note
Use a default route only if it is absolutely necessary (as in a firewall situation) because it puts an additional burden on the mail hub machine and can slow it down.
*.example.com:*
example.com:hub.example.com
*:firewall.example.com
You can use these fields to specify what should be done with an undeliverable message. You select one or more options by clicking the button next to each item. Each of these error actions can assume appropriate combinations of the following values:
Inappropriate combinations, such as "log" by itself (which would log the error but delete the mail), should be avoided. You will probably always want to include a "return" entry or a "hold" and "notify" combination as part of your choices.
The Unknown Local Account error means that a message was addressed to a local domain but didn't correspond to an email account or channel. The bad address could be a typographical error, or it could be a sign that you should set up an alias for a local user at the "bad" address (because people seem to think it is a reasonable address). Unless you get a prohibitive volume of unknown local account errors, you should set this on "notify" and "hold," especially if you're upgrading from a different mail system. This setting lets you know about each error and lets you intervene by resubmitting the message, creating a new alias, returning the message to its sender, or throwing it away. Because many administrators prefer not to deal with bad addresses (because of the large volume they receive), the default is "return."
The Max Hops Exceeded error usually occurs because of a mail loop. Mail loops are fairly serious problems and need to be resolved as soon as possible. Accordingly, the strongly recommended setting for this error is "notify" and "hold" so that you can reconfigure the responsible account and resubmit the message to verify that the problem has been corrected.
The Disk Quota Exceeded error occurs when a message arrives for a user whose disk quota has been exceeded. For this situation you probably want to choose the "return" and "notify" settings.
The System Configuration form lets you
The following sections describe the fields on the System Configuration form.
When mail arrives for a recipient whose address doesn't contain a domain, the domain specified in this field is added to the recipient's address. If no domain is specified here, the hostname of the machine running the Messaging Server is assumed. For example, if this field is set to your domain name, mail addressed to <user> will be sent to <user@your.domain>.
In some cases there is an advantage to configuring the address completion domain to add your domain rather than your host address. When your system uses hostname hiding, a name@domain format will often fare better than a name@host.domain address completion.
Note
Some mail clients won't send mail that doesn't have a complete address. In this case, mail sent to <user> will not be deliverable, and users must be instructed to type the whole address for each message sent, even when it's local.
This field is a list of all the mail domains that this machine handles exclusively. If a domain is listed here and mail comes in with an address within that domain, the message is delivered locally to an account, referred to the server administrator, or returned to the sender (if no account is found for the recipient). If a domain isn't listed here, this machine isn't the primary mail handler for that domain. (However, it can still receive mail for addresses in the unlisted domain if an account is set up with an appropriate alias.)
This field helps determine when a message gets bounced. Specifically, if a server has this set and cannot resolve an address, it bounces the message.
Messages that can't be delivered immediately are placed in a message queue. The system attempts to deliver queued messages at regular intervals as specified here in seconds. Typical intervals are from 30 minutes (1,800 seconds) to two hours (7,200 seconds).
Messages that can't be delivered in a timely manner are eventually returned to the sender with an error message. Use this parameter to set the maximum amount of time that a message remains in the queue before it's returned. Internet standards recommend at least four or five days for this. The minimum is normally two or three days (to accommodate a problem that occurs over a weekend, or to provide ample time to fix the problem).
Enable this option (by choosing Yes) if you want to have the Messaging Server perform a name lookup (through the DNS) on all connecting client machines. If you enable this option, machines will be referred to by their domain names; otherwise they will be referred to by their Internet Protocol (IP) addresses. Places where these names show up include the process table, the log file, and "Received" lines in message headers. If you handle a large volume of messages, be aware that selecting this option will slow down the Messaging Server.
This default covers the number of SMTP, POP3, and finger processes that can run at one time. Specific processes are counted, not the total of all three. Because this is a default, it's used only if the defaults for those modules aren't specified. The recommended default is 20, which is enough for most systems. However, if you're doing something like serving many users with POP3 or IMAP4, you should set the maximum run count for the POP3/IMAP4 module higher.
This is the default for non-network processes such as the account handler. This default is applied only if a limit isn't specified in the configuration of a specific module. The recommended default is 5. If you need to assess the local processes and what they do, refer to Appendix A, "Messaging Server architecture".
This field allows you to specify the minimum free disk space required to allow the Messaging Server to accept messages. A "0" means unlimited. The Messaging Server rejects all messages received if not enough disk space is available.
This field allows you to specify a disk quota to apply to all users who do not have their own disk quota set. A "0" means unlimited. The Messaging Server rejects all messages received once the quota is reached and not enough disk space is available.
This field lists the recommended URL to gain access to the Messaging Server. The default entry is determined by information provided during installation.
This URL is provided to any mail client, such as Messenger 4.0 or greater, requesting it with a special POP/IMAP command. (With Messenger 4.0, the command is Edit|Manage Mail Account.) The URL is the location where end users can point their browsers in order to administer their mail accounts.
This form allows you to turn the single-copy message store feature on or off and to set the minimum message size.
If you turn on single-copy message store, 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 you turn single-copy message store off, messages will be delivered normally, with a copy stored in each recipient's mailbox. The advantage of turning single-copy message store off is better performance.
This field is set to "off" by default to favor performance.
The Minimum Message Size option is a performance-tuning parameter. Every operating system allocates a minimum number of bytes for a file (cluster size) regardless of the bytes in the file. (For example, it may allocate 2K bytes to store 2 bytes). If the minimum message size is small compared to the cluster size, space is wasted; if the minimum message size is large, then there is no single copy for all messages of smaller size, and again space is wasted. The optimal value can only be determined by a trade-off between the cluster size and the type of mail traffic at your server.
You will need to restart the Messaging Server for any changes to take effect.
This form is used to specify each directory on disk that contains a message store. The message store that a given user's mailbox is in is determined by the contents of the Messaging Server field in that user's Mail Information form. If a user's message store is different from the ones listed here, that user cannot have the Single Copy feature enabled. If a user's message store is left unspecified, the default message store is used.
Note:
If Single Copy is turned on, the default message store and all message stores listed on the form have single copy enabled.
Unix
This form is used to specify the interface to the Unix mail system and to select program delivery options.
The Local Mail Delivery Program field lets you specify the default Unix program used to deliver mail to any account that specifies Unix delivery in the Delivery Options field of the user's Mail User Information form. The default for this field is /bin/mail.
Program delivery options let you limit use of program delivery to the user and group specified in the Safe User ID and Safe Group ID fields for running root programs.
For the latest technical information on Sun-Netscape Alliance products, go to: http://developer.iplanet.com
For more Internet development resources, try Netscape TechSearch.
