Netscape Messaging Server Tuning Guide

Last update: 2002/05/09 

This Tuning Guide has the following sections: 

Platform Tuning Information
Solaris Tuning Tips

Software Requirements

Netscape Messaging Server on Solaris requires the following patches: 

  • 105568 /usr/lib/ patch 
  • 105210 libaio, libc & watchmalloc patch 
Sun provides patches from the web site

Tuning Parameters

Modify the TCP settings (in /etc/system): 

set tcp:tcp_conn_hash_size=262144
set maxusers=2048 

* set hard limit on file descriptors
set rlim_fd_max=1024 

* set soft limit on file descriptors
set rlim_fd_cur=1024

The following effects occur based on your setting of the maxusers parameter: 

  • max_nprocs = 10 + 16 * maxusers = ~32K
  • ufs_inode = max_nprocs + 16 + maxusers + 64 = ~34K
  • ncsize = max_nprocs + 16 + maxusers + 64 = ~34k
  • ndquot = (maxusers * NMOUNT)/4 + max_nprocs
  • maxuproc = max_nprocs - 5 = ~32K
Note: We recommend you do not change the above individual parameters (including NMOUNT), but instead allow the maxusers parameter setting to affect them in the noted manner. 

Bump up the Directory Name Lookup Cache (DNLC): 

set ncsize=300000

Bump up the inode cache: 

set ufs_ninode=300000 (suggested by Solaris support is 35000)

If you are using Veritas VxFS, check for the following values: 

    set vxio:inode 350000
    set vxio:vxfs_ninode 400000
A rule of thumb used for our benchmark testing was that the ncsize parameter would be 20% less than the vxio:vxfs_ninode or ufs_ninode values. 

For Veritas support you should visit their site:

The following should be at the top of /etc/rc2.d/S69inet

# TCP stack tuning for Netscape Messaging
# default is 7200000
ndd -set /dev/tcp tcp_keepalive_interval 30000
# default is 240000
ndd -set /dev/tcp tcp_close_wait_interval 15000
# default is 128
ndd -set /dev/tcp tcp_conn_req_max_q 1024
# default is 1024
ndd -set /dev/tcp tcp_conn_req_max_q0 1024
# default is 8192
ndd -set /dev/tcp tcp_xmit_hiwat 32768
# default is 8192
ndd -set /dev/tcp tcp_recv_hiwat 32768

Note: the hiwat settings above will use this much memory per connection, so be aware of the impact on your system. 

Also verify that the following parameters are set properly, if needed (in /etc/rc2.d/S69inet): 


You should also review whether the Solaris Priority Paging capability is right for you. This is discussed at

Solaris 2 Performance tuning is discussed in detail at

Solaris Network performance is discussed at and

HP-UX Tuning Tips

Hardware Requirements

Netscape Messaging Server can be run on any system running HP-UX 11.0 (PA-RISC1.1 or better). 

To determine what your box is, search for the model name in the /usr/sam/lib/mo/sched.models file. 

Software Requirements

Netscape Messaging Server on HP-UX requires: 

  • HP-UX 11.0 or later 
  • The following patches: 
    • PHCO_23651 (fsck_vxfs(1M) cumulative patch) 
    • PHCO_24645 (LVM commands cumulative patch) 
    • PHCO_26000 (libpthreads cumulative patch)
    • PHKL_25906(Data Page Fault when field vmtracing fix) 
    • PHKL_18543 (PM/VM/UFS/async/scsi/io/DMAPI/JFS/perf patch) 
    • PHKL_25775 (LVM Cumulative patch) 
    • PHKL_24027 (Correct VxFS process hangs) 
    • PHKL_22677 (Fixes a coherency corner case for mmap & I/O) 
    • PHNE_24413 (LAN product cumulative patch) 
    • PHNE_25116 (Cumulative STREAMS patch) 
    • PHNE_26771 (cumulative ARPA Transport patch) 
    HP provides patches from the web site
Tweaking Configurable Kernel Parameters

Certain kernel parameters may be tweaked to optimize performance. These kernel parameters are described in this section and they must be set manually; HP-UX system administration tools (sam, kmtune) will not allow numbers to be set this high. To set these parameters, edit the /stand/system file. After modifying this file, run the following command to build the new kernel: 

# mk_kernel -o /stand/vmunix

and then reboot the system. 

The parameters and the values to which they should be set are listed below: 
Parameter Description Value
max_thread_proc maximum threads per process 8192
nkthread maximum threads in the system 32768
maxdsiz maximum data segment size limit; heap memory Figure 100K per concurrent user session, depending on the size of their inbox. A good number is 1GB (0x040000000).
maxtsiz maximum text size 64MB (0x04000000)
maxfiles_lim maximum number of open files per process 32768
nfile maximum number of files system-wide 65536
ninode maximum number of inodes in memory 32768

These numbers should serve as a baseline for kernel tuning; they are slightly higher than the recommended numbers for safely using a 128MB C160 (workstation class machine). If you set the numbers too high, your system will exhaust lockable memory, and it will fail to start up properly (network tracing and logging daemons will be the first to complain, and X will not work). 

Note: For workstation class machines with only 128MB of memory, the maxfiles_lim, nfile, and ninode parameters should be helf the values listed above; they should be 16384, 32768, and 16384, respectively. It is unlikely that such a workstation could support the mail load that would require the high file values. 

Netscape Messaging Server requires many intra-process resources, but comparatively few global resources. For this reason, nproc, nusers, and other similar system-wide resources can be left low to free up memory for inode and thread structures. the exceptions to this rule are nkthread, nfile, and ninode, which also restrict per-process limits. 

Many of the ndd parameters listed in the Solaris Tuning Tips section would also be appropriate for HP-UX systems. HP-UX maintains a separate configuration file, /etc/rc.config.d/nddconf, to isolate ndd settings at system startup. The parameters tcp_keepalive_interval and tcp_conn_req_max (equivalent to tcp_conn_req_max_q) can be set as described. The xmit/recv values are already at those levels on an HP-UX system. 

Other HP/UX tuning parameters which may be useful to review include:

AIX Tuning Tips

Software Requirements

On AIX 4.3.2, you must acquire and install AIX patch PTF U463922 on the installation machine before installing the product. 

Without this patch, the extracting file messages are not displayed during installation. 

IBM provides patches from the web site

Tuning Parameters

For Messaging Server 4.0x, AIX requires that the minruncount tuning parameter service.smtp.mailbox-deliver.minruncount be set to 1. To do so, run the following command: 

# configutil -o service.smtp.mailbox-deliver.minruncount -v 1

AIX Tuning parameters are discussed in detail at the web site

Linux Tuning Tips

System Requirements

The system requirements for Linux are described below: 

  • System libraries need to be glibc-2.1.2 or later. 
  • The Korn shell (or pdksh) must be installed as /bin/ksh
For proper operation with a standard kernel, run Directory Server as a different user than the Messaging Server and adjust the service.{pop,imap,http}.maxthreads parameters so that no more than 256 threads will ever be started. For high volume installations, it may be necessary (or easier) to raise the system process limit. 

Avoiding Extra Disk Updates

