Chapter 6   About MTA Services and Configuration


This chapter provides concepts about configuring MTA services for your server. This chapter contains the following sections:

• The Message Transfer Agent (MTA)

• Channels

• Rewrite Rules

• The Job Controller

• The Dispatcher

• The MTA Configuration File

• Other MTA Configuration Files

• Aliases

• Command Line Utilities

• The MTA Directory Cache

• SMTP Security and Access Control

• Log Files

The Message Transfer Agent (MTA)

---

The Messaging Server Message Transfer Agent (MTA) is part of a store and forward messaging system based on Internet standards. The MTA determines how to route messages for ultimate delivery to the appropriate recipient. As shown in Figure 6-1, the MTA can:

• Route messages to another SMTP host

• Deliver messages to the local message store

• Deliver messages to a program for processing (such as mail filtering)

Figure 6-1    MTA Routing and Delivery

Channels

---

The channel is the fundamental MTA component that processes a message. A channel represents a connection with another computer system or group of systems. The actual hardware connection or software transport or both may vary widely from one channel to the next.

Channels perform the following functions:

• Transmit messages to remote systems, deleting them from their queue after they are sent.

• Accept messages from remote systems, placing them in the appropriate channel queues.

• Deliver messages to the local message store.

• Deliver messages to programs for special processing.

Messages are enqueued by channels on the way into the MTA and dequeued on the way out. Typically, a message enters via one channel and leaves by another. A channel might dequeue a message, process the message, or enqueue the message to another MTA channel.

You define channels in the primary MTA configuration file, imta.cnf. You can also set global options for channels in the MTA option file, option.dat, or set options for a specific channel in a channel option file.

For more information about the MTA configuration file, see The MTA Configuration File. For more information on the option files, see Option File, and TCP/IP Channel Option Files. For complete details about configuring channels, see Chapter 8 "Configuring Channel Definitions."

Master and Slave Programs

Generally (but not always), a channel consists of two programs: master and slave. A channel program that initiates a transfer to a remote system on its own is called a "master" program, while a program that accepts transfers initiated by a remote system is called a "slave" program.

For example, an SMTP channel has a master program that transmits messages and a slave program that receives messages. These are, respectively, the SMTP client and server.

• The master channel program is typically responsible for outgoing connections where the MTA has initiated the operation. The master channel program:
  • Runs in response to a local request for processing.

  • Dequeues the message from the channel message queue.

  • If the destination format is not the same format as the queued message, performs conversion of addresses, headers, and content, as necessary.

  • Initiates network transport of the message.

• The slave channel program typically accepts incoming connections where the MTA is responding to an external request. The slave channel program:
  • Runs in response to an external event or upon local demand.

  • Enqueues a message to a channel. The target channel is determined by passing envelope addresses through a rewrite rule. (Rewrite rules are described in further detail later in this chapter.)

For example, Figure 6-2 shows two channel programs, Channel 1 and Channel 2. Assume the slave program in Channel 1 receives a message from a remote system. The slave program looks at the address, applies rewrite rules as necessary, then based on the rewritten address, enqueues the message to the appropriate channel message queue.

The slave program can enqueue the message to its own message queue or to a message queue belonging to another channel. The master program dequeues the message from the queue and initiates network transport of the message. Note that the master program can only dequeue messages from its own channel queue.

Figure 6-2    Master and Slave Programs

Although a typical channel has both a master and a slave program, it is possible for a channel to contain only a slave program or a master program. For example, the ims-ms channel supplied with Messaging Server contains only a master program because this channel is responsible only for dequeueing messages to the local message store, as shown in Figure 6-3.

Figure 6-3    ims-ms Channel

Channel Message Queues

