Mail messages in the PMDF message queue directories generally have a
two-digit file extension. If PMDF detects a message that is looping, it
will rename the file so that it has an extension of
Message files with such a file extension will not be processed by PMDF
channel programs and therefore will not be delivered. This is a safety
mechanism to prevent messages from looping indefinitely. Looping
messages are detected by having a large number of Received: headers
22.214.171.124 Diagnosing .HELD Files
One possible cause of 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
Another common cause of messages loops is PMDF receiving a message that was addressed to your host with a network name that PMDF does not recognize as one of the host's own names. For example, imagine a host which is known to the TCP/IP domain name system and to other hosts and users as example.com, but whose PMDF configuration does not know that. A message is sent to email@example.com and is accepted by the network and delivered to this host. Since PMDF does not know itself as example.com, it will likely assume that example.com is elsewhere and direct the message back out to the network and unwittingly loop the message back to itself. This loop will continue until PMDF detects the loop and puts the message on hold.
If you detect such a situation, you should try to determine by examination of the message file whether there is a name you should add to your PMDF configuration as a synonym for your official local host name. The Received: lines should show the path the message travels through the loop.
! pmdf.cnf - PMDF configuration file for milan.example.com ! Written by SYSTEM, 19-AUG-2002 21:23 ! This file was created by the PMDF configuration generator. ! ! Rewrite rules for the local host/cluster ! milan $firstname.lastname@example.org (1) milan.example.com $email@example.com naples $firstname.lastname@example.org (2) naples.example.com $email@example.com example.com $firstname.lastname@example.org (3) ! ! Rewrite rules for the Internet . . . l nox_env_to milan.example.com (4) . . .
In Example 35-2 we have added example.com as another name for the cluster consisting of milan.example.com and naples.example.com, where the official local host name has been milan.example.com. Mail addressed to email@example.com will now be properly recognized and locally delivered.
If you do not believe that the name in question should be directed to your host, then you can have to address the problem with a network configuration change or by changing the behavior of a remote mailer.
126.96.36.199 Cleaning Up .HELD Files
After diagnosing and fixing the cause of the loop,
files should be renamed to
.00; e.g., issue the
$ RENAME PMDF_QUEUE:[tcp_local...]*.HELD *.00
$ PMDF CACHE/SYNCHRONIZE
.HELDand the PMDF queue cache database to be synchronized.) Then release the pending PMDF delivery job which is holding in the MAIL$BATCH queue. Now, after the resulting jobs have run, look around to see if there are new
.HELDfiles. There can very well be some. If there are still
.HELDfiles in the original queue directory, then you can not have solved the looping problem. However, you can also find
.HELDfiles in other queue directories such as the local channel (L channel) queue directory. This is because PMDF marks a message
.HELDwhen it has too many Received: lines in which the local host appears. As the message moved from the original directory to another directory (i.e., moved from one channel to another), PMDF again saw too many Received: lines in the message's header and again marked it
.HELD. This is to be expected. Simply repeat the process of renaming the
.00, synchronizing the queue cache, and again releasing the pending PMDF delivery job. Repeat this process until there are no more
.HELDfiles in any of the channel queue directories.