home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / bit / listserv / pmdfl / 1958 < prev    next >
Encoding:
Text File  |  1992-09-08  |  6.4 KB  |  130 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%"DPMSYS%RITVAX.BITNET@ymir.claremont.edu"
  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: <01GOFZ0LZ4J696VN7I@YMIR.CLAREMONT.EDU>
  11. Date:         Sun, 6 Sep 92 10:50:29 GMT
  12. Sender:       PMDF Distribution List <PMDF-L@IRLEARN>
  13. From:         Ned Freed <NED@INNOSOFT.COM>
  14. Subject:      RE: Using DELIVER
  15. Newsgroups: bit.listserv.pmdf-l
  16. Lines: 112
  17.  
  18. > I know this has been covered on this list before, but can
  19. > someone explain again why the VMS forwarding address cannot
  20. > be used as the determinant for the execution of DELIVER.
  21.  
  22. PMDF has to be the entity that determines whether or not integrated DELIVER is
  23. used. This is fundamental -- integrated DELIVER depends on the knowledge that
  24. it is processing a PMDF-originated message. If the mail first passed through
  25. VMS MAIL all the advantages of integrated DELIVER would be totally lost.
  26.  
  27. This then implies that PMDF would have to react to the forwarding addrtess
  28. before VMS MAIL gets the message. But only VMS MAIL knows about its forwarding
  29. addresses. PMDF doesn't know what these addresses are or how to interpret them.
  30.  
  31. It is simply not practical to try and teach PMDF about VMS MAIL forwarding. VMS
  32. MAIL forwarding is very complex, very non-intuitive, and any attempt to unravel
  33. it would result in all sorts of hideous bugs until we got all the semantics
  34. issues worked out. It would also be a big layering violation -- we have no
  35. business dealing with data that's private to VMS MAIL. (Note that dealing with
  36. incoming addresses from the foreign interface is a totally different matter
  37. that has no real relationship to general forwarding address handling.)
  38.  
  39. The task of just identifying a PMDF forwarding address that points at DELIVER
  40. is arguably simpler, but not enough to matter. Don't underestimate the
  41. complexity here -- we're talking about something that hard, that has numerous
  42. serious pitfalls, and probably would take many iterations to get right.
  43.  
  44. Finally, one of the key uses of integrated DELIVER is to conditionally handle
  45. certain mail and leave the rest available for "normal processing". Part of that
  46. "normal processing" may involve dynamic use of forwarding addresses. But this
  47. isn't possible if you've used up your forwarding facilities on firing up
  48. DELIVER. This is another facet of the layering violation that's implicit in
  49. this suggestion -- it would put the cart before the horse insofar as most uses
  50. go.
  51.  
  52. It is therefore impractical, perilous, and totally inappropriate for PMDF to
  53. use forwarding address values to determine _anything_.
  54.  
  55. > I recently encountered the following senario:
  56.  
  57. > A user runs PMDF with integrated DELIVER on his home
  58. > machine (TECHNO).  On another machine (VAXA) which also runs
  59. > PMDF with DELIVER disabled he has his forwarding address set
  60. > to forward mail to his home machine.   His login directory on
  61. > VAXA is his home directory on TECHNO mounted on VAXA via
  62. > DEC's DFS.
  63.  
  64. PMDF and DELVIER aside, this is an extremely dangerous setup. DFS interacts
  65. very poorly with VMS MAIL because of VMS MAIL's use of shared indexed files.
  66. DFS cannot support this sort of shared access, and VMS MAIL is not prepared to
  67. deal with the errors that result from collisions across DFS.
  68.  
  69. Based on very nasty prior experience I would never put this strategy into
  70. production use. I personally have seen this cute little trick cause huge
  71. problems, up to and including the silent loss of lots of mail. "Minor" problems
  72. are usually things like finding your entire cluster wedged tight on Monday
  73. morning.
  74.  
  75. Incidentally, using NFS doesn't offer a viable alternative. NFS would get
  76. rid of most of the wedging problems at the expense of risking total
  77. corruption of any ISAM database you happen to have (like VMS MAIL folders).
  78.  
  79. > This all worked fine until I enabled DELIVER on VAXA.  PMDF
  80. > ignored the forwarding to TECHNO and instead processed all
  81. > mail to his account on VAXA using his mail.delivery file
  82. > from TECHNO.
  83.  
  84. What you have here is basically an impossible situation to resolve. You have
  85. built an environment where users and the software they use has to be able to
  86. tell what system is in use. But you have provided no reasonable mechanism (like
  87. different home directories) for them to use to distinguish one environment from
  88. the other. You therefore force sensitivity to environmental issues into every
  89. single application that anyone writes or uses on your system.
  90.  
  91. > I realize there are workarounds such as defining different
  92. > mail.delivery file names for different nodes, but what are
  93. > the reasons for allowing the file to override a forwarding
  94. > address.
  95.  
  96. The fundamental reason is simple -- DELIVER programming logically occurs before
  97. delivery to the user agent is done. Forwarding in the user agent (which is
  98. _very_ different from forwarding at the MTA level) is therefore a step that's
  99. taken after DELIVER programming and not before.
  100.  
  101. We thought all this through very carefully when integrated DELIVER was
  102. originally added to PMDF. Various orderings were considered including the one
  103. you describe.
  104.  
  105. Defining different MAIL.DELIVERY files would provide a means for users to
  106. distinguish between different environments. But users still have to code around
  107. the differences. We could provide access in the MAIL.DELIVERY file to node
  108. information to make this sort of thing easier. It would make it possible to
  109. program things in a node-specific way. But the underlying problem remains the
  110. same no matter what.
  111.  
  112. Another theoretical approach would be to completely eliminate the need to
  113. distinguish between the environments. This would in turn eliminate the need to
  114. forward mail from one place to the other -- why bother if the environments are
  115. identical? However, this simply cannot be done using DFS, NFS, or any other
  116. tool I know of short of actual VMS clustering.
  117.  
  118. > If there are no technical limitations to letting
  119. > the ~forwarding address be the deciding switch, can the switch
  120. > be defined in the PMDF option file.
  121.  
  122. There are good technical reasons as well as excellent strategic reasons for not
  123. doing this. This is therefore extremely unlikely to ever get implemented in
  124. PMDF.
  125.  
  126. However, in my opinion DELIVER usage of this sort is the very least of your
  127. problems -- you simply have a big accident waiting to happen here.
  128.  
  129.                                         Ned
  130.