From sau@sleepy.bellcore.com Thu Oct  3 16:05:05 1991
Received: from hanna.cac.washington.edu by akbar.cac.washington.edu
	(5.65/UW-NDC Revision: 2.23 ) id AA29595; Thu, 3 Oct 91 13:05:05 -0700
Received: from thumper.bellcore.com by hanna.cac.washington.edu
	(5.65/UW-NDC Revision: 2.23 ) id AA19384; Thu, 3 Oct 91 13:04:49 -0700
Received: from greenbush.bellcore.com by thumper.bellcore.com (4.1/4.7)
	id <AA12304> for MRC@CAC.Washington.EDU; Thu, 3 Oct 91 16:04:44 EDT
Received: by greenbush.bellcore.com (4.1/4.7)
	id <AA08989> for MRC@CAC.Washington.EDU; Thu, 3 Oct 91 16:04:43 EDT
Received: from Messages.7.14.N.CUILIB.3.45.SNAP.NOT.LINKED.greenbush.galaxy.sun4.40
          via MS.5.6.greenbush.galaxy.sun4_40;
          Thu,  3 Oct 1991 16:04:42 -0400 (EDT)
Resent-Message-Id: <EcurTOC0M2YtQTa2QW@thumper.bellcore.com>
Resent-Date: Thu,  3 Oct 1991 16:04:42 -0400 (EDT)
Resent-From: Nathaniel Borenstein <nsb@thumper.bellcore.com>
If-Type-Unsupported: send
Resent-To: Mark Crispin <MRC@CAC.Washington.EDU>
Return-Path: <sau@sleepy.bellcore.com>
Date: Fri, 7 Jun 91 09:09:05 EDT
From: sau@sleepy.bellcore.com (Stephen A Uhler)
Message-Id: <9106071309.AA00574@sleepy.bellcore.com>
To: nsb@sleepy.bellcore.com
Subject: meta-mail
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED;boundary="mail.sleepy.sau.158.532"
Status: RO

--mail.sleepy.sau.158.532

2 Questions:

1) MM_QUIET doesn't seem to work in the 212 version of metamail.

2) I've been pondering how I am going to send you this 40mb mail message.
   I was going to split it up using the "parts" mechanism, but then it occurred to me.
   My software has no business worrying about message size.  Its up to the mail
   delivery agent to do that form me.  I should be able to compose a very
   long message, and pass it off to sendmail (well, a pre-processor to sendmail).
   if the message is too long, based upon the src/dst etc, then sendmail should
   break it into multiple parts for me, and send it as multiple messages.  As the
   user (sender) I should be unaware this is happening.

   Similarly, on the receiving end, the separate parts should be assembled as they
   arrive; I shouldn't have do deal with them at all as multiple messages.

   I guess what I am proposing are two utility programs:

       msplit <max_lines> <max_bytes>

   that takes 1 mail message and splits it into N messages and

       mcombine <parts...>
       mcombine <partially_assembled_thingy> <parts...>

   that any mail system can call to achieve a uniform mechanism of splitting
   and recombining messages,  Kind of like:
--mail.sleepy.sau.158.532
Content-type: image/pbm
Content-transfer-encoding: base64
Content-Description: Mail architecture slide
Comments: Image wrapped by /usr/sau/bin/fetch_image

[encoded data, 71318 characters]
--mail.sleepy.sau.158.532--

