Diagnosing .HELD files
From Messaging Server Technical Reference Wiki
The causes of
.HELD files can be considered to fall into three major categories:
.HELDdue 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).
Looping messages: messages that the MTA side-lined as
.HELDbecause 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
.HELDfor later, manual inspection and action by the MTA administrator. Messages can be side-lined as
.HELDdue to exceeding a configured maximum number of envelope recipients (see the
holdlimitchannel option), due to exceeding
max_mime_partsif such an MTA option has been set to a negative integer, due to an MTA administrator
imsimta qm cleanor
imsimta qm holdcommand 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_ACTIONMilter plugin option), or due to a conversion command script exit status of
When diagnosing the reason why a particular message or messages are
.HELD, consider the following:write file
.HELDdue to a user status or domain status of "
hold"---and only messages
.HELDfor such a reason--- will normally be stored in the hold channel's queue area. That is,
.HELDmessage files in the hold channel's queue area can be assumed to be
.HELDdue to user or domain status.
.HELDdue 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., "
recipient" clauses or "
)" 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_sndoprMTA option---to generate a syslog notice whenever a message is forced into
.HELDstate 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.
.HELDdue 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
holdlimitchannel option, any use of the
$Hflag in the
FROM_ACCESSmapping table or a recipient-address-based
*_ACCESSmapping table, any negative value for the
max_mime_partsMTA options, or any use of the "
hold" action in any system Sieve file (the
systemfilterMTA option/system level
imta.filterfile, or any channel level Sieve filters configured and named via use of
destinationfilterchannel 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 cleancommand) 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_filterMTA 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.)
- ldap_user_mail_status MTA Option
- ldap_domain_attr_mail_status Option
- Received header line MTA options
- holdlimit Option
- max_mime_levels MTA Option
- max_mime_parts MTA Option
- qclean utility
- Sieve hold extension
- spamfilter1_action_0 MTA Option
- Milter implementation
- Milter spamfilterN_config_file
- Milter operation
- Conversion script exit statuses
- Sieve transactionlog extension
- Releasing messages from the hold channel
- Hold channel