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