ggm@brolga.cc.uq.oz (George Michaelson) (04/06/89)
on a slightly more serious note, since secure SMTP will require
post-processing to read, and presumably will look pretty much like
btoa-encoded binary forms, how is this going to tie in with X.400
secure mail forms? anyone doing the gateway code yet?
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.
whenever I proposed this to developers in the UK, they poo-pooed any
suggestion of passing X.400 in Greybook text or SMTP body's as "backwards
looking" and "non-productive for OSI migration" but if the decoders
are going to go in place anyhow why not extend them a bit?
-george
--
ACSnet: ggm@brolga.cc.uq.oz Phone: +61 7 377 4079
Postal: George Michaelson, Prentice Computer Centre
Queensland University, St Lucia, QLD 4067 mlandau@bbn.com (Matt Landau) (04/07/89)
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
nsb+@ANDREW.CMU.EDU (Nathaniel Borenstein) (04/18/89)
> *Excerpts from magazines.mail.cfe: 6-Apr-89 SMTP and alternate message ..* > *Matt Landau@bbn.com (2843)* > 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 Yes, this is certainly the case. For the record, the Andrew Message system can handle other content types; for example, you can use the header Content-type: troff; 0 ; /usr/lib/tmac/tmac.an,/usr/lib/tmac/tmac.recipe to see on-screen the properly formatted versions of the recipes that Briane Reid distributes via the newsgroup alt.gourmand (assuming, of course, that you've installed his troff library in /usr/lib/tmac/tmac.recipe). The mechanism is indeed very general and flexible.