Diagnosing .HELD files

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



 Messages  due to a    user status or    domain status of    " ": 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     because the MTA detected (via    build-up of one or    another sort of &#x2a;Received: header lines) that the messages were looping. 

 Suspicious messages: messages that met some suspicion threshhold,   and were therefore side-lined as   for later, manual    inspection and action by the MTA administrator. Messages can be   side-lined as   due to exceeding a configured maximum    number of envelope recipients (see the     channel    option),    due to exceeding      or   if such an    MTA option has been set to a negative integer, due to an MTA    administrator    ,   or   command executed by the    MTA administrator based on some suspicion of the message(s) in    question, due to use of a    " " action in a    Sieve script or    spam/virus filter package action,    due to use of a     Milter SMFIF_QUARANTINE action   (or explicit " " in a       Milter plugin option), or due to a    conversion command script exit    status of. 



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



 All messages  due to a    user status or    domain status of    " "---and only messages      for such a reason--- will normally be stored in the    hold channel&#x27;s queue area. That is,  message files in    the hold channel&#x27;s queue area can be assumed to be      due to user or domain status. 

 Messages  due to the MTA having detected that    they were looping can be expected to have a great many of one or    another sort of &#x2a;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.,    "  " 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&#x27;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   MTA option---to generate  a syslog notice whenever a message is  forced into   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. 

 Messages  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      channel option,    any use of the   flag in the     mapping   table or a   recipient-address-based      mapping table,    any negative value for the     or      MTA options,     or any use of the    " " action   in any system Sieve file (the      MTA option/system level      file, or any channel level Sieve    filters configured and named via use of       or       channel options) or   spam/virus filter package action&#x27;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   command) they might    have recently performed. Note also that application of a Sieve filter   " " action, whether from a system Sieve    filter or from users&#x27; personal Sieve filters, may optionally be logged in   MTA message transaction logging;    see the   MTA option. (As of MS 8.0 with its new, private  Sieve    " " extension, MTA administrators may wish to   make use of the " " action in any Sieve filter    that performs   a " " action, to record details regarding the reason(s)    that the " " was performed.) 



See also:
 * 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