This chapter describes 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. For more information on the syntax and options for the msconfig command, see "msconfig Command."
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 7-1 provides a comparison of how the MTA configuration is managed in legacy and Unified Configuration.
Table 7-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:
The following changes for compiled MTA configurations were introduced:
The configure command no longer generates a compiled configuration by default, for both legacy and Unified Configuration.
Unified Configuration provides the -xmlfile= switch to use test tools on a non-live configuration. (This was previously only possible with a compiled configuration.)
The imsimta version command now shows if a compiled configuration is used or not.
Whenever you make a change to the MTA configuration, such as to mappings, rewrite rules, channel blocks, aliases, and so on, you must recompile the configuration, if you are using a compiled configuration. This compiles the configuration files into a single image in shared memory.
The compiled configuration has a static and dynamic reloadable part. If the dynamic part is changed, and you run the imsimta reload command, a running program reloads the dynamic data. The dynamic parts are mapping tables, aliases, and lookup tables.
Using a compiled configuration enables you to be able to test configuration changes more conveniently because the configuration files themselves are not "live" when a compiled configuration is in use.
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 attached to the running program. If the image attach operation fails, the MTA falls back on reading the config.xml 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. 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 need to do 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.)
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) aren't 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 the Messaging Server Reference.