Newsgroups: vmsnet.mail.pmdf
Subject: RE: Defragment channel
From: "Daniel C. Newman" <dan@innosoft.com>
Date: 15 Sep 1992 10:17:16 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 15 Sep 1992 10:17:16 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOT66MZV3M9851ES@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"bob@camb.com"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> I am trying to use 4.1 facilities to fragment large messages and then
> reassemble them between two systems that communicate via PhoneNet.
> The sending system is breaking the large messages into smaller
> components with what appear to be reasonable MIME headers indicating
> the multiple parts.  However, the message is not being reassembled.
> The pieces are delivered individually at the 2nd system.  I assume
> I've misconfigured something at that end.

Does the remote system have a "defragment" channel.  These are generated
by the PMDF V4.1 configuration utility.  If the remote system does not have
such a channel, then add to the system's PMDF configuration rewrite rules of
the form

      defragment.sigurd.innosoft.com  $U@defragment.sigurd.innosoft.com

and a channel block of the form

      defragment nox_env_to
      defragment.sigurd.innosoft.com

Also, make sure that the local channel is marked "defragment"

Now, if there is a defragment channel and all on the remote system, then
the problem is probably one of crucial MIME header lines being lost.  None
of the involved channels are marked headeromit or headertrim are they?  In
the case of headertrim, you may wish to review which headers are being removed.
You must preserve the Content-type: and Content-transfer-encoding: headers.

If you have a defragment channel but the fragments are immediately being passed
on (unassembled) then lost header lines are undoubtedly the problem.

> I could use a pointer to documentation on how to configure the
> target system.

No such documentation exists at present.

> Is there an options file that controls things like
> how long the fragments are allowed to sit around before being
> forwarded, as is, unreassembled?  etc.

Fragments sit around for min (notices[1],notices[2],...,notices[n]) DIV 2
where notices[1],...,notices[n] are the days (or minutes) on which to return
warning messages or bounce the message.  The default is 3, 6, 9, 12 and so
by default, the fragments are passed on, unassembled, after they have sat
around for 3 DIV 2 = 1 day.  If a notices keyword is used with the defragment
channel, then those notices are used; otherwise, the notices associated with
the local channel are used (which may be the defaults, 3, 6, 9, 12).

> BTW, this appears to be a feature that will help us a lot on this
> particular link which is used to transfer, via 19.2K PhoneNet, some
> really large, multimegabyte files.

This is one our main motivations for implementing this facility.  Note, that
message fragmention stuff is an example of MIME usage.  The message to be
fragmented is broken into smaller messages; each smaller message is marked
as a MIME message/partial.

Dan