All channels have an associated message queue. When a message enters the messaging system, a slave program determines to which message queue the message is enqueued. The enqueued messages are stored in message files in the channel queue directories. By default, these directories are stored at the following location: /server-instance/imta/queue/channel/*.

Rewrite Rules

---

Rewrite rules determine the following:

• How to rewrite addresses into their proper or desired format.

• To which channel the message should be enqueued after the address is rewritten.

Each rewrite rule consists of a pattern, which indicates the string to search for in the domain name of an address, and a template, which indicates how the address should be rewritten based on the pattern it matches. After the address is rewritten, the message is enqueued to the destination channel for delivery to the intended recipient.

For more information about configuring rewrite rules, see The MTA Configuration File and Chapter 7 "Configuring Rewrite Rules."

The Job Controller

---

The Job Controller creates and manages channel jobs for delivering messages. These channel jobs run inside processing pools within the Job Controller.

Each time a message is enqueued to a channel, the Job Controller ensures that there is a job running to deliver the message. This might involve starting a new job process, adding a thread, or simply noting that a job is already running. If a job cannot be started because the job limit for the channel or pool has been reached, the Job Controller waits until another job has exited, then, when the job limit is no longer exceeded, starts another job.

At startup, the Job Controller reads a configuration file that specifies general parameters, return job scheduling, purge job scheduling, pool definitions, and channel processing information. This configuration information is specified in the file job_controller.cnf in the server_root/msg-instance/imta/config/ directory.

For information about configuring the Job Controller, see Job Controller File and Configuring Message Processing and Delivery.

To start the Job Controller, execute the command:

imsimta start job_controller

To shut down the Job Controller, execute the command:

imsimta stop job_controller

To restart the Job Controller, execute the command:

imsimta restart job_controller

Restarting the Job Controller has the effect of shutting down the currently running Job Controller, then immediately starting a new one.

The Dispatcher

---

The Dispatcher is a multithreaded connection dispatching agent that permits multiple multithreaded servers to share responsibility for a given service. When using the Dispatcher, it is possible to have several multithreaded SMTP server processes running concurrently. In addition, each server may have one or more active connections.

The Dispatcher acts as a central receiver for the TCP ports listed in its configuration. For each defined service, the Dispatcher may create one or more SMTP server processes to handle the connections after they are established.

In general, when the Dispatcher receives a connection for a defined TCP port, it checks its pool of available worker processes for the service on that port and chooses the best candidate for the new connection. If no suitable candidate is available and the configuration permits it, the Dispatcher may create a new worker process to handle this and subsequent connections. The Dispatcher may also create a new worker process in expectation of future incoming connections. There are several configuration options which may be used to tune the Dispatcher's control of its various services, and in particular, to control the number of worker processes and the number of connections each worker process handles.

Creation and Expiration of Server Processes

Automatic housekeeping facilities within the Dispatcher control the creation of new and expiration of old or idle server processes. The basic options that control the Dispatcher's behavior are MIN_PROCS and MAX_PROCS. MIN_PROCS provides a guaranteed level of service by having a number of server processes ready and waiting for incoming connections. MAX_PROCS, on the other hand, sets an upper limit on how many server processes may be concurrently active for the given service.

It is possible that a currently running server process might not be able to accept any connections because it is already handling the maximum number of connections of which it is capable, or because the process has been scheduled for termination. The Dispatcher may create additional processes to assist with future connections.

The MIN_CONNS and MAX_CONNS options provide a mechanism to help you distribute the connections among your server processes. MIN_CONNS specifies the number of connections that flags a server process as "busy enough" while MAX_CONNS specifies the "busiest" that a server process can be.

In general, the Dispatcher creates a new server process when the current number of server processes is less than MIN_PROCS or when all existing server processes are "busy enough" (the number of currently active connections each has is at least MIN_CONNS).

If a server process is killed unexpectedly, for example, by the UNIX system kill command, the Dispatcher still creates new server processes as new connections come in.

For information about configuring the Dispatcher, see Dispatcher Configuration File.

Controlling the Dispatcher

The Dispatcher is a single resident process that starts and shuts down server processes for various services, as needed.

To start the Dispatcher, execute the command:

imsimta start dispatcher

This command subsumes and makes obsolete any other imsimta start command that was used previously to start up a component of the MTA that the Dispatcher has been configured to manage. Specifically, you should no longer use imsimta start smtp. An attempt to execute any of the obsoleted commands causes the MTA to issue a warning.

To shut down the Dispatcher, execute the command:

imsimta stop dispatcher

What happens with the server processes when the Dispatcher is shut down depends upon the underlying TCP/IP package. If you modify your MTA configuration or options that apply to the Dispatcher, you must restart the Dispatcher so that the new configuration or options take effect.

To restart the Dispatcher, execute the command:

imsimta restart dispatcher

Restarting the Dispatcher has the effect of shutting down the currently running Dispatcher, then immediately starting a new one.

The MTA Configuration File

---

The primary MTA configuration file is named imta.cnf. By default, this file is found in the following location: server-instance/imta/config/imta.cnf. This file contains all channel definitions for your server as well as the rewrite rules that determine how addresses are rewritten for routing. The channel associated with a rewritten destination address becomes the destination channel.

This section provides a brief introduction to the MTA configuration file. For details about configuring the rewrite rules and channel definitions that make up the MTA configuration file, see Chapter 7 "Configuring Rewrite Rules," and Chapter 8 "Configuring Channel Definitions."

By modifying the MTA configuration file, you establish the channels in use at a site and establish which channels are responsible for which sorts of addresses via rewrite rules. The configuration file establishes the layout of the email system by specifying the transport methods available (channels) and the transport routes (rewrite rules) associating types of addresses with appropriate channels.

The following example of an imta.cnf configuration file shows how rewrite rules are used to route messages to the proper channel. No domain names are used to keep things as simple as possible. The rewrite rules appear in the upper half of the configuration file followed by the channel definitions in the lower half of the configuration file.

Figure 6-4    Simple MTA Configuration File

! test.cnf - An example configuration file. (1) ! ! This is only an example of a configuration file. It serves ! no useful purpose and should not be used in a real system. ! a $U@a-daemon (2) b $U@b-daemon c $U%c@b-daemon d $U%d@a-daemon (3) l (4) local-host a_channel defragment charset7 usascii (5) a-daemon b_channel noreverse notices 1 2 3 b-daemon

The key items (labeled with boldface numbers, enclosed in parentheses) in the preceding configuration file are explained in the following list:

1. Exclamation points (!) are used to include comment lines. The exclamation point must appear in the first column. An exclamation point appearing anywhere else is interpreted as a literal exclamation point.

2. The rewrite rules appear in the first half of the configuration file. No blank lines can appear among the lines of rewrite rules. Lines with comments (beginning with an exclamation point in the first column) are permitted.

3. The first blank line to appear in the file signifies the end of the rewrite rules section and the start of the channel blocks.

4. On UNIX, the first channel block to appear is always the l channel (the UNIX local channel, designated with the lowercase letter "l"). Blank lines then separate each channel block from one another. (An exception is the defaults channel, which can appear before the l channel).

Table 6-1 lists the routing and queuing of messages by the preceding configuration.

Table 6-1 Addresses and Associated Channels

Address	Queued to channel
u@a	a_channel
u@b	b_channel
u@c	b_channel
u@d	a_channel

Other MTA Configuration Files

---

In addition to the imta.cnf file, iPlanet Messaging Server provides several other configuration files to help you configure MTA services. These files are summarized in Table 6-2.

Table 6-2 MTA Configuration Files

File	Description
Autoreply Option File	Options used by the autoreply program. /server-instance/imta/config/autoreply_option
Alias File (mandatory)	Implements aliases not present in the directory. /server-instance/imta/config/aliases
TCP/IP Channel Option Files	Sets channel-specific options. /server-instance/imta/config/channel_option
Conversion File	Used by the conversion channel to control message body part conversions. /server-instance/imta/config/conversions
Dirsync Option File (mandatory)	Options used by the dirsync program. /server-instance/imta/config/dirsync.opt
Dispatcher Configuration File (mandatory)	Configuration file for the Dispatcher. /server-instance/imta/config/dispatcher.cnf
MTA Configuration File (mandatory)	Used for address rewriting and routing as well as channel definition. /server-instance/imta/config/imta.cnf
Mapping File (mandatory)	Repository of mapping tables. /server-instance/imta/config/mappings
Option File	File of global MTA options. /server-instance/imta/config/option.dat
Tailor File (mandatory)	File to specify locations and some tuning parameters. /server-instance/imta/config/imta_tailor
Job Controller File (mandatory)	Configuration file used by the Job Controller. /server-instance/imta/config/job_controller.cnf

Autoreply Option File

The autoreply option file, autoreply_option, sets options for the autoreply or vacation program. For more information about the syntax of this file, see the Messaging Server Reference Manual.

Alias File

The alias file, aliases, sets aliases not set in the directory. In particular, the address for root is a good example. Aliases set in this file will be ignored if the same aliases exist in the directory. For more information about aliases and the aliases file, see Aliases.

After making changes to the aliases file, you must restart the MTA.

TCP/IP Channel Option Files

TCP/IP channel option files control various characteristics of TCP/IP channels. Channel option files must be stored in the MTA configuration directory and named x_option, where x is the name of the channel. For example, /server-instance/config/imta/tcp_local_option.

The option file consists of one or more keywords and an associated value. For example you can disable the SMTP EXPN command on your server by including the DISABLE_EXPAND keyword in the option file and setting the value to 1.

Other option file keywords allow you to:

• Set a limit on the number of recipients allowed per message (ALLOW_RECIPIENTS_PER_TRANSACTION)

• Set a limit on the number of messages allowed per connection (ALLOW_TRANSACTIONS_PER_SESSION)

• Control the type of information logged to the MTA log file (LOG_CONNECTION, LOG_TRANSPORTINFO)

• Specify the maximum number of simultaneous outbound connection that the client channel program allows (MAX_CLIENT_THREADS)

For information about all channel option keywords and syntax, see the Messaging Server Reference Manual.

Conversion File

The conversion file, conversions, specifies how the conversion channel performs conversions on messages flowing through the MTA. Any subset of MTA traffic can be selected for conversion and any set of programs or command procedures can be used to perform conversion processing. The MTA looks at the conversion file to choose an appropriate conversion for each body part.

For more information about the syntax of this file, see the Messaging Server Reference Manual.

Dirsync Option File

The dirsync option file, dirsync.opt, sets options for the dirsync program that cannot be set through the command line.

For more information about the syntax of this file, see the Messaging Server Reference Manual.

Dispatcher Configuration File

The Dispatcher configuration file, dispatcher.cnf, specifies Dispatcher configuration information. A default configuration file is created at installation time and can be used without any changes made. However, if you want to modify the default configuration file for security or performance reasons, you can do so by editing the dispatcher.cnf file.

The Dispatcher configuration file format is similar to the format of other MTA configuration files. Lines specifying options have the following form:

option=value

The option is the name of an option and value is the string or integer to which the options is set. If the option accepts an integer value, a base may be specified using notation of the form b%v, where b is the base expressed in base 10 and v is the actual value expressed in base b. Such option specifications are grouped into sections corresponding to the service to which the following option settings apply, using lines of the following form:

[SERVICE=service-name]

The service-name is the name of a service. Initial option specifications that appear before any such section tag apply globally to all sections.

The following is a sample Dispatcher configuration file (dispatcher.cnf).

! The first set of options, listed without a [SERVICE=xxx] ! header, are the default options that will be applied to all ! services. ! MIN_PROCS=0 MAX_PROCS=5 MIN_CONNS=5 MAX_CONNS=20 MAX_LIFE_TIME=86400 MAX_LIFE_CONNS=100 MAX_SHUTDOWN=2 ! ! Define the services available to Dispatcher ! [SERVICE=SMTP] PORT=25 IMAGE=server_root/msg-instance/imta/lib/tcp_smtp_server LOGFILE=server_root/msg-instance/imta/log/tcp_smtp_server.log

For more information about the parameters for this file, see the Messaging Server Reference Manual.

Mapping File

The mapping file, mappings, defines how the MTA maps input strings to output strings.

Many components of the MTA employ table lookup-oriented information. Generally speaking, this sort of table is used to transform (that is, map) an input string into an output string. Such tables, called mapping tables, are usually presented as two columns, the first (or left-hand) column giving the possible input strings and the second (or right-hand) column giving the resulting output string for the input it is associated with. Most of the MTA databases are instances of this type of mapping table. The MTA database files, however, do not provide wildcard-lookup facilities, owing to inherent inefficiencies in having to scan the entire database for wildcard matches.

The mapping file provides the MTA with facilities for supporting multiple mapping tables. Full wildcard facilities are provided, and multi-step and iterative mapping methods can be accommodated as well. This approach is more compute-intensive than using a database, especially when the number of entries is large. However, the attendant gain in flexibility may actually serve to eliminate the need for most of the entries in an equivalent database, and this may actually result in lower overhead overall.

You can test mapping tables with the imsimta test -mapping command. For more information about the syntax of the mapping file and the test -mapping command, see the Messaging Server Reference Manual.

Option File

The options file, option.dat, specifies global MTA options—as opposed to channel options.

You can use the options file to override the default values of various parameters that apply to the MTA as a whole. In particular, the option file is used to establish sizes of the various tables into which the configuration and alias files are read. You can also use the options file to limit the size of messages accepted by the MTA, specify the number of channels allowed in the MTA configuration, set the number of rewrite rules allowed, and so on.

For more information about the syntax of the options file, see the Messaging Server Reference Manual.

Tailor File

The tailor file, imta_tailor, sets the location of various MTA components. For the MTA to function properly, the imta_tailor file must always reside in the server-instance/imta/config directory.

Although you can edit this file to reflect the changes in a particular installation, you must do so with caution. After making any changes to this file, you must restart the MTA. It is preferable to make the changes while the MTA is down.

---

Note	Do not edit this file unless absolutely necessary.

---

For more information about the syntax of this file, see the Messaging Server Reference Manual.

Job Controller File

The Job Controller file, job_controller.cnf, specifies channel processing information. This file:

• Defines various pools

• Specifies for all channels the master program name and the slave program name, if applicable

In the imta.cnf file, you can specify the name of a process pool (that was defined in job_controller.cnf) by using the pool keyword. For example, the following fragment from a sample job_controller.cnf file defines the pool MY_POOL:

[POOL=MY_POOL]
job_limit = 12

The following fragment from a sample imta.cnf file specifies the pool MY_POOL in a channel block:

channel_x pool MY_POOL
channel_x-daemon

If you want to modify the parameters associated with the default pool configuration or add additional pools, you can do so by editing the job_controller.cnf file, then stopping and restarting the Job Controller.

A new Job Controller process is created, using the new configuration, and receives subsequent requests. The old Job Controller process continues to execute any requests it has queued until they are all finished, at which time it exits.

The first pool in the Job Controller configuration file is used for any requests that do not specify the name of a pool. The MTA channels defined in the MTA configuration file (imta.cnf) can have their processing requests directed to a specific pool by using the pool channel keyword followed by the name of the pool. The pool name must match the name of a pool in the Job Controller configuration. If the Job Controller does not recognize the requested pool name, the request is ignored.

In the initial configuration, the following pools are defined: DEFAULT, LOCAL_POOL, IMS_POOL, SMTP_POOL.

Examples of Use

Typically, you would add additional pool definitions to the Job Controller configuration if you wanted to differentiate processing of some channels from that of other channels. You might also choose to use pools with different characteristics. For example, you might need to control the number of simultaneous requests that some channels are allowed to process. You can do this by creating a new pool with the job limit, then use the pool channel keyword to direct those channels to the new, more appropriate pool.

In addition to the definition of pools, the Job Controller configuration file also contains a table of the MTA channels and the commands that the Job Controller must use to process requests for each channel. The two types of requests are termed "master" and "slave." Typically, a channel master program is invoked when there is a message stored in an MTA message queue for the channel. The master program dequeues the message.

A slave program is invoked to poll a channel and pick up any messages inbound on that channel. While nearly all MTA channels have a master program, many do not have or need a slave program. For example, a channel that handles SMTP over TCP/IP doesn't use a slave program because a network service, the SMTP server, receives incoming SMTP messages upon request by any SMTP server. The SMTP channel's master program is the MTA's SMTP client.

If the destination system associated with the channel cannot handle more than one message at a time, you need to create a new type of pool whose job limit is one:

[POOL=single_job]
job_limit=1

On the other hand, if the destination system has enough parallelism, you can set the job limit to a higher value.

Figure 6-5 shows a sample Job Controller configuration file.

Figure 6-5    Sample Job Controller Configuration file on UNIX

!MTA Job Controller configuration file ! !Global defaults tcp_port=27442   (1) secret=never mind return_job=server_root/bin/msg/imta/bin/return.sh return_time=00:30/24:00 purge_job=server_root/bin/msg/imta/bin/purge purge_argv=-num=5 slave_command=NULL   (2) max_life_age=3600   (3) ! ! !Pool definitions ! [POOL=DEFAULT]   (4) job_limit=10   (5) ! [POOL=LOCAL_POOL] job_limit=10 ! [POOL=IMS_POOL] job_limit=1 ! [POOL=SMTP_POOL] job_limit=1 ! !Channel definitions ! ! [CHANNEL=l]   (6) master_command=server_root/bin/msg/imta/bin/l_master ! [CHANNEL=ims-ms] master_command=server_root/bin/msg/imta/bin/ims_master ! [CHANNEL=tcp_*]   (7) anon_host=0 master_command=server_root/bin/msg/imta/bin/tcp_smtp_client

The key items in the preceding example (numbered, enclosed in parentheses, and in bold font) are:

1. This global option defines the TCP port number on which the Job Controller listens for requests.

2. Sets a default SLAVE_COMMAND for subsequent [CHANNEL] sections.

3. Sets a default MAX_LIFE_AGE for subsequent [CHANNEL] sections.

4. This [POOL] section defines a pool named DEFAULT.

5. Set the JOB_LIMIT for this pool to 10.

6. This [CHANNEL] section applies to a channel named l, the UNIX local channel. The only definition required in this section is the master_command, which the Job Controller issues to run this channel. Since no wildcard appears in the channel name, the channel must match exactly.

7. This [CHANNEL] section applies to any channel whose name begins with tcp_*. Since this channel name includes a wildcard, it will match any channel whose name begins with tcp_.

For more information about the syntax of the Job Controller file, see the Messaging Server Reference Manual.

Aliases

---

The MTA provides a facility to support mailbox names associated with the local system that do not necessarily correspond to actual users: aliases. Aliases are useful for constructing mailing lists, forwarding mail, and providing synonyms for user names.

Aliases apply only to addresses that match the l channel or to any channel marked with the aliaslocal keyword. Each time an address that matches the l channel or any channel marked with the aliaslocal keyword is encountered by the MTA's message submission logic, the mailbox (for example, username) specified in the address is compared against each entry in the alias database or alias file. If a match occurs the alias address is replaced by the translation value or values specified by the alias. An alias can translate into any combination and number of additional aliases or real addresses. The real addresses need not themselves be associated with the l channel or any channel marked with the aliaslocal keyword and thus aliases can be used to forward mail to remote systems.

Since the only addresses truly considered to match a channel are Envelope To addresses, aliases can apply only to Envelope To addresses. The MTA performs alias translation and expansion only after address rewriting is completed. The translation values produced by an alias are treated as completely new addresses and are reprocessed from scratch.

The Alias Database

The MTA uses the information in the directory and creates the alias database. The alias database is consulted once each time the regular alias files is consulted. However, the alias database is checked before the regular alias file is used. In effect, the database acts as a sort of address rewriter that is invoked prior to using the alias file. Refer to the iPlanet Messaging Server 5.0 Provisioning Guide for information on what directory attributes are used to create user and distribution list entries in the alias database.

---

Note	The format of the database itself is private. Do not try to edit the database directly. Make all required changes in the directory.

---

The Alias File

The aliases file is used to set aliases not set in the directory. In particular, the postmaster alias is a good example. Aliases set in this file will be ignored, if the same aliases exist in the directory. The MTA has to be restarted for any changes to take effect. Any line that begins with an exclamation point is considered to be a comment and is ignored. Blank lines are also ignored.

A physical line in this file is limited to 252 characters. You can split a logical line into multiple physical lines using the backslash (\) continuation character.

The format of the file is as follows:

user@domain: <address> (for users in hosted domains) user@domain: <address> (for users in non-hosted domains. For example, default-domain)

For example:

! A /var/mail/ user inetmail@siroe.com: inetmail@native-daemon ! A message store user ms_testuser@siroe.com: mstestuser@ims-ms-daemon

Including Other Files in the Alias File

Other files can be included in the primary aliases file. A line of the following form directs the MTA to read the file-spec file:

<file-spec

The file specification must be a complete file path specification and the file must have the same protections as the primary aliases file; for example, it must be world readable.

The contents of the included file are inserted into the aliases file at its point of reference. The same effect can be achieved by replacing the reference to the included file with the file's actual contents. The format of include files is identical to that of the primary aliases file itself. Indeed, include files may themselves include other files. Up to three levels of include file nesting are allowed.

Command Line Utilities

---

iPlanet Messaging Server provides several command-line utilities that enable you to perform various maintenance, testing, and management tasks for the MTA. For example, you use the imsimta cnbuild command to compile the MTA configuration, alias, mapping, security, system wide filter, and option files. You use the imsimta dirsync command to recreate or update the MTA directory cache. For complete information on the MTA command-line utilities, see the Messaging Server Reference Manual.

The MTA Directory Cache

---

For each message that it processes, the MTA needs to access information about the users, groups (mailing lists, family accounts, organization), and domains that it supports. This information is stored in an LDAP directory service. Rather than querying the directory service each time it processes a message, the MTA caches the directory information; that is, it takes a snapshot of the directory information and stores it. The MTA then accesses the directory information in the cache.

The directory information stored in the directory service is continuously updated. As a result, the directory information in the MTA-directory cache must be updated periodically—that is, synchronized—with the current directory information in the directory service. Messaging Server supports two types of synchronization:

• Full synchronization - The existing cache is replaced with a new cache, completely rebuilt with the current user and group entries from the directory service. After the synchronization occurs, the MTA configuration file is rebuilt, then the MTA is automatically restarted.

• Incremental synchronization - The existing cache is updated with user and group entries that were created or modified since the last full or incremental synchronization. The MTA is not restarted.

By default, the MTA directory cache is fully synchronized every day at 2:00 am and incrementally synchronized every ten minutes.

Table 6-3 shows which updates occur on full and partial directory synchronizations.

Table 6-3 MTA Directory Cache Updates

MTA Directory Cache Update	Full Synchronization	Incremental Synchronization
New user entries added	Yes	Yes
Modified user entries updated	Yes	Yes
*Deleted user entries removed	Yes	No
New members added to existing distribution lists	Yes	Yes
Deleted members removed from existing distribution lists	Yes	Yes
New distribution lists added	Yes	Yes
*Deleted distribution lists removed	Yes	No
*For incremental directory synchronization to take account of deleted entries, the entry's status must first be marked as deleted. After performing an incremental synchronization, the MTA considers the user or group to be nonexistent. The actual directory deletion must be done only after the incremental synchronization.

In general, directory synchronization occurs automatically. However, if necessary, you can use the imsimta dirsync command to recreate or update the MTA directory cache. For more information on the imsimta dirsync command, see the Messaging Server Reference Manual.

Synchronization Configuration Parameters

Table 6-4 lists the directory synchronization configuration parameters.

Table 6-4 Directory Synchronization Configuration Parameters

Parameter	Description
local.imta. ldsearchtimeout	Specifies the LDAP search timeout when searching for users and mailing list information. The default is no timeout.
local.imta. hostnamealiase	When checking the mailhost or mailRoutingHosts attribute of an LDAP entry to see if it is local, the dirsync process uses the local.hostname parameter to do the comparison. In addition, a comma separated list of hostname aliases can be provided through the local.imta.hostnamealiases parameter. The dirsync process will then use all the hostnames provided in those 2 parameters to check if an entry is local.
local.imta. mailaliases	By default, the MTA considers only the mail and mailAlternateAdress LDAP attributes as routable email addresses. Alternatively, a comma separated list of LDAP attributes can be provided through the local.imta.mailaliases parameter. This list overwrites the default attributes. For example, the MTA will consider the following four attributes when routing messages: local.imta.mailaliases=mail,mailAlternateAdres, rfc822mailbox,rfc822mailalias
local.imta. ugfilter	This parameter sets the LDAP search filter that dirsync uses when searching for users and mailing list information. The default filter is (objectClass=inetLocalMailRecipient). For example, if you want to consider only LDAP entries with the inetLocalMailRecipient AND myispSubscriber object classes, you would set this parameter to: local.imta.ugfilter= (&(objectClass=inetLocalMailRecipient) (objectClass=myispSubscriber)) Note: A timestamp filter will be added to this filter in the case of an incremental synchronization. As a consequence, you need to wrap your custom filter with ().
local.imta. statssamplesize	If set, this parameter tells dirsync to print out on the standard output a summary of the number of user and mailing list entries proceeded since the beginning as well as an average rate in entries/second. Users and mailing lists are counted whether or not they are successfully synchronized.
local.imta. reverseenabled	Triggers the generation of the reverse database. The default value is yes. How the reverse database is actually used is controlled by the USE_REVERSE_DATABASE option.
local.imta. ssrenabled	Triggers the generation of the server side rule (SSR) database. The default value is yes. How the SSR database is actually used is controlled by the ssr channel keyword.
local.imta. vanityenabled	Controls whether or not vanity domains (msgVanityDomain user LDAP attribute) are enabled. The default is yes.
local.imta. catchallenabled	Controls whether or not catchall addresses (mail or mailAlternateAddress of the form @domain) are enabled. The default is yes.
local.imta. scope	This parameter tells dirsync which entries it should synchronize: Cache only user and mailing list entries for which the mailhost attribute is the local host: value = "local". Cache user and mailing list entries regardless of their mailhost attribute: value = "domains". This is the default value if the parameter is missing. Do not cache any domain, user, or mailing list: value = "nobody"

SMTP Security and Access Control

---

For information about SMTP security and access control, see Chapter 9 "Mail Filtering and Access Control," and Chapter 11 "Configuring Security and Access Control."

Log Files

---

All MTA specific log files are kept in the MTA log directory, (server-instance/log/imta/). This directory contains log files that describe message traffic through the MTA and log files that describe information about specific master or slave programs.

For more information about MTA log files, see Chapter 12 "Logging and Log Analysis."