This chapter describes Oracle Communications Messaging Server general MTA services and configuration in Unified Configuration.
In a legacy configuration, you manage the MTA configuration by editing various text files. In Unified Configuration, you manage the MTA configuration by using the msconfig command. The Unified Configuration stores the MTA configuration in a single file, config.xml (for the most part). The msconfig command performs syntax validation on option names and values as well as the Unified Configuration structure to a limited degree. See "msconfig Command" for more information about the msconfig command syntax and options.
Caution:
Only edit your Unified Configuration by running the msconfig command. This saves old configurations and allows for rollback. Do not hand-edit any of the Unified Configuration files. Oracle Support may occasionally edit these files to work around any issues pertaining to msconfig.Table 8-1 provides a comparison of how the MTA configuration is managed in legacy and Unified Configuration.
Table 8-1 MTA Configuration: Legacy Versus Unified Configuration
| Legacy Configuration Files | Unified Configuration Method |
|---|---|
|
mappings file |
Running msconfig edit mappings loads mappings in legacy format in the administrator's chosen editor. |
|
imta.cnf file |
Running msconfig edit channels loads channel blocks in legacy format in the administrator's chosen editor. Running msconfig edit rewrite loads rewrite rules in legacy format in the administrator's chosen editor. |
|
option.dat file |
Get or set options directly by running msconfig. |
|
job_controller.cnf file |
Get or set options directly by running msconfig; most options require job_controller prefix. |
|
dispatcher.cnf file |
Get or set dispatcher options; most require a dispatcher. prefix, service-specific settings are in a service:name group, such as service:SMTP.tcp_ports. |
|
conversions file |
Run msconfig edit conversions. |
|
aliases file |
Run msconfig edit aliases. |
This section includes the following topics:
When using a compiled MTA configuration, note the following:
The dispatcher configuration, job controller configuration, and channel-specific options are part of the compiled configuration.
The configure command does not generate a compiled configuration by default, for both legacy configuration and Unified Configuration.
Unified Configuration provides the -xmlfile= switch for use in testing tools on a non-live configuration. (This was previously only possible with a compiled configuration.)
The imsimta version command shows if a compiled configuration is used or not.
When using a compiled configuration, whenever you make a change to the MTA configuration, such as to mappings, rewrite rules, channels, aliases, conversions, dispatcher configuration, job controller configuration, or channel-specific options, you must recompile your configuration for the changes to take effect. Compilation reads the entire configuration and writes it out as a single binary file.
Whenever a component of the MTA (such as a channel program) must read the configuration file, it first checks to see if a compiled configuration exists. If it does, the image is loaded instead of reading the various configuration files.
You use the imsimta cnbuild command to compile the MTA configuration.
Prior to Messaging Server 7.0.5, two MTA Tailor options were relevant for imsimta cnbuild: imta_config_data specified the default output image file, and imta_config_option_file specified an option file adjusting configuration internal table sizes. As of Messaging Server 7.0.5, these MTA Tailor options have been deleted, and the following hard-coded file paths are used instead: server_root/config/advanced/config_data and server_root/lib/option_config.dat, where server_root is the value of the SERVERROOT environment variable.
Compiled configurations have a static part and a dynamic reloadable part. If the dynamic part is changed, and you run the imsimta reload command, all running MTA processes reload the dynamic data. The dynamic parts are presently the mapping tables and text databases. Everything else is static.
Using a compiled configuration makes it easy to test configuration changes because the configuration files themselves do not "go live" until they are compiled. Most MTA test utilities provide a -noimage switch, which tells them to ignore the compiled configuration and instead read the configuration from the original files. This lets you test things to make sure they are working before affecting the running system.
If you make changes to the reverse, forward, or general databases, then issue the command imsimta reload to get the changes to take effect. If you make changes to rewrite rules, channel blocks, mappings, aliases, conversions, or job controller options, then you should issue an imsimta cnbuild command followed by an imsimta restart smtp command. If you make changes to dispatcher options, you must run an imsimta restart dispatcher command. If you make changes to options 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.
If you make changes to options that are included in the compiled configuration that affect both the SMTP server and the job controller, you should issue the following commands:
imsimta cnbuild imsimta restart smtp imsimta restart job_controller
(See "MTA Commands" for details on these commands.)
The imsimta reload command also reloads authentication, SSL/TLS, and affinity group options. This is done even if the MTA's configuration is not compiled.
Other instances where you must restart the job controller:
Changing the job controller configuration.
Adding or changing use of the channel options pool, maxjobs, master, slave, single, single_sys, or multiple. Adding or changing a threaddepth channel option can be dealt with instead by running the imsimta cache -change -thread_depth=... command.
If you want changes to master channel jobs to take effect immediately (rather than waiting for the controller to time-out existing channel jobs), then any relevant (which means almost all) changes to the MTA configuration or channels. (Changes to mappings or to MTA databases: (1) are not usually relevant for outbound channel jobs, though they can matter to "intermediate" channels such as conversion, process, reprocess, and (2) if those intermediate channels are a concern, changes to mappings or to databases can often be handled by running the imsimta reload command, avoiding a restart of the Job Controller.) The desire to have changes take effect immediately needs to be balanced against the damage that restarting the Job Controller does. Also consider just how much longer a particular sort of job is going to run anyhow.
Any changes (such as additions or changes to options on channel definitions) also require running the imsimta cnbuild command. That's a basic, regardless of whether a Job Controller restart is needed.
Try to avoid restarting the Job Controller, especially at times of large numbers of messages in the queues, unless one of the preceding conditions necessitates a restart.
For more information on MTA services see Messaging Server Reference.