home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / bit / listserv / pmdfl / 2559 < prev    next >
Encoding:
Text File  |  1992-12-27  |  4.0 KB  |  85 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!INNOSOFT.COM!NED
  3. Errors-to: epmdf@YMIR.BITNET
  4. X-Envelope-to: PMDF-L@IRLEARN.BITNET
  5. X-VMS-To: IN%"JEREMY@vsm.com.au"
  6. X-VMS-Cc: IPMDF
  7. MIME-version: 1.0
  8. Content-type: TEXT/PLAIN; CHARSET=US-ASCII
  9. Content-transfer-encoding: 7BIT
  10. Message-ID: <01GSSBLDE7UA90NSXF@YMIR.CLAREMONT.EDU>
  11. Date:         Sun, 27 Dec 92 06:03:38 GMT
  12. Sender:       PMDF Distribution List <PMDF-L@IRLEARN.BITNET>
  13. From:         Ned Freed <NED@INNOSOFT.COM>
  14. Subject:      RE: Empty reply address from All-In-One/PMDF-MR
  15. Newsgroups: bit.listserv.pmdf-l
  16. Lines: 67
  17.  
  18. > Hello there, I was wondering if anyone had seen this before.
  19.  
  20. Sure, its commonplace.
  21.  
  22. > I sent a mail message to a friend of mine at another site where they use
  23. > All-In-One (the office system), and requested a delivery-receipt.  A little
  24. > while later I received the following acknowlegement:
  25.  
  26. > Return-path: <>
  27. > ...
  28. > From: <>
  29. > ...
  30.  
  31. > (I have replaced the site name by the word "site" in all addresses above, and
  32. > the person's A1 username by "the user".)
  33.  
  34. > I would have expected the reply address for this message to be some sort of
  35. > postmaster address for the site, is this configurable in All-In-One or PMDF-PR
  36.    ?
  37.  
  38. First of all, you had best stop expecting anything of this sort. X.400 delivery
  39. receipts are _defined_ not to have originator address information in them.
  40. (Actually, this isn't precisely correct -- they do have something called
  41. originator address information, but it refers to the originator in the sense of
  42. who sent the original message the delivery receipt refers to. In other words,
  43. the terminology for X.400 delivery receipts is reversed and properly speaking
  44. what they don't contain is information about the system/agent that's producing
  45. the receipt. Of course there's always the Received:, X400-Received:, and
  46. MR-Received: lines, which can be used to backtrack to the system that generated
  47. the receipt if you know what you're doing...)
  48.  
  49. So, when an X.400 delivery receipt is converted to an RFC822 message, there is
  50. no address information that corresponds to the Return-path: or From: addresses
  51. of RFC822. It is defined this way and there's no way to provide this
  52. information in X.400 even if you wanted to. Gateways between X.400 and RFC822
  53. can either cobble up some phony address or simply leave the information out. It
  54. is totally up to the gateway, so you cannot count on any particular behavior at
  55. any given time. This is therefore a general reality check that extends far
  56. beyond PMDF-MR. There is also no rule at present that says X.400 sites must
  57. have a valid "postmaster" address (there's an Internet Draft that proposes
  58. making this a requirement) so in general you can have no idea what address to
  59. send queries to.
  60.  
  61. The formats used by Message Router are very close to X.400-1984, so PMDF-MR is
  62. functionally very similar to an X.400 gateway. And in the case of PMDF-MR you
  63. get to define what address gets substituted for an empty or missing address in
  64. the message header. This is done with the $E rule in the
  65. FROM_MR.TXT/FROM_MR.DAT file/database. My $E rule reads:
  66.  
  67.   $E                              $C$I$&0$Wpostmaster@innosoft.com
  68.  
  69. Yours should have something similar in it if you want to get a proper
  70. postmaster address on the From: line. However, this won't affect the receipts
  71. you get from other sites. What information they put in the header is up to
  72. them.
  73.  
  74. You don't get to set what appears in the envelope From: line though (what you
  75. eventually see as the Return-path:). Delivery receipts should not themselves be
  76. capable of generating delivery notifications. This is explicitly suppressed,
  77. according to Internet rules, by leaving the envelope From: address blank.
  78. PMDF-MR does not provide a way to override this since doing so would be
  79. extremely likely to cause infinite messaging loops. (Note that PMDF itself has
  80. an extended model for this information, but there are no facilities in X.400 or
  81. Message Router to take advantage of the extended model PMDF has. As a result
  82. PMDF-MR plays this one fairly strictly.)
  83.  
  84.                                 Ned
  85.