Diagnosing .HELD files

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


The causes of .HELD files can be considered to fall into three major categories:

  1. Messages .HELD due to a user status 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, (e.g., while moving user mailboxes).
  2. 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.
  3. 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 option), due to exceeding max_mime_levels or max_mime_parts if such an MTA option has been set to a negative integer, due to an MTA administrator imsimta qclean, imsimta qm clean or imsimta qm hold command executed by the MTA administrator based on some suspicion of the message(s) in question, due to use of a "hold" action in a Sieve script or spam/virus filter package action, due to use of a Milter SMFIF_QUARANTINE action (or explicit "hold;" in a QUARANTINE_ACTION Milter plugin option), or due to a conversion command script exit status of PMDF__FORCEHOLD.

When diagnosing the reason why a particular message or messages are .HELD, consider the following:write file

  1. All messages .HELD due to a user status 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.
  2. 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 especially carefully at the hostnames and any recipient address information (e.g., "for recipient" clauses or "(ORCPT recipient)" comments) appearing in such header lines. One cause of such message loops is user error: a user forwards their messages on system A to system B, and has system B set up to forward back to system A. (The solution is for the user to fix their forwarding definitions.) 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"; more on this below). Or another possible cause is missing or erroneous host table entries or DNS records that cause routing back to the MTA of addresses in domains not intended to be handled by this MTA. (The solution in such a case should be to correct the name records at the TCP/IP level; when that can not be achieved, some host table or nameserver problems can be worked around by special routing configuration on the MTA, though solving any underlying name problems is preferable.) Note that the MTA's thresholds for determining that a message is likely "looping" are configurable; see Received header line MTA options. Also note that the MTA may optionally be configured---see the held_sndopr MTA option---to generate a syslog notice whenever a message is forced into .HELD state due to exceeding such a threshold. If syslog messages of HELDMSG, Header count exceeded; message has been marked .HELD automatically are present, then you know that this is occurring.
  3. Messages .HELD due to some suspicious characteristic will of course exhibit that characteristic---though 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 option, any use of the $H flag in the FROM_ACCESS mapping table or a recipient-address-based *_ACCESS mapping table, any negative value for the max_mime_levels or max_mime_parts MTA options, or any use of the "hold" action in any system Sieve file (the systemfilter MTA option/system level imta.filter file, or any channel level Sieve filters configured and named via use of sourcefilter or destinationfilter channel options) or spam/virus filter package action's Sieve scriptlet, or (when using a milter) use of the SMFIF_QUARANTINE milter action, or use of the conversion channel with a script that exits with the status PMDF__FORCEHOLD. Also ask any fellow MTA administrators about any manual command line side-lining (via, for instance, a 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 in MTA message transaction logging; see the log_filter MTA option. (As of MS 8.0 with its new, private Sieve "transactionlog" extension, MTA administrators may wish to make use of the "transactionlog" action in any Sieve filter that performs a "hold" action, to record details regarding the reason(s) that the "hold" was performed.)


See also: