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 .HELD.
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
lines.
35.4.7.1 Diagnosing .HELD file One 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 forwarding definitions.
Another common cause of message 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 acme.com, but whose PMDF configuration does not know that. A message is sent to joe@acme.com and is accepted by the network and delivered to this host. Since PMDF does not know itself as acme.com, it will likely assume that acme.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.
Example 35-2 pmdf.cnffor
coyote.acme.com
! pmdf.cnf - PMDF configuration file for coyote.acme.com
! Written by SYSTEM, 19-APR-1992 21:23
! This file was created by the PMDF configuration generator.
!
! Rewrite rules for the local host/cluster
!
coyote $u@coyote.acme.com (1)
coyote.acme.com $u@coyote.acme.com
sleddog $u@coyote.acme.com (2)
sleddog.acme.com $u@coyote.acme.com
acme.com $u@coyote.acme.com (3)
!
! Rewrite rules for the Internet
.
.
.
l nox_env_to
coyote.acme.com (4)
.
.
.
In Example 35-2 we have added acme.com as another name for the cluster consisting of coyote.acme.com and sleddog.acme.com, where the official local host name has been coyote.acme.com. Mail addressed to joe@acme.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 may have to address the problem with a network configuration change or by changing the behavior of a remote mailer.
35.4.7.2 Cleaning up .HELD file
After diagnosing and fixing the cause of the loop, .HELD
files should be renamed to .00; for example, in the csh
shell you can use commands such as the following:
# cd /pmdf/queue/tcp_local
# foreach N ({.,*}/*.HELD)
? mv $N `dirname $N`/`basename $N \.HELD`.00
? end
Then synchronize the queue cache with the command
# pmdf cache -synchronize(Alternatively, the
pmdf qm -maint utility's
release command can be used to cause message files to
cease to be .HELD and the PMDF queue cache database to be
synchronized.) Then use the pmdf startup post to run the
PMDF periodic delivery retry job immediately. Now, after the resulting
jobs have run, look around to see if there are new .HELD
files. There may very well be some. If there are still
.HELD files in the original queue directory, then you may
not have solved the looping problem. However, you may also find
.HELD files in other queue directories such as the local
channel (L channel) queue directory. This is because PMDF marks a
message .HELD when 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 .HELD files to
.00, synchronizing the queue cache, and again submitting
PMDF processing jobs. Repeat this process until there are no more
.HELD files in any of the channel queue directories.