home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / vmsnet / mail / pmdf / 2307 < prev    next >
Encoding:
Internet Message Format  |  1992-09-15  |  3.3 KB
  1. Path: sparky!uunet!decwrl!infopiz!mccall!ipmdf-newsgate!list
  2. Newsgroups: vmsnet.mail.pmdf
  3. Subject: RE: Defragment channel
  4. Message-ID: <01GOT6493RIQ9TCNO5@INNOSOFT.COM>
  5. From: "Daniel C. Newman" <dan@innosoft.com>
  6. Date: 15 Sep 1992 10:17:16 -0700 (PDT)
  7. Organization: The Internet
  8. Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
  9. Resent-Date: 15 Sep 1992 10:17:16 -0700 (PDT)
  10. Resent-From: epmdf@YMIR.CLAREMONT.EDU
  11. Errors-To: epmdf@YMIR.CLAREMONT.EDU
  12. Resent-Message-ID: <01GOT66MZV3M9851ES@YMIR.CLAREMONT.EDU>
  13. X-Vms-To: IN%"bob@camb.com"
  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: 58
  19.  
  20. > I am trying to use 4.1 facilities to fragment large messages and then
  21. > reassemble them between two systems that communicate via PhoneNet.
  22. > The sending system is breaking the large messages into smaller
  23. > components with what appear to be reasonable MIME headers indicating
  24. > the multiple parts.  However, the message is not being reassembled.
  25. > The pieces are delivered individually at the 2nd system.  I assume
  26. > I've misconfigured something at that end.
  27.  
  28. Does the remote system have a "defragment" channel.  These are generated
  29. by the PMDF V4.1 configuration utility.  If the remote system does not have
  30. such a channel, then add to the system's PMDF configuration rewrite rules of
  31. the form
  32.  
  33.       defragment.sigurd.innosoft.com  $U@defragment.sigurd.innosoft.com
  34.  
  35. and a channel block of the form
  36.  
  37.       defragment nox_env_to
  38.       defragment.sigurd.innosoft.com
  39.  
  40. Also, make sure that the local channel is marked "defragment"
  41.  
  42. Now, if there is a defragment channel and all on the remote system, then
  43. the problem is probably one of crucial MIME header lines being lost.  None
  44. of the involved channels are marked headeromit or headertrim are they?  In
  45. the case of headertrim, you may wish to review which headers are being removed.
  46. You must preserve the Content-type: and Content-transfer-encoding: headers.
  47.  
  48. If you have a defragment channel but the fragments are immediately being passed
  49. on (unassembled) then lost header lines are undoubtedly the problem.
  50.  
  51. > I could use a pointer to documentation on how to configure the
  52. > target system.
  53.  
  54. No such documentation exists at present.
  55.  
  56. > Is there an options file that controls things like
  57. > how long the fragments are allowed to sit around before being
  58. > forwarded, as is, unreassembled?  etc.
  59.  
  60. Fragments sit around for min (notices[1],notices[2],...,notices[n]) DIV 2
  61. where notices[1],...,notices[n] are the days (or minutes) on which to return
  62. warning messages or bounce the message.  The default is 3, 6, 9, 12 and so
  63. by default, the fragments are passed on, unassembled, after they have sat
  64. around for 3 DIV 2 = 1 day.  If a notices keyword is used with the defragment
  65. channel, then those notices are used; otherwise, the notices associated with
  66. the local channel are used (which may be the defaults, 3, 6, 9, 12).
  67.  
  68. > BTW, this appears to be a feature that will help us a lot on this
  69. > particular link which is used to transfer, via 19.2K PhoneNet, some
  70. > really large, multimegabyte files.
  71.  
  72. This is one our main motivations for implementing this facility.  Note, that
  73. message fragmention stuff is an example of MIME usage.  The message to be
  74. fragmented is broken into smaller messages; each smaller message is marked
  75. as a MIME message/partial.
  76.  
  77. Dan
  78.