From: ned@innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Error in queueing bounced message.
Date: 16 Aug 92 03:16:40 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 15 Aug 1992 19:16:40 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNMDX2AHTU95N96H@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"SMITH%NYUMED.BITNET@ymir.claremont.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> I have been noticing an odd ?error? recently where messages are apparently
> being placed in the wrong queue when they get bounced.  This isn't happening
> all the time, of course.  But this is now the third such message, and I would
> like to figure out what is wrong.

> This message was placed in the MR-LOCAL queue.  It should be in the MTCP-LOCAL
> queue to be delivered.

Sorry -- this is incorrect. It should have gone into the MR_LOCAL queue and did
just that. Here's my analysis of the message you presented.

PLIM@MCCLB0.MED.NYU.EDU sent a message to plim@nyu-medical.NYU.EDU. This was
queued to the mtcp_local channel, which is what your configuration specifies.
This message then bounced -- the host name is illegal (NSLOOKUP confirms this).
The bounce message is then sent to both the postmaster and to the originator
PLIM@MCCLB0.MED.NYU.EDU.

But the address PLIM@MCCLB0.MED.NYU.EDU is aliased back to
plim@nyu-medical.NYU.EDU, so the bounce message itself bounces back to the
bounce message's originator -- the postmaster.

The postmaster therefore receives two slightly different copies of this
bounce message.

The postmaster is aliased to smith@nyu-medical.med.nyu.edu (note that this is a
different domain name). This address is mapped to the mr_local channel. You
therefore receive two copies of the bounce message via the mr_local channel and
nobody else gets anything.

All this precisely matches the way you have PMDF and PMDF-MR configured. The
headers make it all fairly clear in and of themselves, but I cross checked it
with your configuration to be sure.

> What _I_ think happened is:  I sent a mesage to PLIM which bounced.

No -- PLIM sent a message to him-or-her-self which bounced. This then generated
two copies of mail to the postmaster and nothing to anyone else since nobody
else here has a valid address.

> The error notifying me of the bounce is the message that is stuck.

This is the first time you mention that things are stuck. From the looks of
this message I suspect you have encountered the PMDF-MR problem with handling
complex bounce messages. This has been discussed in this forum previously, and
it is fixed in V4.1-10. (Side note for Bob Tinkelman: I checked this message in
its various formats to be sure and it worked fine with -10)

> The PMDF-MR channel is reached by sending mail to 'nyu-medical.med.nyu.edu'
> using SMTP, and I have an alias in the aliases. file routing SMTP mail to
> smith@nyu-medical.

No, according to your configuration nyu-medical.med.nyu.edu is reached directly
by an MR_LOCAL channel. Everyone else might reach it via SMTP (there is an MX
for it) but you do not. There is no reason for mail to this domain to ever
appear in your MTCP_LOCAL channel queue.

The domain nyu-medical.nyu.edu is reached via MTCP_LOCAL according to your
configuration (I suspect this is just the .EDU rule acting here) and this
domain is therefore illegal both to you and to everyone else.

> I have forwarded my VMS mail to the same address.  I am
> getting the non-delivery notice because I am also the postmaster.  I am
> including below the notification message sent to 'postmaster' and the queue
> file from MR-LOCAL.

This explains why you are getting notices on the MR_LOCAL channel. Nobody
else sees them since there's no other legal address associated with the
message.

One final note. It is extremely unlikely that bounce messsages would go to
different places than regular messages. There is nothing special about them,
and the code used is identical (we are talking about the same bits in shared
global memory here).

					Ned