When the MTA fails to start, general error messages appear at the command line. In this section, common general error messages will be described and diagnosed.
To diagnose your own MTA configuration, use the imsimta test -rewrite -debug utility to examine your MTA’s address rewriting and channel mapping process. By using this utility allows you to check the configuration without actually sending a message. See 26.2.1 Check the MTA Configuration.
MTA subcomponents might also issue other error messages that are not described in this chapter. You should refer to the chapters on MTA command-line utilities and configuration in the Sun Java System Messaging Server Administration Reference and chapters 5 through 10 for more information on each subcomponent. This section includes the following types of errors:
An error in mm_init generally indicates an MTA configuration problem. If you run the imsimta test -rewrite utility, these errors will be displayed. Other utilities like imsimta cnbuild, a channel, a server, or a browser might also return such an error.
Commonly encountered mm_init errors include:
Two alias file entries have the same left hand side. You will need to find and eliminate the duplication. Look for an error message that says error line #XXX where XXX is a line number. You can fix the duplicated alias on the line.
Note that an extraneous blank line in the rewrite rules (upper portion) of your MTA configuration file (imta.cnf) causes the MTA to interpret the remainder of the configuration file as channel definitions. Make sure that the very first line of the file is not a blank. Since there are often multiple rewrite rules with the same pattern (left-hand side), this then causes MTA to interpret them as channel definitions with non-unique official host names. Check your MTA configuration for any channel definitions with duplicate official host names and for any improper blank lines in the upper (rewrite rules) portion of the file.
This message indicates that two mapping tables have the same name, and one of the duplicate mapping tables needs to be removed. However, formatting errors in the mapping file may cause the MTA to wrongly interpret something as a mapping table name. For example, failure to properly indent a mapping table entry will cause the MTA to think that the left hand side of the entry is actually a mapping table name. Check your mapping file for general form and check the mapping table names.
A blank line should precede and follow any line with a mapping table name. However, no blank lines should be interspersed among the entries of a mapping table.
This error means that a mapping table name is too long and needs to be shortened. Formatting errors in the mapping file may cause the MTA to wrongly interpret something as a mapping table name. For example, failure to properly indent a mapping table entry will cause the MTA to think that the left hand side of the entry is actually a mapping table name. Check your mapping file and mapping table names.
If you see this message, you need to recompile and reinstall your compiled character set tables through the command imsimta chbuild. See the imsimta chbuild in Sun Java System Messaging Server 6.3 Administration Reference for more information.
This error message generally means that you need to resize your MTA character set internal tables and then rebuild the compiled character set tables with the following commands:
imsimta chbuild -noimage -maximum -option imsimta chbuild
Verify that nothing else needs to be recompiled or restarted before making this change. Refer to imsimta chbuild in Sun Java System Messaging Server 6.3 Administration Reference for more information on imsimta chbuild.
This error indicates that a local host alias or proper name is too long (the optional right hand side in the second or subsequent names in a channel block). However, certain syntax errors earlier in the MTA configuration file (an extraneous blank line in the rewrite rules, for instance) may cause MTA to wrongly interpret something as a channel definition. Aside from checking the indicated line of the configuration file, also check above that line for other syntax errors. In particular, if the line in which MTA issues this error is intended as a rewrite rule, then be sure to check for extraneous blank lines above it.
This error indicates that a channel definition block is missing the required second line (the official host name line). See the chapters on MTA configuration and command-line utilities in the Sun Java System Messaging Server Administration Reference and Chapter 12, Configuring Channel Definitions for more information on channel definition blocks. A blank line is required before and after each channel definition block, but a blank line must not be present between the channel name and official host name lines of the channel definition. Also note that blank lines are not permitted in the rewrite rules portion of the MTA configuration file.
The official host name for a channel (second line of the channel definition block) is limited to 128 octets in length. If you are trying to use a longer official host name on a channel, shorten it to a place holder name, and then use a rewrite rule to match the longer name to the short official host name. You may see this scenario if you work with the l (local) channel host name. For example:
Original l Channel: !delivery channel to local /var/mail store l subdirs 20 viaaliasrequired maxjobs 7 pool LOCAL_POOL walleroo.pocofronitas.thisnameismuchtoolongandreallymakesnosensebutitisan example.monkey.gorilla.orangutan.antidisestablismentarianism.newt.salaman der.lizard.gecko.komododragon.com Create Place Holder: !delivery channel to local /var/mail store l subdirs 20 viaaliasrequired maxjobs 7 pool LOCAL_POOL newt Create Rewrite Rule: newt.salamander.lizard.gecko.komododragon.com $U%$D@newt
Note that when using the l (local) channel, you will need to use a REVERSE mapping table. Refer to the MTA configuration chapter in the Sun Java System Messaging Server Administration Reference for information on usage and syntax.
Certain syntax errors earlier in the MTA configuration file (for example, an extraneous blank line in the rewrite rules) may cause the MTA to wrongly interpret something as a channel definition. This could result in an intended rewrite rule being interpreted as an official host name. Besides checking the indicated line of the configuration file, also check above that line for other syntax errors. In particular, if the line on which the MTA issues this error is intended as a rewrite rule, be sure to check for extraneous blank lines above it.
One of the functions of the imsimta cnbuild utility is to compile MTA configuration information into an image that can be quickly loaded. The compiled format is quite rigidly defined and often changes substantially between different versions of the MTA. Minor changes might occur as part of patch releases.
When such changes occur, an internal version field is also changed so that incompatible formats can be detected. The MTA components will halt with the above error when an incompatible format is detected. The solution to this problem is to generate a new, compiled configuration with the command imsimta cnbuild.
It is also a good idea to use the imsimta restart command to restart any resident MTA server processes, so they can obtain updated configuration information.
To ensure proper operation, it is important to configure enough swap space on your messaging system. The amount of required swap space will vary depending on your configuration. A general tuning recommendation is that the amount of swap space should be at least three times the amount of main memory.
An error message such as the following indicates a lack of swap space:
jbc_channels: chan_execute : fork failed: Not enough space
You might see this error in the Job Controller log file. Other swap space errors will vary depending on your configuration.
Solaris systems: swap -s (at the time MTA processes are busy), ps -elf, or tail /var/adm/messages
HP-UX systems: swapinfo or tail /var/adm/syslog/syslog.log
In order to send a message, the MTA reads configuration files and creates message files in the MTA message queue directories. Configuration files must be readable by the MTA or any program written against the MTA’s SDKs. During installation, proper permissions are assigned to these files. The MTA utilities and procedures which create configuration files also assign permissions. If the files are protected by the system manager, other privileged user, or through some site-specific procedure, the MTA may not be able to read configuration information. This will result in “File open” errors or unpredictable behavior. The imsimta test -rewrite utility reports additional information when it encounters problems reading configuration files. See imsimta test in Sun Java System Messaging Server 6.3 Administration Reference.
If the MTA appears to function from privileged accounts but not from unprivileged accounts, then file permissions in the MTA table directory are likely the cause of the problem. Check the permissions on configuration files and their directories. See 26.2.3 Check the Ownership of Critical Files.
“File create” errors usually indicate a problem while creating a message file in an MTA message queue directory. See 26.2.2 Check the Message Queue Directories to diagnose file creation problems.
You may see this error when an address is provided to the MTA through a browser. Or, the error may be deferred and returned as part of an error return mail message. In both cases, this error message indicates that the MTA is not able to deliver mail to the specified host. To determine why the mail is not being sent to the specified host, you should follow these troubleshooting procedures:
Verify that the address in question is not misspelled, is not transcribed incorrectly, or does not use the name of a host or domain that no longer exists.
Run the address in question through the imsimta test -rewrite utility. If this utility also returns an “illegal host/domain” error on the address, then MTA has no rules in the imta.cnf file and related files to handle the address. Verify that you have configured MTA correctly, that you answered all configuration questions appropriately, and that you have kept your configuration information up to date.
If imsimta test -rewrite does not encounter an error on the address, then MTA is able to determine how to handle the address, but the network transport will not accept it. You can examine the appropriate log files from the delivery attempt for additional details. Transient network routing or name service errors should not result in returned error messages, though it is possible for badly misconfigured domain name servers to cause these problems.
If you are on the Internet, check that you have properly configured your TCP/IP channel to support MX record lookups. Many domain addresses are not directly accessible on the Internet and require that your mail system correctly resolve MX entries. If you are on the Internet and your TCP/IP is configured to support MX records, you should have configured the MTA to enable MX support; see TCP/IP Connection and DNS Lookup Support 12.4.3 TCP/IP Connection and DNS Lookup Support for more information. If your TCP/IP package is not configured to support MX record lookups, then you will not be able to reach MX-only domains.
Errors such as the following are not necessarily MTA errors: os_smtp_* errors like os_smtp_open, os_smtp_read, and os_smtp_write errors. These errors are generated when the MTA reports a problem encountered at the network layer. For example, an os_smtp_open error means that the network connection to the remote side could not be opened. The MTA may be configured to connect to an invalid system because of addressing errors or channel configuration errors. The os_smtp_* errors are commonly due to DNS or network connectivity problems, particularly if this was a previously working channel or address. os_smtp_read or os_smtp_write errors are usually an indication that the connection was aborted by the other side or due to network problems.
Network and DNS problems are often transient in nature. The occasional os_smtp_* error is usually nothing to be concerned about. However, if you are consistently seeing these errors, it may be an indication of an underlying network problem.
To obtain more information about a particular os_smtp_* error, enable debugging on the channel in question. Investigate the debug channel log file that will show details of the attempted SMTP dialogue. In particular, look at the timing of when a network problem occurred during the SMTP dialogue. The timing may suggest the type of network or remote side issue. In some cases, you may also want to perform network level debugging (for example, TCP/IP packet tracing) to determine what was sent or received.