From: dan@hmcvax.claremont.edu (Daniel C. Newman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Postmaster notification for held msgs
Date: 28 Jul 92 23:19:00 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 28 Jul 1992 15:19 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GMX0FK23ZM9GVWIR@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"bob@camb.com"
X-Vms-Cc: IPMDF
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> I had situation where pmdf held some msgs after detecting a probable mail
> loop.  I don't think I'd received any notification from pmdf (e.g., via
> a mail msg to postmaster) when this occurred.  Did I miss it?  Should the
> daily RETURN job report on held files if they stick around for too many
> days?

No, you did not miss seeing an error report.  When a mail loop is detected,
sending more mail is very, very dangerous.  Consider the case where the local
host is not recognizing one of its names -- the typical cause of a mail loop.
Now, suppose we send mail to the postmaster and the postmaster's address
involves the unrecognized name.  The message to the postmaster will loop and
loop until it is marked .HELD (20 loops) and yet another message will be sent
to the postmaster. Mail then piles up and the postmaster still has no clue as
to the problem.

Now, it's not hard to conceive of a loop whereby the looping mail multiplies.
In such a case generating new mail is really, really dangerous.

The bottom line here is that when a mail loop occurs, something, somewhere is
misconfigured (the local host, a remote host, who knows) and generating new
mail messages (warnings to the postmaster) is clearly not a safe thing to do.
PMDF therefore does nothing other than to rename the message file to *.HELD
(this prevents PMDF from attempting further delivery attempts).  At present,
it's up to the postmaster to notice such things.  About the only safe thing
PMDF could do would be to issue an OPCOM broadcast of some sort.

Now for some general advice on what to do when you find *.HELD messages. [I
know that Bob knows what to do, but I figure other people on this list may
not.]

First, the occurrence of these loops are very rare and always indicate a
misconfiguration somewhere.  There are two typical causes:

(1) A user has set up a forwarding loop (e.g., their mail on system A goes
    to system B; their mail on system B goes to system A), or

(2) System A thinks that mail for user@host goes to system B; B receives
    the mail but doesn't doesn't recognize that it is @host and sends the
    mail back to A (or elsewhere) which then sends it back to B.

The way to determine what is going on is to examine the Received: lines in a
*.HELD message.  PMDF, when it sees the local host occur 10 or more times
(configurable with the PMDF option file options MAX_LOCAL_RECEIVED_LINES and
MAX_RECEIVED_LINES) in the Received: header lines, will mark the message *.HELD
and stop trying to deliver it.  Look at these received lines, see who the
message is for and make sure that (1) is not the problem.  If (1) is the
problem then undo the user's forwarding and discuss e-mail concepts with them.
If (1) is not the problem, then it is undoubtedly (2).

If (2) seems to be the case, then the problem is either (2a) that the local
host does not recognize one of its names, or (2b) the remote host which keeps
on sending mail to the local host is confused.  In the former case, you
probably need to add a rewrite rule to your PMDF.CNF of the form

unknown-host    $U@local-host

where "unknown-host" is the host name that is not being recognized and
"local-host" is the official local host name associated with the local (l)
channel.  It may be that the local host is a gateway and should be passing this
mail on to another system, "other-host", in which case a rule of the form

unknown-host    $U@other-host

is probably appropriate.

In the case of (2b), you have to call the postmaster of the remote host and
get them to fix things....

Now, after things are straightened out, rename the *.HELD file to *.00, [run
pmdf_root:[exe]synch_cache.exe if you're using PMDF V4.1,] and then release the
PMDF Delivery job in the MAIL$BATCH queue.  There's a good chance that the
message will pass on to another PMDF channel queue directory (e.g., the local
channel directory) and again be marked *.HELD.  This is normal; it happens
because PMDF again sees the local host name appearing 10+ times in the received
line.  Merely rename the file to *.00, [rerun synch_cache,] and then release
the PMDF Delivery job yet again.

Dan