Ims-ms channel error messages

From Messaging Server Technical Reference Wiki
Jump to: navigation, search


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

IMAP error statuses relevant to the MTA
Name Type Text+ Meaning
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_PERMISSION_DENIED Permanent Permission denied  
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).

++For completeness, additional IMAP statuses are listed, though they are not normally relevant (do not normally appear) as ims-ms channel or LMTP channel delivery error statuses.


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_time and max_life_askwork (max_life_age and 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):


idle shutdown 

When a thread is exiting due to having no work to do:


Tthread-number exiting 

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:


shutdown received 

When the Job Controller is telling a process to shut down due to an administrator restart command:


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


See also: