Messaging Server: Diagnosing and Cleaning Up .HELD Files
By Joesciallo-Oracle on May 18, 2007
Many mail administrators are very familiar with .HELD message files in Messaging Server, how they are a separate case from "regular" message files, and how you have to deal with them manually.
Now, I'll be the first to admit that I'm a Messaging Server neophyte, but fortunately, I get 'hang' with the experts (if only virtually). Here's a great recap on .HELD messages that I'm passing along (stealing outright) that I think will prove useful for both the seasoned and novice mail administrator.
Diagnosing and Cleaning up .HELD Files.HELD files can occur due to three major reasons:
- Messages .HELD due to a user or domain status of "hold". These are messages that are, by intent of the MTA administrator, intentionally being side-lined, typically while some maintenance procedure is being performed, (for example, while moving user mailboxes).
- Looping messages: messages that the MTA side-lined as .HELD because the MTA detected (via build-up of one or another sort of \*Received: header lines) that the messages were looping.
- Suspicious messages: messages that met some suspicion threshhold, and were therefore side-lined as .HELD for later, manual inspection and action by the MTA administrator. Messages can be side-lined as .HELD due to exceeding a configured maximum number of envelope recipients (see the holdlimit channel keyword), due to running the imsimta qclean, imsimta qm clean or imsimta qm hold commands based on some suspicion of the message(s) in question, or due to use of a "hold" action in a Sieve script.
When diagnosing the reason why a particular message or messages are .HELD, consider the following:
- All messages .HELD due to a user or domain status of "hold"--and only messages .HELD for such a reason--will normally be stored in the hold channel's queue area. That is, .HELD message files in the hold channel's queue area can be assumed to be .HELD due to user or domain status.
- Messages .HELD due to the MTA having detected that they were looping can be
expected to have a great many of one or another sort of \*Received: header lines,
when inspected. Furthermore, those Received: header lines typically illustrate the
exact path of the message loop: look carefully at the host names and any
recipient address information (for example, "for recipient" clauses or "(ORCPT recipient)" comments) appearing in such header lines. One cause of such message loops is user
error. A user forwards messages on system A to system B, and has system B set
up to forward back to system A. (If this is the case, users need to fix their
Another common cause of message loops is the MTA receiving a message that was addressed to the MTA host using a network name that the MTA does not recognize (has not been configured to recognize) as one of its own names. The solution is to add the additional name to the list of names that your MTA recognizes as "its own". Note that the MTA's threshholds for determining that a message is likely "looping" are configurable; see the MAX_\*RECEIVED_LINES option.dat options. Also note that the MTA may optionally be configured--see the HELD_SNDOPR global MTA option--to generate a syslog notice whenever a message is forced into .HELD state due to exceeding such a threshhold. If syslog messages of
Received count exceeded; message held.are present, then you know that this is occurring.
- Messages .HELD due to some suspicious characteristic will of course exhibit that characteristic--through a priori that characteristic could be anything which the site has chosen to characterize as "suspicious". If you are an administrator of the MTA, you should attempt to stay reasonably aware of whatever such configuration choices and actions have been taken on your MTA. However, if you are not the only or original administrator of this MTA, then check the MTA configuration for any configured use of the holdlimit channel keyword, any use of the $H flag in address-based \*_ACCESS mapping tables in the MTA mappings file, or any use of the "hold" action in any system Sieve file (the system level imta.filter file, or any channel level Sieve filters configured and named via use of sourcefilter or destinationfilter channel keywords); and ask any fellow MTA administrators about any manual command line side-lining (via, for instance, an imsimta qm clean command) they might have recently performed. Note also that application of a Sieve filter "hold" action, whether from a system Sieve filter or from users' personal Sieve filters, may optionally be logged; see the LOG_FILTER global MTA option (see Table 4-16 in the Sun Java System Messaging Server 6.3 Administration Reference) for more information.