Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!mit-eddie!bbn!diamond.bbn.com!mlandau
From: mlandau@bbn.com (Matt Landau)
Newsgroups: comp.protocols.tcp-ip
Subject: SMTP and alternate message body types [Was Re: Secure SMTP & X.400]
Message-ID: <12747@jade.BBN.COM>
Date: 6 Apr 89 23:20:29 GMT
References: <286@brolga.cc.uq.oz>
Reply-To: mlandau@bbn.com (Matt Landau)
Organization: BBN Systems and Technologies Corporation, Cambridge, MA
Lines: 52

In comp.protocols.tcp-ip (<286@brolga.cc.uq.oz>), ggm@brolga.cc.uq.oz 
(George Michaelson) writes:
>
>also, by positing a framework for transmitting encoded body-types in
>plain SMTP we can equally propose other complex body-types, and thus
>X.400 and OSI can be staved off for a few years yet by concentrating 
>on the UA's to de-munge the mail and forgetting all the transport stuff.

On a related topic, there is currently an Internet RFC (RFC 1049, by
Marvin Sirbu at CMU) that proposes extending RFC-822 headers to include 
a standard Content-Type: header in which the body-type and decoding
instructions can be transmitted.

We've gone ahead and implemented a front-end to /bin/mail (actually, to 
the local mail delivery agent of your choice) that interprets either
Content-Type or X-Content-Type headers, and allows for an external
configuration file with instructions for dispatching different mail 
content types to different decoders and delivery programs.

We use this facility quite effectively in the Slate multimedia document 
communications system to deliver encoded multimedia electronic mail over 
conventional mail transport channels.  I've seen it work with existing
mail systems including SMTP with sendmail or MMDF, uucp, BITNET, and at 
least one X.400 mailer (delivering our own private body type instead
of one of the "standard" ones).

I believe that CMU has done something similar with the Andrew system
to allow delivery of Andrew multimedia documents via sendmail.  I'm not
sure their version is configurable to handle arbitrary content types,
but the existence of these two different systems should serve as proof
that we can easily extend current SMTP (and other text-mail mail delivery
mechanisms) to deal with complex body types, without all the ancilliary
hair of X.400

In fact, there are tremendous advantages in doing so.  For one thing, you 
don't lose any of the current network connectivity that has made mail 
systems work so well up to this point.  By relying on existing transport 
systems, and using encoding/decoding schemes to package up different body 
types in a form acceptable to those transport systems, we have a 
pre-existing electronic community of tens (or more likely hundreds) of 
thousands of people, with the network communications infrastructure 
already in place to make complex/compound message types useful almost 
immediately.

Eventually, X.400 and related standards may become widespread, and may
even become the de facto way we all deal with mail.  (I'm not sure I'd
bet on it, but that's another story...)  But X.400 and company are no 
means necessary if one simply wants to extend the domain of things that 
can be communicated by electronic mail beyond simple text.
--
 Matt Landau			Waiting for a flash of enlightenment
 mlandau@bbn.com			  in all this blood and thunder