By default, every time a file is read Linux writes the access time to disk. Netscape Messaging Server never uses this information. The partitions that hold the server, stores, and queues may be mounted with the noatime option to avoid these extra disk writes. 

Note: These partitions should not be shared with applications that need access time information (for example, tmpwatch). 

To make this change, edit your /etc/fstab file. Below is a sample entry: 

/dev/sda6 /nsmsg ext2 defaults,noatime 1 2 

Low Default File Descriptor Limits

Low system process file descriptor limits may limit the IMAP connection counts. Linux 2.2 with the appropriate patches can support many connections (64,000), but the system limit is often too low. 

RedHat 6.0 includes the patches to support 64,000 file descriptors per process. If you are an expert experimenting with non RedHat-kernels, apply the "Alan Cox" patches to get 64,000 file descriptors. 

Note: An unmodified Linux 2.2 is limited to 1,000 file descriptors per process. 

The following command raises the system file descriptor limit to 80,000: 

# echo 80000 > /proc/sys/fs/file-max && echo 80000 > /proc/sys/fs/inode-max 

Low Default Process Limits

A low system process limit of 256 per user may limit thread creation for the default server configurations. 

Note: Each Linux thread uses a process table entry just like a full process would. 

To change this, edit /usr/src/linux/include/linux/tasks.h and change NR_TASKS to 1024 or more and MAX_TASKS_PER_USER to be (NR_TASKS-256)

#define NR_TASKS 1024

Rebuild the kernel for these changes to take effect. 

Not all the Memory is Used

By default, Linux only uses 1Gb of memory, even if more is available. A portion of that 1Gb is set aside, so only 960Mb is available. 

Messaging performance may be enhanced using 2Gb of memory. 

Note: Some modules (for example, boot ramdisk) may not work with the larger memory limit. 

If you do not specify a 2Gb limit when you configure the kernel, you can edit the following two files are described below: 

  • Edit /usr/src/linux/include/asm-i386/page.h and change __PAGE_OFFSET to 0x80000000

  • #define __PAGE_OFFSET (0x80000000)

  • Edit /usr/src/linux/arch/i386/ and change the 0xC0000000 to 0x80000000

  • . = 0x80000000 + 0x100000;

After editing these files, rebuild the kernel for the changes to take effect. 

Tru64 Unix 4.0d, 4.0e and 4.0f Tuning Tips

Software Requirements

Additional tuning information can be found at the Compaq Tru64 Unix web site:

Tuning Parameters

For Tru64 Unix 4.0d and later, the following parameters should be updated in /etc/sysconfigtab


Windows NT 4.x

Software Requirements

For Windows NT, you must have Windows NT 4.0 Service Pack 4 or later installed to run and install the Messaging Server 4.15 or later. 

MTA Tuning Information
Configuration Parameters

