10.4 Other MTA Configuration Files

In addition to the imta.cnf file, Messaging Server provides several other configuration files to help you configure MTA services. These files are summarized in Table 10–5. This section consists of the following subsections:

• 10.4.1 Alias File

• 10.4.2 TCP/IP (SMTP) Channel Option Files

• 10.4.3 Conversion File

• 10.4.4 Dispatcher Configuration File

• 10.4.5 Mappings File

• 10.4.6 Option File

• 10.4.7 Tailor File

• 10.4.8 Job Controller File

If you make changes to the reverse, forward, or general databases, then issue the command imsimta reload to get the changes to take effect (see 10.9.1 MTA Text Databases). If you make changes to the imta.cnf, mappings file, aliases, conversions, or option.dat files that do not affect the job_controller, then you should issue an imsimta cnbuild followed by an imsimta restart smtp. If you make changes to dispatcher.cnf you need to do an imsimta restart dispatcher. If you make changes to the configuration files that are included in the compiled configuration that affect the job controller, but not the SMTP server, in many cases you should issue the following commands: imsimta cnbuild and imsimta restart job_controller.

See MTA Commands in Sun Java System Messaging Server 6.3 Administration Reference for details on these commands.

10.4.1 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 10.5 Aliases.

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

10.4.2 TCP/IP (SMTP) 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, msg-svr-base/config/tcp_local_option. For more information refer to 12.4.1 Configuring SMTP Channel Options. For complete information on all channel option keywords and syntax, see the Sun Java System Messaging Server 6.3 Administration Reference.

10.4.3 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 13.5 The Conversion Channel

10.4.4 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. (For conceptual information, see 8.3 The Dispatcher

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=msg-svr-base/lib/tcp_smtp_server
LOGFILE=msg-svr-base/log/tcp_smtp_server.log

For more information about the parameters for this file, see the Sun Java System Messaging Server 6.3 Administration Reference.

10.4.5 Mappings File

The mappings file 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 mappings 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 mappings file and the test -mapping command, see the 10.3 Mappings File and theSun Java System Messaging Server 6.3 Administration Reference

After making changes to the mappings file, you must restart the MTA or issue the command imsimta reload.

10.4.6 Option File

The options file, option.dat, specifies global MTA options as opposed to channel-specific 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.

In option.dat, lines starting with #, ! or ; are treated as comment lines, even if the preceding line has a trailing \ meaning that it is being continued. This means that long options that may contain these characters, in particular delivery options, care has to be taken.

For delivery options, where a natural layout would lead to continuation lines starting with a # or !, there is a safe and neat work around.

For more information about the syntax of the options file, see the Sun Java System Messaging Server 6.3 Administration Reference.

10.4.7 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 msg-svr-base/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.

Do not edit this file unless absolutely necessary.

For complete information on this file, see the Sun Java System Messaging Server 6.3 Administration Reference.

10.4.8 Job Controller File

The Job Controller creates and manages channel jobs for delivering messages. These channel jobs run inside processing pools within the Job Controller. A pool can be thought of a “place” where the channel jobs are run. The pool provides a computing area where a set of jobs can operate without vying for resources with jobs outside of the pool. (For information on Job Controller concepts and channel keyword configuration, refer to 8.7 The Job Controller, 12.5.4 Processing Pools for Channel Execution Jobs and 12.5.5 Service Job Limits.

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

• 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.

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.

10.4.8.1 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.

Example 10–1 shows a sample Job Controller configuration file. Table 10–6 shows the available options.

Example 10–1 Sample Job Controller Configuration File in UNIX

!MTA Job Controller configuration file
!
!Global defaults
tcp_port=27442         (1)
secret=never mind
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=msg-svr-base/lib/l_master
!
[CHANNEL=ims-ms]
master_command=msg-svr-base/lib/ims_master
!
[CHANNEL=tcp_*]         (7)
master_command=msg-svr-base/lib/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_.

Example of Adding Additional Pools

The Job Controller creates and manages channel jobs for delivering messages. These channel jobs run inside processing pools within the Job Controller. A pool can be thought of a “place” where the channel jobs are run. The pool provides a computing area where a set of jobs can operate without vying for resources with jobs outside of the pool. Note that the job limit that is set in the job_controller is per pool. So, for example, if you have your SMTP_POOL defined with a job_limit of 10, then only 10 tcp_smtp client processes can run in that pool at any given time.

There are situations where one may want to create additional tcp_* channels (say, for example, a tcp channel for particularly slow mail sites). It is a good idea to have these channels run in different pools. The reason for this is if we created ten different tcp_* channels and they were all running in SMTP_POOL, it is possible to only have one tcp_smtp client running per tcp_* channel at any given time (depending on whether or not there is mail destined for all the tcp_* channels and given that SMTP_POOL defined with a job_limit of 10). Assuming there is heavy load on the system and that all queues have messages waiting to go out the various tcp_* channels, this would not be efficient. It is much more likely that one would want to define additional pools for the additional tcp_* channels so that there is no contention for slots.

For example, suppose we set up the following tcp_* channels:

tcp_yahoo smtp mx pool yahoo_pool keyword keyword keyword
tcp-yahoo-daemon

tcp_aol smtp mx keyword keyword keyword pool aol_pool
tcp-aol-daemon

tcp_hotmail smtp mx pool hotmail_pool keyword keyword keyword 
tcp-hotmail-daemon
...
tcp_sun smtp mx pool sun_pool keyword keyword keyword
tcp-sun-daemon

In order to add have ten tcp_smtp_client processes for each of the new channels we would add the following in the job_controller.cnf file:

[POOL=yahoo_pool]
job_limit=10

[POOL=aol_pool]
job_limit=10

[POOL=hotmail_pool]
job_limit=10

 ...

[POOL=sun_pool]
job_limit=10

For more information about pools, see 12.5.4 Processing Pools for Channel Execution Jobs.