Ims-ms channel error messages
MTA channels attempting to deliver to the Message Store, i.e.,
ims-ms channels or
tcp_lmtpcs* channels, can encounter several different sorts of issues: initialization errors (errors initializing the MTA, the Message Store, Message Store notify plugin code (if
notifytarget named group options are set in Unified Configuration, or the
local.store.notifyplugin configutil parameter is set in legacy configuration), domain map code, or LDAP pool code) many of which will cause the channel to abort, subsequent Message Store errors, subsequent trouble getting LDAP information about a domain or user, or IMAP error statuses when attempting to deliver particular messages. When encountering a problem doing an LDAP lookup for a domain or user while attempting to deliver a message, or an IMAP error status on a particular message, the MTA channel keeps running (and moves on to attempting to deliver any other messages awaiting delivery).
In particular, the IMAP error statuses reported by an
ims-ms channel or LMTP server, when it attempts to access or manipulate the Message Store, are not specific to such channels, but rather are general IMAP error statuses (which may also be seen in other contexts, such as IMAP e-mail client attempts to access or manipulate the Message Store). Additional details on the underlying Message Store issue that gave rise to an IMAP error status may be available in the Message Store NSLOG logging for the component which encountered the issue; in the case of the
ims-ms channel or LMTP server, see the
imta NSLOG file discussed in ims-ms channel debugging and error logging.
Some IMAP error statuses are considered "permanent" errors: a message will be immediately bounced, if such an error is encountered. Other IMAP error statuses are considered "temporary" errors: a message will be retained in the MTA channel queue (
ims-ms or LMTP client
tcp_lmtpcs* channel) for further delivery attempts. See IMAP error statuses for a full listing of IMAP errors, or see IMAP error statuses relvant to the MTA for the subset of IMAP errors relevant to the MTA, and in particular relevant to the
ims-ms and LMTP channels. (Note that in the case of LMTP, the IMAP error status is encountered by the LMTP server on a Message Store back end, which then reports the error to the LMTP client running on a "front end" MTA. So in the LMTP case, such errors may be reported in the LMTP server's message transaction log file, in an LMTP server log file, and also as a reported LMTP error in the LMTP client's log file or in the message transaction log file of the "front end" MTA running the LMTP client channel.)
|Delivery permanent errors|
|IMAP_INVALID_USER||Permanent||Invalid user||The recipient address did not parse into syntactically valid uid, channel part, and optionally domain and/or folder portions|
|IMAP_QUOTA_EXCEEDED_PERSISTENT||Permanent||Over quota||The user has exceeded their configured quota for more than the configured grace period.|
|IMAP_MESSAGE_TOO_LARGE||Permanent||Message too large||Message is larger than the user's entire quota (mailQuota).|
|IMAP_MAILBOX_NONEXISTENT||Permanent||Mailbox does not exist||(Recall that these error messages are general IMAP error messages, that may occur in other contexts besides ims-ms channel or LMTP channel delivery.) When this error occurs in the context of an ims-ms or LMTP channel delivery, the meaning is as follows. Normally, the ims-ms channel and LMTP server tcp_lmtpss* channel will create a mailbox, if it does not exist. And when delivery to a specific folder is being attempted due to a Sieve "fileinto" action, and the folder does not exist, the channel will attempt to create the folder. (If the folder part of the address was not generated by the user's Sieve filter nor world writeable, then the channel will log a General facility, Information level notice to the imta file saying "append_setup path failed, trying INBOX:" followed by the IMAP_MAILBOX_NONEXISTENT error text. If the folder part was due to the user's Sieve filter but the folder could not be created, then the channel will log a General facility, Error level notice to the imta file saying "mboxlist_createmailbox path failed, trying INBOX:" with the specific IMAP error text.) But if the partition is bogus, then this error will be returned.|
|IMAP_MESSAGE_CONTAINSNULL||Permanent||Message contains NUL characters||(A message that has gone through the MTA will not normally cause such an error, as the MTA will normally legalize message content.)|
|IMAP_MESSAGE_CONTAINSNL||Permanent||Message contains bare newlines||(A message that has gone through the MTA will not normally cause such an error, as the MTA will normally canonicalize message content resulting in proper use of CRLF for line breaks, and encoded newlines in binary content; see the discussion of the lmtp* and smtp* channel options.)|
|IMAP_MESSAGE_BADHEADER||Permanent||Message contains invalid header|
|IMAP_MESSAGE_NOBLANKLINE||Permanent||Message has no header/body separator||(A message that has gone through the MTA will not normally cause such an error, as the MTA will normally legalize messages one way or another; see the *headertermination channel options.)|
|IMAP_CONFIG_ERROR||Permanent||Configuration error||Returned if either LDAP pool code, or the domain map code, cannot be initialized. (Note that normally such initialization is done when the ims-ms channel first starts up, and when the LMTP server first starts up, and errors initializing at that time will cause the channel or server to exit. So this is not expected to occur for the ims-ms channel and LMTP server tcp_lmtpss* channel at this later, message processing, stage.)|
|IMAP_PROXY_ONLY||Permanent||Server is not configured for local users|
|IMAP_WRONG_MAILHOST||Permanent||Mailbox is on a different server||This suggest that either the user's LDAP entry is missing a mailHost attribute entirely, or their mailHost has been changed (their mailbox has been moved) while old messages were awaiting delivery in the ims-ms channel queue area, or that there is an error in the MTA configuration (causing it to attempt to deliver a message on the wrong mailHost), or operator error whereby messages have been manually moved (incorrectly) from one host to another.|
|IMAP_MAILBOX_BADNAME||Permanent||Invalid mailbox name|
|Delivery temporary errors|
|IMAP_MAILBOX_LOCKED||Temporary||Mailbox is busy||The mailbox was locked. When this status is encountered, the MTA delivery channel (ims-ms or tcp_lmtpcs*) first retries 10 times at 100 millisecond intervals (before this error is ever even reported back from the channel). Prior to 8.0, lock attempts were nonblocking; a 1 second time is used in 8.0 or later. If the mailbox remains locked, then the channel gives up on this delivery attempt, generating a "Q" record with the "Mailbox is busy" reason if logging is enabled. And then there is special code in the ims-ms channel (and as of MS 7.0 in the LMTP client channel) to ask the Job Controller to retry delivery again very, very soon---with a randomly generated backoff of between one second and two minutes---overriding the normal *backoff values. Occasional occurrences of such a temporary error are normal, as for instance if a user is logged in and performing extensive, time-consuming operations on a mailbox; indeed, it is because an occasional such occurrence is "normal" that the delivery channels have special code to handle this (usually transient) error condition by retrying delivery very soon. However, persistent occurrences for the same user might suggest a problem with that user's mailbox. Or, if such errors suddenly start occurring at around the same time for all (or many) users, that could be a suggestion of some more widespread and general problem with the Message Store.|
|IMAP_MAILBOX_BADFORMAT||Temporary||Mailbox has an invalid format||The mailbox may be corrupted.|
|IMAP_MAILBOX_NOTSUPPORTED||Temporary||Operation is not supported on mailbox||The mailbox may be corrupted.|
|IMAP_IOERROR||Temporary||System I/O error. Administrator, check server log for details.||The Message Store may be corrupted, or otherwise inaccessible (e.g., disk not mounted); or the Message Store store.idx file may have reached its 2 gigabyte size limit.|
|IMAP_PARTITION_UNKNOWN||Temporary||Unknown/invalid partition||The user's mailMessageStore LDAP attribute does not correspond to a partition-name defined via a path partition option in Unified Configuration (a store.partition.partition-name.path configutil parameter in legacy configuration), or the value of that option or configutil parameter does not point to a valid location, or contains invalid characters (only alphanumeric characters are allowed). (If a user does not have a mailMessageStore set at all, then the Message Store's default partition, defaultpartition Message Store option in Unified Configuration or store.defaultpartition configutil parameter in legacy configuration, is assumed, which defaults to primary. When the absence of an explicit mailMessageStore is causing use of the default partition, then whatever the default partition is, it must then have a valid path specified in the path option for that named partition in Unified Configuration (partititon:whatever.path) or the store.partition.whatever.path configutil parameter; in particular, when store.defaultpartition has its default value of primary, then the primary partition must have a valid path specified in partition:primary.path in Unified Configuration or store.partition.primary.path in legacy configuration.)|
|IMAP_PARTITION_FULL||Temporary||Store partition is full||See also the (new in MS 6.2) configutil parameters local.store.checkdiskusage and local.store.diskusagethreshold (initially instead named local.store.diskthreshold in MS 6.2), or in Unified Configuration the checkdiskusage and diskusagethreshold Message Store options, which control whether---and when---the store performs checks on its disk space usage. With such checks enabled, the store will "lock" a partition (at which point the IMAP_PARTITION_FULL error will be returned) slightly before the partition is actually filled up. This is a safety measure, to ensure that expunge operations (which need to rewrite the index files) have disk room in which to operate.|
|IMAP_QUOTA_EXCEEDED||Temporary||Over quota||The recipient has exceeded their configured quota, but for less than the configured grace period.|
|Other statuses (not seen by ims-ms channels or LMTP channels)++|
|IMAP_USERFLAG_EXHAUSTED||Too many keywords in mailbox|
|IMAP_MAILBOX_EXISTS||Mailbox already exists||When attempting to create a folder, this is a success status|
|IMAP_MAILBOXLIST_NONEXISTENT||Mailbox list does not exist|
|IMAP_INVALID_IDENTIFIER||Invalid identifier||May occur when attempting to set an ACL on a folder|
|IMAP_INVALID_MSGNO||Invalid message number|
|IMAP_QUOTAROOT_NONEXISTENT||Quota root does not exist|
+The IMAP error text is localizable. The text shown in this table is merely the default text (which happens to be English).
The IMAP delivery temporary error statuses listed in IMAP error statuses relevant to the MTA may appear in the "history" field of messages that failed a delivery attempt; this is visible via, for instance, the
history command of the
imsimta qm utility, as well as being physically present in the history field in the deferred message files awaiting further delivery attempts in the MTA
ims-ms channel disk queue area or
tcp_lmtpcs* channel disk queue area. (Should a message eventually bounce due to "timing out", such history information may also be included in the bounce message, as controlled by the
history_to_return MTA option.) Furthermore, the temporary error text will be included in the
ims-ms channel's "
Q" record in the MTA message transaction log file, should such logging be enabled via use of the
logging channel option.
The IMAP delivery permanent error statuses shown in IMAP error statuses will appear in the
ims-ms channel's or
tcp_lmtpcs* channel's "
R" or "
K" record in the MTA message transaction log file, should such logging be enabled via use of the
logging channel option.
As with other types of channel processes, the
ims-ms channel processes do not have an infinite life time: after running for a (configurable) while, they shut down (and the Job Controller will start up new
ims-ms channel processes, as needed). The Job Controller options
max_life_conns, respectively, in legacy configuration) and the
ims-ms channel's own 60 seconds limit on time to persist while idle, control the timing of the
ims-ms channel process "recycling". In addition, an administrator
restart of the Job Controller will cause the Job Controller to tell channel processes to shut down. So notices in the
imta log file such as the following are part of normal operation:
At Notice level:
product ims_master version shutting down product ims_master version starting up
And at Debug level: When the
ims-ms channel process' threads have all been idle for 60 seconds or more (or are deadlocked):
When a thread is exiting due to having no work to do:
When the Job Controller is telling a process to shut down due to the process having gotten old:
EOF from job controller
And after an administrator
restart of the Job Controller, the following sorts of messages can also be expected in the
imta file. At Debug level:
When the Job Controller is telling a process to shut down due to an administrator
exit from job controller mta-status
A message (at Warning level) of
Shutdown timeout, possible deadlock
however, is an indication that one or more threads in a process attempting to shut down have not been able to finish their work. If this error repeats, it may indicate that a mailbox is corrupted or locked.
In an MTA message transaction log file "
Q" or "
Z" record, a reason of "
shutdown" indicates that a delivery attempt for that recipient is being deferred due to a shutdown in progress---either an administrator's manual shutdown, or a shutdown due to a channel process "timing out".
- ims-ms channels
- LMTP channels
- LMTP client TCPIP channels
- The Message Store
- notifytarget options
- IMAP error statuses
- lmtp Option
- smtp Option
- limitheadertermination Option
- quotagraceperiod Store Option
- Sieve fileinto action
- MTA transaction log entry format
- logging Option
- log_reason MTA Option
- Job Controller
- backoff Option
- defaultpartition Store Option
- checkdiskusage Store Option
- diskusagethreshold Store Option
- history_to_return MTA Option
- ims-ms channel debugging and error logging