Configuration parameters for the MTA are described below: 

  • service.smtp.smtp-accept.minruncount 

  • This limits the number of SMTP sessions being serviced at any one time. Like the other services, when the server is busy it will accept the TCP connection but nothing happens until resources are free. Unlike POP/IMAP, the 4.0x SMTP daemon cannot share X worker threads among more than the same number of X active sessions; it uses one thread per session. This behavior is changed in 4.1x, which shares these threads among multiple SMTP sessions. 

    Even in 4.1x, the SMTP daemon still does not have a maxsessions parameter; it will plex these threads among as many SMTP sessions as it can. 

    The default for this parameter is 32. For 4.0x, this parameter directly controls the number of active SMTP sessions that can be serviced at one time and that can be safely tuned up to several hundred threads. With the new SMTP thread model in 4.1x, this parameter should be left alone in most cases.

  • service.smtp.account-handler.minruncount

  • service.smtp.smtp-router.minruncount

    The semantics of these parameters are similar to service.smtp.smtp-accept.minruncount but apply to their respective SMTP daemon modules. In most cases, the default values are fine. When increasing the value of any of these parameters, you should exercise the same care as in selecting reasonable values for IMAP/POP/HTTP servers (see the Protocol Tuning Information section). For example, multiplying all the defaults by 10 would not be resonable, but doubling the number of program-deliver threads on a machine that runs a program delivery mail list manager should be fine.

  • service.smtp.smtp-accept.log

  • service.smtp.account-handler.log

    These parameters turn on or off the logging for each MTA module. The following parameters default to on (yes) if not set: 

    The following parameters default to off (no) if not set: 
  • service.smtp.domainlangtable 

  • This parameter should be changed from its 4.01 default value. A bug was uncovered in certain versions of our internationalization libraries that leaves the SMTP daemon vulnerable to core dumps when certain foreign language messages are sent to the server. Changing this value does not wholly eliminate the problem, but it reduces the number of cases in which this problem could occur. 

    Our recommended value specifies a language table that only includes languages for which Netscape has resource bundles: 

    • fr
    • fr$de
    • de$es
    • es$jp
    • ja
    This problem is fixed in version 4.15. 

    The meaning of this parameter is that each line in service.smtp.domainlangtable consists of: 

    • country/domain   language-list 

    • country/domain is either a country 'ending' (e.g. us=USA, be=Belgium,... or for a Netscape group based in Japan). In this way you can set language defaults for a whole country or even a particular domain in a country (e.g. if everyone in spoke English, replies to it would override the Japanese language default for the country). 

      language-list is an ordered list of languages separated by commas or pipes (|). Currently the ,'s and |'s have the exact same meaning. (We were intending to have the |'s be used when you want to display more than one language (e.g. for a reply to Canada send both English and French), but that never go into the product.) To make your life simpler, it's probably best to just use commas everywhere until functionality changes. 

      The meaning of a line like: 

        be fr-BE|nl-BE,fr|nl
      would be (if |'s were handled): 
        For mail from the domain of Belgium, send a reply in both Belgian-French and Belgian-Dutch (=Flemish?). If neither of those are available, then send reply in both French and Dutch. 
      Since |'s are not handled, this is actually equivalant to: 
        be fr-BE, nl-BE, fr, nl
      which means: 
        Send reply to Belgians in (first available language of): Belgian-French, Belgian-Dutch, French, Dutch. (If none of the above are available then the universal default is English). 
  • service.smtp.smtp-router.smtprewritestyle 

  • This parameter controls how the MTA rewrites some of the RFC822 message header fields. Doing header rewrites slows SMTP down a bit. 

    The From:, To: and CC: lines are rewritten. The overhead is an additional LDAP lookup on the From: address. The To: and CC: addresses should already be cached and no additional lookup is required. 

    The default value for this parameter is quoted. A value of never turns the header rewriting off. 

  • service.smtp.ldappoolsize 

  • LDAP connections are pooled in the Messaging Server 4.x. The pool of LDAP resources is shared among all the threads of a given messaging server process. These connections are not shared across separate processes. 

    This parameter controls not only the size of the SMTP LDAP pool, but also specifies the default size of the LDAP pool used by other messaging server processes. Since there is no way to change the LDAP pool size for other processes, this effectively sets the pool size for all messaging server processes. The default for this parameter is 32, which should be adequate in most cases. 

    Decreasing the value of this parameter may actually help performance in some situations, particularly if you have many IMAP/POP/HTTP daemons since you will be swapping LDAP with too many total connections. However, care should be taken when dropping this number to avoid introducing contention for the LDAP connection among the other working threads. Dropping this value below 8 in most cases is not recommended. Increasing this value by a large amount is usually just a waste of resources.

  • service.smtp.smtp-accept.maxmessagesize 

  • This parameter is coded to work only if the SIZE extension in service.smtp.smtp-accept.allowsize has been turned on by the administrator.

  • service.smtp.smtp-deliver.timeoutgreet 

  • This parameter is the timeout in seconds when waiting for a response when the local MTA contacts a remote MTA.

  • service.smtp.*.maxruncount 

  • None of the maxruncount options are used.

  • local.service.smtp.smtp-router.addresentfrom 

  • In Messaging Server 4.15 Patch 1, this parameter is now available to suppress the addition of the Resent-From: header on list expansion. Setting the parameter to no prevents the header from being added. Setting it to yes adds Resent-From: on list expansion. 

    By default, this value is not set; and works as if set to yes.

  • service.smtp.smtp-router.dorewritefromusingauth

  • service.smtp.smtp-router.dorewritesenderusingauth

    These parameters will rewrite the From: and Sender: headers with the information from the authentication session.

  • service.smtp.smtp-accept.timeoutcommand

  • service.smtp.smtp-accept.timeoutdata

    These parameters help make sure that connections that are not used and not closed get closed after a certain amount of time. 

    By default, these parameters are set to 600 seconds (10 minutes). If users are sending large attachments over slow dialup lines, you may need to modify these to avoid connections waiting for threads. 

  • service.smtp.prog-deliver.defaultuid

  • service.smtp.prog-deliver.defaultgid

    This is the user and group IDs used for program delivery. By default these values are 1, which often corresponds to the daemon use and other group in your local /etc/passwd file.

  • service.smtp.error-handler.hopcountexceedactions

  • service.smtp.error-handler.quotaexceedactions

    These parameters describe the error handling when the MTA hop count is exceeded, quota is exceeded, or something unknown happens. These values are numeric sums of the following actions: 

    • 1     Reply to Sender
    • 2     Hold (not used in 4.x)
    • 4     Notify Postmaster
    • 8     Log
    So that if you define the value 14 as service.smtp.error-handler.hopcountexceedactions, it will treat a hop count exceeded as Hold (not used in 4.x), Notify Postmaster, and Log
  • service.smtp.smtp-deliver.checkdeferredqueue 

  • When set to yes, this parameter instructs the MTA to determine if there are messages in the queue waiting to be sent to a particular domain. If so, new messages to the domain are also queued, awaiting the next attempt to connect and send.

Throttling SMTP Accepts

Messaging Server 4.x provides two additional ways to stop denial of service attacks along with plugins and filters: 

  • Any one connection cannot send more than 1000 mail messages 
  • Once the control queue is over 2000 messages, the server starts to throttle back the speed with which it accepts incoming connections. 
These mechanisms make it more difficult to grow the queue to massive proportions. 

To throttle SMTP accepts, configure the following parameters: 

  • local.service.smtp.smtp-accept.maxrecipients 

  • Netscape Messaging Server 4.04 and later allows the administrator to tune the maximum number of recipients of a message. Care should be taken to modify this values because ISPs and other systems receiving mailing lists may need to accept a large number of recipients in each mail. 

    The default value is 100000

  • local.service.smtp.smtp-accept.maxmessages 

  • This is the maximum number of messages per SMTP session; the default value is 1000

You may also modify the queue throttle value: 
  • local.service.smtp.throttlethreshold 

  • Messaging 4.05 Patch 1, 4.1 Patch 2 and 4.15 Patch 1 allow the administrator to tune the level at which the throttling occurs. Care must be taken because if the throttle level is set too high, the accept rate will overwhelm the ability over the server to deliver all the messages it accepts. 

    There is no parameter default value; the internal value is 2000

Configuring the Postmaster

The MTA will fail to start if it doesn't find a postmaster account, nor will it start if it finds more than one postmaster account. More information is available from

Routing Multiple Recipients

The SMTP routing is done after the envelope of the message has been split on recipient domains. This means that if you route all mail with one routing rule in a routing table: 

and send a message to user1@mydomain and userX@yourdomain, then the server sends two messages to smtp.otherdomain: one for user1 and one for userX

This is probably not efficient if you have a hub or router machine that handles all outgoing mail. 

Caching LDAP Queries

Each time an LDAP query is made (on message senders and recipients), the entry info is kept; it is 'tagged' by the search that retrieved the entry (could be either recipient address or UID). This information is kept in memory, roughly tracking the Control information for the message (stored separately, but linked) and removed when the message is delivered or dropped. 

Theoretically, this keeps us to one LDAP entry per recipient per message; and most of the time this is the way it works out. 

Note: The LDAP information between messages is not cached; it is assumed that there is little chance of random messages containing the same recipients. 

DNS Caching

For performance reasons, the MTA caches DNS entries. The following describes the impact and process of the caching. 

  • The MTA randomizes MX hosts at the same preference. If an MX host at a higher preference goes down it gets removed from the cached list and it re-enters the cache only when the domain gets looked up again; that happens when TTL for that domain is up.
  • The code which does MX lookup always tries the nameservers in the order in resolv.conf. It does not remember if the first nameserver timed out from last time.
  • If there is no MX record for the host and we lookup the A record for that domain, then the behavior is to try the servers listed in resolv.conf in order. If no response is received from a server, it's demoted (placed last in an internal list constructed from the list in resolv.conf). A server cannot be promoted except by having its superiors demoted, which means a demotion is permanent unless the MTA is refreshed (the MTA doesn't yet support this in 4.x), or the secondary (or tertiary) server stops responding.
More DNS information can be found at:

Turning DNS Caching off

Starting with Messaging Server 4.1 Patch 2 and 4.15 Patch 1, DNS caching by the MTA can be turned off if you wish to have more control over the DNS behavior. 

The following configuration setting will turn off DNS caching in the MTA: 

    configutil -o service.smtp.dnscachesize -v -1
A message will appear in the smtp log stating that DNS caching has been disabled: 
    [28/Feb/2000:10:00:00 -0800] system smtpd[10000]: General Notice: DNS cache is disabled
MTA Relays

Customer experience shows that the following should improve performance on outbound SMTP servers. They usually build up to large SMTP Deliver queues causing the server to stop accepting incoming connections. Specifically, the lower setting for smtp-deliver.timeoutgreet and higher setting for smtp-deliver.minruncount are important. 

    configutil -o service.http.enable -v no 
    configutil -o service.imap.enable -v no 
    configutil -o service.pop.enable -v no 
    configutil -o service.ldapmemcache -v no 
    configutil -o service.smtp.smtp-deliver.minruncount -v 130 
    configutil -o service.smtp.smtp-accept.minruncount -v 140 
    configutil -o service.smtp.smtp-router.minruncount -v 50 
    configutil -o service.smtp.smtp-deliver.timeoutgreet -v 30 
    configutil -o service.smtp.account-handler.minruncount -v 40 
    configutil -o service.smtp.error-handler.minruncount -v 3 
    configutil -o service.smtp.mailbox-deliver.minruncount -v 1 
    configutil -o service.smtp.unix-deliver.minruncount -v 1 
    configutil -o service.smtp.prog-deliver.minruncount -v 1 
    configutil -o service.smtp.autoreply-handler.minruncount -v 1 
    setconf local.dbtxnsync 1 
You may also want to tune the following based on the expected output usage: 
    setconf local.service.smtp.smtp-accept.maxrecipients 250 
MTA Fallback Host

Starting with Messaging Server 4.15 Patch 1, you can create a fallback host ("host of last resort") so that if you timeout connections on all of the remote MTAs, you can route messages to a fallback MTA; for example a local MTA that acts as an offline deferred queue. 

The following configuration setting will enable a fallback host for the MTA: 

    service.smtp.smtp-deliver.fallbackhosts is a $ separated list of x:y where x is a pseudo regular expression specifying domain and y is a host (name or IP address). If y has multiple IP addresses, they'll all be tried. The y IP addresses are treated as if they are the lowest priority MXs by the nameserver. 

    If the real MXs for the domain are all dead, these pseudo-MX IP addresses will float to the top and stay there for the duration of TTL (typically). 

    Trivial case of *:<host> forwards all deferred mail to <host>

Turning off LDAP lookups

Beginning with Messaging Server 4.15 Patch 1, the ability to turn off LDAP lookups for outbound-only relays is available through the following configuration parameter: 

    service.smtp.smtp-router.remotemaildomains is a space-separated list of pseudo regular expressions. 

    For example: 

      * will make the server treat <everything> as remote and not do an ldap lookup on that. 

      * will make everything remote. 

    More complex expressions are also possible: 
      (!* && !*
    then the address is remote, and so on. 
Queueing Behavior

In Messaging Server 4.1, the queue handling is designed using a structure based on a directory containing control files and auxiliary directories containing the body of the messages. 

The idea is to use status attributes in the control files holding information about: 

  • last time a message attempt was made for delivery
  • sender
  • recipient
  • sender mailhost
  • remote mail server
  • ... and so on ...
Thus, an envelope is a holder of control information, which allow us to track the messages on their way out to the remote system. 

The queue reporting tool, mailq, performs a count of the number of envelope files in the control directory for a deferred domain and displays that information to the user. 

Differences between 4.0x and 4.1x Queueing Behavior

The organization of the deferred directory for SMTP delivery has been changed between 4.0x and 4.1x. Multi-level hash directories have been employed to fan-out domains and message files under queue/deferred/SMTP-Deliver. The hash directories are two levels deep, and is computed for domainname and also for the message files. The hashdir utility can be used to find the hash values. 

The deferred queue for the domain in 4.0 was queue/deferred/SMTP-Deliver/ The 4.1 deferred queue is queue/deferred/SMTP-Deliver/xx/yy/, where xx and yy is the hash value computed over

Additionally, in 4.0x when a message was deferred the message file was left in the /messages directory, and only the envelope file was moved to the deferred directory. In 4.1, the message file is now also moved to deferred directory. Ie. queue/deferred/SMTP-Deliver/xx/yy/, where XXXXXXXX.XXX is the message file. 

This was changed to minimize the number of files in the messages directory. 

Queue Processing when the MTA is Started

On start up, the MTA will attempt a sanity check between contents of the files in the queue/control/env-XXX and the files under queue/messages

In 4.0x, since we're leaving the message files for deferred messages in the queue/messages directory, a situation could arise where one ended up with many tens of thousands of files in the queue/messages directory (say if a site like is down). This considerably slows down the checking performed by the server at start up. To prevent this situation from occurring the deferred messages are no longer kept in the queue/messages directory. 

In 4.1x, since we move deferred message files to their own directory under queue/deferred/SMTP-Deliver, and also since the default throttle limit for the server is 2000, we should rarely, if ever, end up with a situation where there are 20,000 message files in the messages directory. 

It is conceivable that this processing could be done in the background, but this is not the way 4.x has been architected. Also it is questionable to start the MTA without doing a sanity check first. 

Note: The deferred queue is not processed on start up. 

Mail Headers

If a message is received with only one (envelope) recipient, then the MTA will put the recipient address into the Received: header. For multiple recipients, it adds no extra information. 

For example, the following is what you may see for a single recipient: 

      Received: from yourdomain (yourmailserver.yourdomain [XXX.YYY.ZZ.AA]) 
                by anotherserver.yourdomain (Netscape Messaging Server X.Y) 
                with ESMTP id AAA5555 for <user1@testenv.yourdomain>; 
                Fri, 14 Jan 2000 15:00:00 -0700 
while for multiple recipients, you would see: 
      Received: from yourdomain (yourmailserver.yourdomain [XXX.YYY.ZZ.AA]) 
                by anotherserver.yourdomain (Netscape Messaging Server X.Y) 
                with ESMTP id AAA5555; Fri, 14 Jan 2000 15:00:00 -0700 
Language criteria for Replies

The Messaging Server uses the following criteria for determining the language of replies: 

  1. Does message have a Prefer-Language: or X-Accept-Language: header (the later is used by Communicator 4.x I believe). If so, try to use the language specified in that header.
  2. Is recipient in our Directory, and if so do they have a preferredLanguage attribute.
  3. What is the domain of the sender? (e.g. is by domain definition Korean, so we'd use Korean in the reply). This is editable (see service.smtp.domainlangtable) so you can specify desired languages for countries and even individual domains.
  4. If none of the above 'click' then we fall back to English.
sendmail utility

The sendmail utility is a fixed command located at /usr/lib/sendmail which is part of the Messaging Server. Since multiple instances of the Messaging Server can be installed, but only one of /usr/lib/sendmail, this causes issues with which sendmail utility to use. 

Starting with Messaging Server 4.05 Patch 1, 4.1 Patch 2 and 4.15 Patch 1, the following configuration parameters are now available for use by the sendmail utility: 


The sendmail utility now does the following when looking up its listen address and port number: 

  1. looks for the local.service.sendmail.port config value
  2. if not set, looks for service.smtp.port config value
  3. if not set, looks for the smtp/tcp service port number
  4. if not set, uses 25
  5. looks for the local.service.sendmail.listenaddr config value
  6. if not set, looks for the service.listenaddr config value
  7. if not set, uses localhost
Thus with multiple instances of the Messaging Server, different listen addresses and ports can be specified each time sendmail is run. 
Protocol Tuning Information
Configuration Parameters

Configuration parameters for protocol tuning are described below: 

  • service.ldapmemcachesize
  • service.ldapmemcachettl

  • These parameters are related to the LDAP chaching done at the LDAP SDK level. This cache is not used in Messaging Server 4.x. There is another related parameter, service.ldapmemcache, that controls the operation of this cache; its default value is no. This should be left off under all circumstances. It is unstable in the 4.x servers and has been seen to slow down the server. 

    Because of the problems with this layer of LDAP caching, we have implemented LDAP caching at the mail server application level. There are not that many direct controls into this cache; in particular, what gets cached by the SMTP daemon. 

  • service.pop.maxthreads 
  • service.imap.maxthreads 
  • service.http.maxthreads 

  • These parameters control the number of threads dedicated to the respective services. Up to the specified number of threads are shared among all active sessions for better than one thread per session utilization. 

    The default values for these parameters was 1,000 in Messaging Server 4.0 and 4.01. This was determined to be too high and was reduced to 250 in versions 4.03 and later. This parameter should be less than 500 under normal conditions to avoid practical problems with thread scheduling and resource contention within a process. If more threads are required, see the numprocesses parameters below. 

    For Linux, the value of these parameters should be set to 50 to better work with the default process table size. 

    Note: This does not affect the maximum number of concurrent connections that the servers can sustain. 

  • service.pop.numprocesses
  • service.imap.numprocesses
  • service.http.numprocesses

  • More than one popd, imapd, or mshttpd can be configured to service the incoming load on a messaging server, but there can only be one smtpd process per server at this time. When more than one process is used, the load is randomly split between the processes by OS scheduling mechanisms. 

    The default value for these parameters is 1, which should be fine for small to mid-sized servers. This number can be increased on large servers to take advantage of multiple CPUs in a more efficient manner than can be achieved by increasing the number of threads to a very large number. 

    The increasing the number of processes, you should bear in mind that LDAP pools and authentication caches are not shared across processes. Also, when increasing the number of processes, 1-2 processes per CPU is a practical rule-of-thumb upper limit. Beyond that, the server may thrash under load as processes are thrashed in and out of CPU instruction and data caches. Other servers (such as LDAP servers) that may be running on the mail server should be taken into account when choosing values for these parameters. 

    The value for this parameter should not exceed the number of processors on your hardware. 

  • service.pop.maxsessions
  • service.imap.maxsessions
  • service.http.maxsessions

  • These parameters control the maximum number of sessions that will be serviced by the maxthreads worker threads in each of the numprocesses processes for each respective service. Connections that come in above this limit must wait for a slot to be freed up by one of the active sessions. Until then, the new connection will not even get a banner even though the TCP connection has been established. 

    The value for maxsessions can be greater than the number of threads. The 4.x server uses a worker thread dispatcher rather than a thread-per-connection model. This differs from 3.x servers which used one thread in one process per session. And in 4.1x, the server allocates threads only to handle each command, so there's a very efficient use of resources. 

    The default values are 600 for POP and 400 for IMAP and HTTP. 

  • service.pop.idletimeout
  • service.imap.idletimeout
  • service.http.idletimeout

  • These parameters control how long a session is permitted to remain idle before it is terminated by the server. The value is specified in minutes. The minimum (and default) is 10 minutes for POP, and 30 minutes for IMAP and HTTP. These values may be increased, but not decreased. 

Protocol Tracing


Messaging Server 4.x supports telemetry gathering for the POP, IMAP and HTTP protocols. This tracing involves creating a log file with all protocol commands both sent and received by the server. 

Telemetry gathering is done on a user-by-user basis, so create a subdirectory (e.g. log/pop/telemetry/userid) with the appropriate permissions, and a new file will be created there for each connection listing the commands for that session. 


Most operating systems support tracing the protocol on a particular socket or port. On Solaris, this is done using the snoop command. 

For example, to trace a POP connection, you might use the command: 

      snoop -x 56 port pop3
Read the man pages for these commands before use for details. 

IMAP Memory Footprint

Messaging Server 4.1 and later supports thousands of connections per process (the default is only one imapd process). 

To be conservative, expect 100K per connection, but in reality this is more like 50K (without SSL). 

nsmsgDisallowAccess Attribute

The nsmsgDisallowAccess LDAP attribute exists for each user and specifies which type of access is not allowed for each user. Set this attribute to pop, imap, smtp, or http as necessary to disallow that type of access for the user. 

Specifying Domains

The service.smtp.domain parameter specifies the domain on which this server runs; it is set during installation. The service.smtp.defaultdomain parameter specifies the domain that users are expected to have if none other is specified; this parameter is set through the Console. 

For example, suppose you have a server inside of Netscape that handles mail for customers exclusively; it is called Thus, service.smtp.domain will be but service.smtp.defaultdomain will be 

Specifying Local Domains

Though the ability exists (now that the 2KB limit on entries through the configutil utility has been fixed) to add many thousands of entries to the service.smtp.smtp-router.localmaildomains for a single server, it's not recommended to add more than a couple of hundred localmaildomains. Customers who have multiple thousands of localmaildomains specified may run into performance problems with SMTP routing. 


When setting the quota for a user, the quota of the user's mailbox only gets updated on the next incoming message to the mailbox. 

You can specify unlimited quota using the IMAP protocol command: 

  tag SETQUOTA "user/whatever" ()

Aging Rules and Policies

Aging rules can be written on a per-user basis because it's available through pattern matching. For example, you can match on /user/bob/* to match all of bob's folders. This will impact performance with a large number of wildcard matches, however. 

Also, there is no current method to build aging policies so that you can specify 100 messages in all of bob's folders. For example, you cannot have the policies activate at a 100 message limit if there are 100 messages in bob's Inbox and 0 messages in bob's Work folder, as well as activate with 50 messages in bob's Inbox and 50 messages in bob's Work folder. 


When setting the service.listenaddr parameter for specifying the address which services should listen to, the parameter can be in both hostname or IP formats. Whether the interface is virtual or physical doesn't matter. 

Messenger Express (WebMail) Tuning Information
Configuration Parameters

Configuration parameters for Messenger Express (WebMail) are described below: 

  • service.http.ipsecurity 

  • This parameter specifies whether to enable IP address checking of the session ID used for security of the Messenger Express client for communicating with the mshttpd daemon of the server. 

    If you have a reverse proxy requirement, where the clients will not be connecting directly with the daemon, you will probably need to disable (set to no) this parameter. Note: disabling this parameter will not restrict the session ID available to the authenticating IP address. 

LDAP attributes for WebMail

There are several LDAP attributes used by WebMail. Some of these are defined here: 

  • nswmextendeduserprefs meDraftFolder=Drafts specifies Where to save draft messages (e.g. Drafts). 
  • nswmextendeduserprefs meAutoSign=true specifies to add your signature to sent messages.
  • nswmextendeduserprefs meSignature specifies your signature. 
  • nswmextendeduserprefs vCard specifies your vCard.
  • nswmextendeduserprefs meSentFolder=Sent specifies where to put your sent mail (e.g. Sent).
  • nswmextendeduserprefs meExpungeOnExit=true specifies to expunge your deleted messages on Exit.
  • nswmextendeduserprefs meViewSize=100 specifies the number (e.g. 100) of entries to view in a single pane.
WebMail use of LDAP Language Extension

WebMail uses the LDAP language extension. This is the only way in which it can let the MTA know which language to use for auto-reply messages, for applying the appropriate MIME encoding for header and body. 

More information about the LDAP language extension can be found at:

Security Tuning Information
Configuration Parameters

Configuration parameters for security are described below: 

  • service.authcachettl 

  • This parameter specifies the amount of time that the entries kept in the authentication cache may live. This value is specified in seconds. 

    The default value is 900 seconds, which is on the short side. With the average POP client performing POP checks every 10 minutes, this value would result in an LDAP search being done for every other POP check. Typically, values on the order of a few days are recommended for ISPs. 

    The authentication cache is not persistent across server restarts, and it is not shared between different processes. 

    The value of the authentication cache is reduced if proxyauth is used for final user login to the mail store machines as may be the case in some Multiplexor configurations.

  • service.authcachesize 

  • This parameter specifies the number of entries in the authentication cache used by the POP, IMAP, and HTTP servers. Its value should be greater than or equal to the number of users who have their mailbox on the machine to avoid pushing entries out of the cache before the TTLs expire. 

    The default value is 10,000 entries, which is fine for servers with user populations smaller than 10,000 users.

  • local.tmpdir 

  • This parameter specifies the SSL session cache and as a default for the http outgoing message spool directory. 

    Data stored here is necessarily temporary; state is not kept over server restarts.

Enforcing Authenticated SMTP withing Domains

Authenticated SMTP can be enforced within specified domains by using the service.smtp.authmaildomain parameter. This is a space-separated list of entries and can only be set by IP address. (Domain names are either spoofable, or take too long to look up in DNS.) 

Partial IP addresses are implicitly "asterisked," and exceptions can also be entered by starting with a !. If finer tuning is needed, a bit mask can be entered after the restricted IP (separated by a tab). 

For example: 

202.11. will require any IP address 202.11.x.x to AUTH before sending mail (NOTE: the trailing . is needed on 1 or 2 digit octets, otherwise 202.111.x.x will match, which is probably not what is wanted.) 

202.11. ! will allow to connect without AUTH even though it's in the above domain. 

You may also specify a mask, for example: 

202.11.170.<tab> will restrict logins from (hex) CA.11.Fx.xx to be authenticated. 

Specifying Mailbox Access Domains

    Starting with 4.15, the LDAP attribute mailAccessDomain supports multiple filters in a single attribute, separated by $, with either + or - denoting their disposition. 

    The mailAccessDomain filter syntax is: 

      [+-] servicelist : clientlist ( $ [+-] servicelist : clientlist )*
    The following example will make it so that the user can only access imap and imapmmp (no ssl). 
      +imap imapmmp:ALL$-pop popmmp:ALL
    Or, to allow a POP client to connect to the MMP, and the MMP to connect to the store, you can use:$
    if is the client and is the MMP. 

    Or, to restrict the MMP to a SUBNET/IP range, but leave the store open, if it's behind a secure lan: 

Mailbox Check for New Mails

If you do not know a user's password, it is possible to authenticate against the message store so that you can select a mailbox to check for new messages. To do so: 

  1. Login as a proxy user: 

  2. LOGIN <proxyuser> <password>

  3. Issue a proxyauth command to become that user: 

  4. PROXYAUTH <user>

  5. Select the mailbox (for example, INBOX): 


Authentication SDK

The Authentication SDK is discussed in the Plugin section. 

Store Tuning Information
Configuration Parameters

Configuration parameters for the store are described below: 

  • store.dbcachesize store.dbtmpdir 

  • These parameters control the database caches used for the mboxlist of the message store. The cachesize is specified in bytes, and should be large enough to hold the entire database. The DB cache files are the ___* files located in the mboxlist directory. 

    The dbtmpdir parameter controls where these cache files are placed, and should be placed on a RAM backed file system on operating systems that support this feature (for example, /tmp/msg_dbtmpdir on Solaris). Note: this is unlikely to greatly improve performance for running the reconstruct utility.

    The performance gain for store.dbtmpdir will only be felt if you have greater than 100,000 users, a correspondingly large data.db2 file (say greater than 50MB) and you've started to increase store.dbcachesize to compensate (say something greater than 100MB). This is exactly the same mechanism used in directory for storing the cache on a tmpfs to avoid excessive and unnecessary page-outs of data that is inherently volatile and deletable. 

    To know if you need this, look for high wait-times and lots of write io's on your disk volume containing mboxlist.


  • The proper setting for this parameter is outlined in the 4.04 and later release notes. This parameter controls the frequency in which the thread responsible for database deadlock detection should look for problems. The value of this parameter is the number of microseconds between deadlock checks. 

    This parameter is not applicable for the 4.01 server, as it was added to 4.03 and later patches to correct problems in the 4.0 and 4.01 servers. The default value is 1000. For large machines, this value should be set between 100-200. For small boxes, this value should be left at 1000 or even increased.

  • store.expirestart 

  • This parameter specifies the hour at which deleted messages should be expired from the store. 

    The 4.x mail store does not unlink message files as soon as they have been deleted via IMAP expunge or POP delete. Instead, the server keeps track of all the messages that have been placed in a deleted state and unlinks the files at the specified hour. This was done to improve performance during peak server usage since unlink() is a potentially slow action executed in filesystem (kernel) space. 

    For IMAP servers, this expire run normally deletes a relatively small percentage of the messages in the mail store. 

    On a POP server, this nightly expire run can potentially delete a very large percentage of the messages in the mail store since POP is a download-and-delete protocol. This can translate to several hours of intensive filesystem activity during the expire run, so care should be taken when selecting a value for the parameter to avoid loading the system during peak usage hours. 

    The default value is 23, which specifies that the expire run should occur during the 11:00pm hour. Finer specification beyond specifying what hours to run is not possible. 

    The default value of 23 is appropriate for enterprise deployments where the server sees very little usage at night. For an ISP, an off hour such as 03 (3:00am) may be more appropriate.

  • store.cleanupage 

  • This parameter defines the age in hours (default is 1) of an expunged message, after which the stored utility will remove the message.

Synchronization of Message Writes

Starting with NMS 4.03, and included in the 4.1x and later releases, the Messaging Server writes all messages in fdatasync() mode. 

This includes messages in the queue, envelope log information, messages written to the store, and metadata within the store, including indices, cache, etc. 

Using the following configuration parameters, it can be modified to either using the fsync() mode or no syncing at all (allowing filesystem syncs to handle all issues): 

    This parameter will turn off calling the fdatasync() routine that causes transactions to be synchronized to disk everytime a transaction occurs and allow the filesystem/drive array to schedule the syncs itself. 

    These parameters can be set to a value of 0, 1, or 2

    While local.dbtxnsync applies to all database transactions, the* parameters apply to the store indices and values. 

    If set to 0, all writes related to file descriptors used by the store are sync'd according to the OS and filesystem. 

    If set to 1 (the default), all writes related to file descriptors use the fdatasync() command, which forces all currently queued I/O operations associated with the file descriptor to synchronized I/O data integrity completion. 

    If set to 2, an fsync() moves all modified data and attributes associated with the file descriptor to a storage device guaranteeing that all in-memory modified copies of buffers associated with the file descriptor have been written to disk. 

    Note: If is set, then by default (unless specifically overwritten), the other*synclevel parameters will use that value. 

    These parameters can be set to a value of 0, 1, or 2, as noted above. 

    While local.dbtxnsync and* apply to all database and store transactions, respectively, the envelopesynclevel and messagesynclevel apply only to the MTA. 

With a higher synchronization level, you will have worse performance, but if data integrity is the most important issue, then turning up the synchronization level may be what you want. 

(Please review your system's man pages for more information on what fdatasync() and fsync() mean.) 

Single Copy Message Store

Unlike Single Copy Message Store (SCMS) capabilities in NMS 3.x, the NMS 4.x has SCMS that works and cannot be turned off. 

It is implemented as hard links on both Unix and NT, and can be archived using normal filesystem utilities. The reference count is kept by the filesystem, not the Messaging Server. The message size is counted towards the quota of each mailbox that contains a link to the message file. 

reconstruct and Message Store Maintenance

reconstruct is a utility used to rebuild data in the message store. The message store consists of a master mailbox list (mboxlist) and individual user folders and messages. Each entry in the mboxlist corresponds to a folder in the specific user area. 

reconstruct as well as reconstruct -r is used to rebuild the individual user folders in case they become corrupted or inconsistant. (The -r option specifies a recursive reconstruct on user folders.) 

Damaged user folders are usually detected from errors in logs, as well as actual user reports and complaints. 


    Joe1 reports that he can not access his messages in his INBOX. The system otherwise appears to be working properly. Therefore the admin would assume the folder has become inconsistant and run the following: 

      reconstruct user/joe1/INBOX
    Assume a site has experienced massive hardware failure, and the integrity of the entire system is in question. After addressing the other issues, if an admin has reason to believe many user folders may be damaged, they could reconstruct all folders by executing the command: 
      reconstruct -r
reconstruct -m and the master mailbox list

reconstruct -m is used to rebuild the master mailbox list (mboxlist). 

The mboxlist is protected by a logging database, and is thus difficult to corrupt. After a mail server crash or system crash, the mail server will automatically attempt to recover itself. During this recovery period, you may get a warning message that the message store has not come up in the expected time period. If stored is running, it is likely still in the recovery process. If stored is not running, you should check the stored log file as specified by the warning message. 

Do not try to restart the store daemon. 

Most likely the recovery process will succeed and the store will come up. If it does not, the log files will indicate you need to run reconstruct -m

In order to run reconstruct -m in this particular situation (catastrophic failure of the database system) you need to keep the store down, delete the contents of the store/mboxlist directory, and run reconstruct -m

Besides (in addition to) catastrophic recovery, reconstruct -m is also used to resynchronize the mboxlist with the user folders. 

The mboxlist is the absolute definition of which user folders are valid. Therefore, if a user folder exists in the store, but is, for some reason, not recorded in the mboxlist, the user will be unable to access this folder. 

Currently this situation may be the result of some restore functions as described in backup/restore. Although unlikely, it may also happen in the case of rare system failures. The symptoms are that the folder physically exists in the store, yet it can not be accessed through the server, and reconstruct claims it does not exist. 

In this case, you would run reconstruct -m on a running store WITHOUT removing any files as described under catastrophic failure. reconstruct -m will sift thru all existing folders without much interference to normal operation, and resynchronize existing folders into its database. 

Now that the mboxlist knows about the folder, a reconstruct can be run on the specific folder in order to make sure the folder is rebuilt correctly. 

For example: 

    For some reason Joe1 can not access any of his messages. We naturally try reconstruct user/joe1/INBOX but reconstruct reports the folder does not exist. 

    Looking in the joe1 directory in the message store, it appears as if there is valid data there. Thus we conclude the joe1 folder is not in the mboxlist database, and run a reconstruct -m

    Then we run a reconstruct user/joe1/INBOX to make sure the folder is consistent. 

An Extreme Case: 
    Suppose for some reason we experienced a catastrophic failure and our mboxlist database was damaged or destroyed, and we managed to somehow bring the store up anyhow, and allowed users to start accessing their mail. 

    In this extremely unlikely case, we know the mboxlist database is damaged. So following normal proceedures, we would do the following: 

    • bring the Messaging Server down
    • remove files in the store/mboxlist directory
    • run reconstruct -m
    • since users were accessing folders, they may have caused damage to their user folders. So if we think that is possible, run reconstruct -r.
    • restart the Messaging Server
Avoiding failures

Excepting hardware failures, the two leading causes of message store corruption are lack of disk space and manual manipulation of files. 

Disk space is absolutely required for a mail server to function as desired. Running out of disk space often leads to administrators trying to move files around and sometimes manually removing them. This very frequently results in some type of corruption. 

If you can avoid these two things, there is a very high probability you will avoid some VERY undesirable situations. 

Deleting Orphaned Mailboxes

Orphaned mailboxes (formerly active mailbox accounts that have had their LDAP entry deleted) can be deleted with the following two-step process: 

  1. Run the following command to create a file that contains the list of commands necessary to delete the orpahaned mailboxes. The name of the file is specified in the <orphans-cmd-file> parameter: 

  2. # reconstruct -o -d <orphans-cmd-file>

    The actual commands themselves look something like this: 

    mboxutil -d /user/test/annie/INBOX

  3. Run the following command to execute the commands listed in the <orphans-cmd-file> file and thus delete all orphaned accounts: 

  4. # sh <orphans-cmd-file>

High Availability Tuning Information
Tuning VxFS to Prevent Kernal Map Fragmentation

Noticeable performance slowdowns may be experienced when running Veritas File System (VxFS) 3.x on large memory (more than 1GB RAM) machines. The fragmentation occurs after VxFS allotts large amounts of memory for buffer cache use due to an immediate need and then frees the buffers when they are no longer needed. This occurs most commonly after a backup process has been run on a file system. 

This issue affects all users who match all of the following criteria: 

  • You are running VxFS 3.x. 
  • Your machine has more than 1GB RAM. More physical RAM allows VxFS to allocate more memory for buffer cache use which increases the chances for fragmentation. 
  • You make periodic backups of your VxFS file system or you run commands such as find, tar, and vxdump; these procedures all require many inodes to be temporarily cached in the kernel. 
  • You have a large number of files (over 100,000) in the file system. More files require more buffer cache use when they are scanned through by a backup. Database installations generally have a relatively small number of files and are less likely to experience this issue. 
If you match all of these criteria, you are at risk and it is recommended that you upgrade to VxFS 3.3.3, which has changed the method in which VxFS releases memory to alleviate this problem. 

To determine if you have a kernel map fragmentation problem, use the following command: 

# echo "map kernelmap" | crash | grep SEGMENT

If the total number of segments returned by this command is over 5,000, then the system is most likely experiencing a slowdown during memory allocations which can affect general performance. 

Veritas inode Issues

One of the benefits of the VxFS file system is the promise of unlimited inodes; the ability to create an unlimited number of directories and files in a file system. However, VxFS has a bug that could limit the number of inodes to just over 8 million. 

To overcome this limitation, you can do one of the following: 

  • Create the file system by using the mkfs command with the largefiles option. 
  • Set the largefiles option with the fsadm utility on an existing file system. 
To tell if a particular file system has the largefiles option set, use the fsadm as shown below (assuming that the file system is mounted as /data): 

# /usr/lib/fs/vxfs/fsadm /data

This command returns either nolargefiles or largefiles. If nolargefiles is returned, change the setting with the following: 

# /usr/lib/fs/vxfs/fsadm -o largefiles /data

The fsadm command should be run while the file system is mounted. It will not disrupt the normal operation of the file system. 

VxFS Tuning and Support

For Veritas support and tuning issues you should visit:

Directory Server failover

You can specify multiple LDAP servers for failover conditions if one of them goes down. To do this, you need to specify multiple LDAP servers in the local.ugldaphost parameter and set the local.ugldapuselocal parameter to yes

For example, if you specify: 

         configutil -o local.ugldaphost -v "ldap01.yourdomain ldap02.yourdomain"
         configutil -o local.ugldapuselocal -v "yes"
then if ldap01.yourdomain becomes inaccessible, it will fail over to use ldap02.yourdomain

Implementing RAID for Messaging

The recommended method for implementing RAID for messaging is to stripe first, then mirror. 

With the many areas of storage used by the Messaging Server, it has been found that RAID 0+1 for the message queue(s) and a hardware RAID5 solution for the mail store (software RAID being slow) works for some customer configurations. 

Backup and Restore Information
Configuration Parameters
  • local.lastconfigfetch 

  • This configuration parameter is created at runtime when any configuration utility is run. So, for example, you will see an updated value every time you run configutil

    Backup Tips and Information

    You can backup your file system either live or from a snapshot; either method will serve to get the bits on tape. For recovery, you should shut down the server and restore the message store from tape, plus any incremental backups. 

    If you're restoring everything, you should wipe out the mboxlist database and then run reconstruct -m to restore the mboxlist information and the quota information. 

    If you did not perform the backup from a snapshot, you must run reconstruct -r to rebuild the index files in each folder. 

    Restoring a Single Message

    To restore a single message, locate the #.msg file and use the deliver utility to push it back into a folder. Then run the following command: 

    reconstruct -r <mailbox>

    where <mailbox> includes something like user/<userid>/inbox.old

    Restoring a User's Inbox

    To restore a particular Inbox: 

    1. Run the following command to determine the path to the user's mailboxes: 

    2. # hashdir <userid>

    3. Use mboxlist -c to create a directory called inbox-old under the ../partition/<hashdir_result>/<userid> directory. 
    4. Move the contents of the inbox from the backup tape to the user's inbox-old directory. 
    5. Run the following command: 

    6. # reconstruct -r <mailbox>

      where <mailbox> includes something like user/<userid>/inbox-old. 

    Restoring a Single Folder

    To restore a single folder, move the folder from the backup tape to the user's directory (for example, partition/primary/=user/<hashdir_result>/<userid>/inbox.old). Then, run the following command: 

    # reconstruct -r <mailbox>

    where <mailbox> includes something like user/<userid>/inbox.old

    Recovering a User's Messages

    The following details a temporary workaround so that a user (mrobinson, in this example) can get access to his/her mail: 

    1. Create a folder named restored for user mrobinson

    2. # mboxutil -c user/mrobinson/restored

    3. Copy the ??/*.msg files from +=Main 1996 to =restored

    4. The names of the ?? directories and *.msg files are important; the files must have the same names and be under directories with the same name. 

      Note: Do not copy the store.* files; leave the ones that already exist in =restored

    5. Make sure all the file ownerships are correct. 
    6. Run the following command: 

    7. # reconstruct user/mrobinson/restored

      This may be run while the server is up. The messages should now be in the user's restored folder. 

    MTA Plugin and UBE Information
    Understanding Plugins

    Plugins are discussed at: and

    Authentication SDK (ProxyAuth) information can be found under your Messaging Server installation at <server-root>/bin/msg/authsdk/

    Writing Plugins

    Issues related to writing plugins include: 

    • Formats of messages passed through to a plugin is in RFC 822 compliant format. Messages sent header and body together can be split with the plugin by finding the CR/LF/CR/LF lines. 
    • For protocol (pre-accept) plugins, you should use the supplied API for alloc-ing space (*PPRealloc()). 

    • For post-accept and pre-deliver plugins, malloc() can be used. 

    • Handling the RSET command: 

    • RSET does not mean "think of this as a new connection", it means forget about whatever sender and recipient information I was trying to pass on - I'll give up on that particular message/envelope and try another. 

      A very important distinction here is that authentication may only happen once. 

    • If denying delivery of a message by returning an error of the form: 

    • 551 delivery not allowed outside of local domains for restricted users

      return PP_DONE and don't DEFERLINE. Remember, the real server is at the bottom of the stack. 

    Install and Upgrade Information
    Understanding Installation and Upgrade

    Installation is discussed in detail at:

    upgrade utility

    When using the upgrade utility with the -r option to remove messages, it first converts the file from Messaging Server 3.x format to 4.x format; if successful, it removes the 3.x file, and then moves onto the next file for conversion. 

    Revision History
    • April 24, 2000
    • Add local.tmpdir explanation to the Security section. 
    • Add checkdeferredqueue, *actions, timeoutcommand and timeoutdata descriptions to the MTA section. 
    • Update information about mailAccessDomains in the Security section. 
    • Add information about upgrade to the Install section. 
    • Add information about the langauge of replies to the MTA section. 
    • Add local.ugldaphost and local.ugldapuselocal explanation to the High Availability section. 
    • Add more information about store.dbtmpdir to the Store section. 
    • Add Protocol Telemetry/Tracing information to the Protocol section. 
    • April 21, 2000
    • Add Install and Upgrade section. 
    • Add WebMail Tuning section 
    • Add Specifying Mailbox Access Domains to the Security section. 
    • Add Synchronization of Message Writes section and store.cleanupage parameter to the Store section. 
    • Update HP/UX kernel tuning parameters. 
    • Fix Solaris kernel tuning parameters ufs_ninode instead of ufs_inode; add reference to 20% buffer between vxio:vxfs_ninode and ufs_ninode values. 
    • Change Tru64 Unix support reference to include 4.0e and 4.0f, as well. 
    • Add section on specifying local mail domains to the Protocol section. 
    • Add several items to the MTA section, including: Mail Headers, dorewrite*usingauth and domainlangtable parameters, more DNS references. 
    • Update section on maxsessions with difference between 4.x and 4.1x. 
    • Add limitation information on aging policies. 
    • Add Revision history. 
    • March 23, 2000
    • Reorder Solaris tuning parameters above HP; add URLs for vendor tuning information for all platforms where available. 
    • Add parameter information to MTA section, including: log, addresentfrom, throttlethreshold parameters. 
    • Add other information to the MTA section, including: postmaster settings, turning DNS caching off, MTA fallback hosts, and turning off LDAP lookups, sendmail utility settings. 
    • Add extensive description of MTA queueing behavior to the MTA section. 
    • Add quota information to the Protocol section. 
    • Add discussion of the reconstruct utility and message store maintenance. 
    • Add Plugin tuning and writing information. 
    • January 17, 2000
    • Add Linux information.
    • Add information about running reconstruct on a live server.
    • Add information about MTA relay tuning.

    © Copyright 1999, 2000 Netscape Communications Corp., a subsidiary of America Online, Inc. All rights reserved.