Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"JEREMY@vsm.com.au"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Sun, 27 Dec 92 06:03:38 GMT
From:         Ned Freed <NED@INNOSOFT.COM>
Subject:      RE: Empty reply address from All-In-One/PMDF-MR
Newsgroups: bit.listserv.pmdf-l

> Hello there, I was wondering if anyone had seen this before.

Sure, its commonplace.

> I sent a mail message to a friend of mine at another site where they use
> All-In-One (the office system), and requested a delivery-receipt.  A little
> while later I received the following acknowlegement:

> Return-path: <>
> ...
> From: <>
> ...

> (I have replaced the site name by the word "site" in all addresses above, and
> the person's A1 username by "the user".)

> I would have expected the reply address for this message to be some sort of
> postmaster address for the site, is this configurable in All-In-One or PMDF-PR
   ?

First of all, you had best stop expecting anything of this sort. X.400 delivery
receipts are _defined_ not to have originator address information in them.
(Actually, this isn't precisely correct -- they do have something called
originator address information, but it refers to the originator in the sense of
who sent the original message the delivery receipt refers to. In other words,
the terminology for X.400 delivery receipts is reversed and properly speaking
what they don't contain is information about the system/agent that's producing
the receipt. Of course there's always the Received:, X400-Received:, and
MR-Received: lines, which can be used to backtrack to the system that generated
the receipt if you know what you're doing...)

So, when an X.400 delivery receipt is converted to an RFC822 message, there is
no address information that corresponds to the Return-path: or From: addresses
of RFC822. It is defined this way and there's no way to provide this
information in X.400 even if you wanted to. Gateways between X.400 and RFC822
can either cobble up some phony address or simply leave the information out. It
is totally up to the gateway, so you cannot count on any particular behavior at
any given time. This is therefore a general reality check that extends far
beyond PMDF-MR. There is also no rule at present that says X.400 sites must
have a valid "postmaster" address (there's an Internet Draft that proposes
making this a requirement) so in general you can have no idea what address to
send queries to.

The formats used by Message Router are very close to X.400-1984, so PMDF-MR is
functionally very similar to an X.400 gateway. And in the case of PMDF-MR you
get to define what address gets substituted for an empty or missing address in
the message header. This is done with the $E rule in the
FROM_MR.TXT/FROM_MR.DAT file/database. My $E rule reads:

  $E                              $C$I$&0$Wpostmaster@innosoft.com

Yours should have something similar in it if you want to get a proper
postmaster address on the From: line. However, this won't affect the receipts
you get from other sites. What information they put in the header is up to
them.

You don't get to set what appears in the envelope From: line though (what you
eventually see as the Return-path:). Delivery receipts should not themselves be
capable of generating delivery notifications. This is explicitly suppressed,
according to Internet rules, by leaving the envelope From: address blank.
PMDF-MR does not provide a way to override this since doing so would be
extremely likely to cause infinite messaging loops. (Note that PMDF itself has
an extended model for this information, but there are no facilities in X.400 or
Message Router to take advantage of the extended model PMDF has. As a result
PMDF-MR plays this one fairly strictly.)

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU