








            EMail With A Mind of Its Own:
            The Safe-Tcl Language for Enabled Mail

            Nathaniel S. Borenstein

            First  Virtual  Holdings,  Inc.,   25   Washington   Avenue,
            Morristown, NJ 07960, USA
            Email: nsb@nsb.fv.com

            Abstract

            A uniform extension language for email systems can radically
            extend  the  utility  of  electronic  mail,  simplifying the
            construction  of  mail-based  services  and  permitting  the
            delivery   of  active  messages  that  interact  with  their
            recipients  and  take  differential  actions  based  on  the
            recipients'   responses.    This   paper  describes  such  a
            language,  Safe-Tcl,  including  the  strong  security   and
            portability  constraints it has to satisfy, and outlines its
            fundamental design.

            Keyword Codes: C.2.4, D.3.2, H.4.3
            Keywords:   Distributed   Systems,   Programming    Language
            Classifications, Communications Applications

            I.  The Dream of Enabled Mail

            The phrase "enabled mail" encompasses  several  technologies
            that  share  the common goal of significantly increasing the
            power and utility of electronic mail systems.  Enabled mail,
            in  general, is the augmenting of electronic mail systems by
            the introduction  of  computational  power  at  several  key
            points  in  the  electronic  mail  process.   Many  existing
            systems offer such power in some places, but  the  power  is
            incomplete,   non-uniform,   and  suffers  from  a  lack  of
            interoperability across platforms and tools.

            A conceptual model for  the  introduction  of  computational
            power  in email systems is given in [13].  Specifically, the
            general email model is  enhanced  by  viewing  the  delivery
            process  as  consisting  of  three  distinct phases:  First,
            "delivery-time", which occurs immediately before the message
            crosses the delivery slot, and in which the message is still












            conceptually under  the  control  of  the  sender;   Second,
            "receipt-time",  which  occurs immediately after the message
            crosses the delivery slot; and, finally,  "activation-time",
            which  occurs  whenever the recipient processes the message.
            This model provides an abstract  framework  for  considering
            various  uses of computational technology to provide enabled
            mail.

            The types of enabled mail most commonly  found  in  existing
            system  allow  users  to  specify  customized  computational
            processes to be executed upon the receipt of a mail message,
            or upon the incorporation of a message into a user's message
            store.   Various  mail  systems  offer  extremely   powerful
            languages  for  this  type  of  functionality.  Because this
            functionality  is  largely  incorporated  within  a   single
            software  suite,  the fact that each of these systems uses a
            different language and  model  is  only  a  minor  nuisance,
            particularly   for   those   attempting  to  switch  between
            different mail systems.

            Less common, and  more of a radical break for most users and
            implementors,    is    the    notion   of   "active"   mail.
            Traditionally,  electronic  mail   has   been   a   passive,
            unidirectional  medium.   Even multimedia mail [1, 2, 3] has
            operated this way -- mail  messages  contain  text  that  is
            displayed  to  the  user, images that are shown to the user,
            audio that is played for  the  user,  and  so  on,  but  the
            process  is  traditionally  one-way and non-interactive.  In
            active mail,  a message contains a program  to  be  executed
            when  the  recipient  reads the message.  Such a message can
            potentially perform arbitrarily complex interactions, vastly
            increasing   the  scope  and  utility  of  electronic  mail.
            Active  mail  has  hitherto   been   largely   confined   to
            experimental research software, due to problems of security,
            portability and standardization.  [1,7,8,9]  Recent research
            [10] has demonstrated workable solutions to the security and
            portability problems, making the time ripe to  consider  the
            wider  deployment and eventual standardization of a language
            for active mail.  In the area of active mail, convergence on
            a  single  language is critical, because email that does not
            interoperate in a  cross-platform  manner  is  of  extremely
            limited utility.

            Recently, the author and a colleague,  Marshall  Rose,  have
            published a draft specification of a model for enabled mail,
            clarifying the conceptual roles of the various places in the












            email  process  where  computation  can  augment  the  email
            process.   [13]    Additionally,   we   have   published   a
            specification   and   public-domain   implementation  for  a
            language, Safe-Tcl, that we believe can serve as a  uniform,
            cross-platform  engine  for  all  of  these  kinds  of mail-
            enabling computation [14].  While  standardization  is  more
            important  for  some aspects of enabled mail (notably active
            mail) than for others, there is much to be gained from using
            a  uniform  language  at  all  phases  of  the  enabled-mail
            process.  We have based our language on Tcl  [4,  5,  6],  a
            language  that  was  explicitly designed to be embedded as a
            computational extension to a larger application.  Aside from
            our  highly  subjective  judgment  that  Tcl is a very well-
            designed language for such purposes, Tcl has the  virtue  of
            being simple, well-defined, and available in a high-quality,
            extremely portable public domain implementation.

            The choice of Tcl as a  base  language  provides  the  basic
            syntax  and  many  of  the  primitives  for  an enabled mail
            language, but vanilla Tcl is not itself suitable for enabled
            mail.   The design of a language for enabled mail involves a
            complex combination of constraints.  For some parts  of  the
            computation, where the program comes entirely from a trusted
            source (such as the user on behalf of whom it is executing),
            any  sufficiently  powerful  and well-defined language would
            probably suffice, especially if  augmented  with  messaging-
            specific  features.   The  most severe constraints come from
            the active mail case, where security, interface portability,
            and cross-platform availability are absolutely critical.

            The remainder of this paper  is  structured  in  two  parts.
            First,  we  outline the problems inherent in the design of a
            language for enabled mail.  Then, we describe  the  Safe-Tcl
            language  and  how  it  solves  these  problems.  Concluding
            sections discuss the current status, availability and future
            prospects  for  the  Safe-Tcl  language  in  particular  and
            enabled mail in general.

            II.   The Key Problems:  Designing a Language for Enabled
            Mail

            As stated previously, some types of enabled  mail,  such  as
            programs  to filter incoming mail, can be provided in almost
            any general-purpose  programming  language.   To  provide  a
            uniform language for all phases of the enabled mail process,
            however, special attention must be paid to the "worst  case"












            --  active  mail.   In active mail, any electronic mail user
            can send a program to any other electronic mail user, to  be
            executed   in  the  recipient's  environment.   This  raises
            several severe constraints which must be  addressed  in  the
            design of an enabled mail language.

            Security

            The most critical constraint for active  mail  is  security.
            Simply  put, it must be possible to read a message from your
            mortal enemy without that message doing you any harm.    The
            use  of an arbitrarily powerful programming language in this
            role would be completely unacceptable,  as  it  would  allow
            malicious  users  to  send  email  messages that deleted the
            recipient's files, stole confidential information and mailed
            it   elsewhere,   forged   email   impersonating  the  email
            recipient, or caused any number of other kinds of mischief.

            Fortunately, recent research [10] has  demonstrated  that  a
            language  for  active  mail  can  be suitably restricted and
            constrained to do no such harm.  The details are beyond  the
            scope  of  this  paper,  but the basic idea is quite simple:
            you simple remove from the language any features that can be
            used   to   do   harm,   and  then  augment  the  resulting,
            impoverished language  with  less  general  primitives  that
            provide  a  safe  subset  of the removed functionality.  For
            example, you might remove the general-purpose mechanisms for
            reading   and   writing  files,  but  replace  it  with  new
            primitives that only allow limited operations on a  specific
            set of "public" files.

            When the solution is framed in  these  terms,  it  is  clear
            that,  with  sufficient  attention to some subtle details, a
            language can be made safe for widespread  active  mail  use.
            What  is  probably  less  clear is that such a language will
            retain sufficient power to be broadly useful.

            Power

            After an active mail language is made safe, the question  of
            the  language's  power  becomes  important.  Previous active
            messaging  systems  either  left  the  burden  of   security
            entirely  to the user [1], sidestepped it by restricting all
            computation to a trusted environment, which doesn't scale to
            the  most  general  email networks [7, 9], or restricted the
            language so severely as to  fundamentally  prohibit  certain












            classes of potential applications [10].

            The  fundamental  problem  is  that   the   most   dangerous
            primitives,  where active messaging is concerned, tend to be
            the most general  primitives.    The  process  of  making  a
            language  safe  for  active  messaging  consists  largely of
            replacing general  primitives  with  more  specialized  safe
            primitives.   Inevitably,  the  resulting loss of expressive
            power  handicaps  the  creation  of  certain   applications,
            particularly  those  applications  not  anticipated  by  the
            language designers.

            Extensibility

            The obvious solution to the problem of insufficient power in
            an   active   messaging  language  is  to  simply  add  more
            specialized safe primitives as needed.  This, however, is  a
            challenging idea when applied to the whole universe of email
            systems.   Upgrading  all  systems  to   support   the   new
            primitives, however safe they might be, will generally be so
            difficult that it rarely happens.   The  biggest  innovation
            that  Safe-Tcl  has over previous active messaging languages
            (such as ATOMICMAIL) is its extension model, which makes  it
            plausible  to  grow  the  system's  functionality  in a safe
            evolutionary manner.

            Missing from all previous active messaging  systems  is  any
            systemic   support   for  the  distributed  maintenance  and
            evolution of the set of known safe primitives.  In all  such
            systems of which the author is aware, the only way to extend
            the language in a manner that augments its fundamental power
            (as  opposed  to  simply  defining  new procedures using the
            existing   primitives,   which   provides   conceptual   and
            computational  convenience but no real increase in power) is
            to recompile the language interpreter  itself,  typically  a
            major  enterprise.   Ideally,  an  active messaging language
            should provide some simple  mechanism  by  which  users  can
            define specialized operators in an unrestricted environment,
            and make those specializations  alone  available  to  active
            mail programs.

            Authentication

            Once the  ability  for  users  to  provide  power-augmenting
            extensions   is   provided,   the  issue  of  authentication
            inevitably arises.  For many applications, users  will  want












            to  define  actions  that  are  available  only  for  active
            messages from certain trusted senders.   Trusting  the  mail
            headers  is  dangerously  naive  in  this regard, as mail is
            trivial to forge in most environments.   This  implies  that
            the  ideal  active messaging language would have the ability
            to understand and validate authenticated  mail  (using  such
            technology  as  Privacy  Enhanced  Mail (PEM) [11] or Pretty
            Good Privacy (PGP) [12]).  Such capabilities have  not  been
            available in any previous systems for active messaging.

            Interface Portability

            The notion of portability is  of  obvious  importance  to  a
            language  for  enabled  mail,  as it will have to run on the
            widest imaginable variety of computing platforms.  When most
            people  think  of  portability,  however, they tend to think
            primarily about the  issues  involved  in  writing  portable
            software.   While  these  issues are as important to enabled
            mail as they are to  any  other  multiplatform  application,
            there  is an even harder issue for active mail, that of user
            interface portability.

            The problem is that the sender of  an  active  mail  message
            will  not, in the general case, have any knowledge about the
            type of computing platform or platforms on which his message
            will be read.   This means that he cannot write programs for
            a particular user interface model such as  that  provide  by
            Windows,  the  Macintosh,  X11,  or a teletype.  The program
            must be written and delivered without  any  knowledge  about
            the environment in which it will interact with the user.

            Previous research active mail systems typically ignored this
            issue  entirely,  generally  focusing on providing a single-
            platform active mail, which was rightly perceived  as  "hard
            enough".    The  ATOMICMAIL  system  [10]  was  the first to
            provide  any  kind  of  solution  to   this   problem.    In
            ATOMICMAIL,  all  user  interaction  took place via abstract
            primitives such as "get a string from the user" or "ask  the
            user  a  multiple  choice  question".  The implementation of
            these  primitives  varied  significantly  on  the  supported
            platforms  (Macintosh, X11, smart terminals, and teletypes),
            but this variation was  invisible  to  ATOMICMAIL  programs,
            which simply knew, for example, that they had asked the user
            a multiple choice question and  somehow  gotten  an  answer.
            ATOMICMAIL   thus  demonstrated  that  it  was  conceptually
            possible to write interactive programs  that  were  entirely












            ignorant  and  independent of the user interface platform on
            which they would be executed.

            Interface Quality

            Unfortunately, ATOMICMAIL's solution to the problem of  user
            interface  portability led directly to another problem, that
            of interface quality.  ATOMICMAIL was generally perceived as
            solving  the  portability  program  by making it possible to
            produce programs that would have a user interface  that  was
            uniformly terrible on a wide variety of platforms.

            The problem was that ATOMICMAIL's abstractions constituted a
            Procrustean  bed into which all interactive applications had
            to be made to fit.  An ATOMICMAIL program might  be  running
            in   the   world's   most   sophisticated   user   interface
            environment, but it couldn't exploit that power in  any  way
            other   than   to   use   the   world's  most  sophisticated
            implementation of "ask the user a multiple choice question".
            In  particular, it was impossible to develop a modern event-
            driven program with this model.

            To succeed with a broad base  of  casual  users,  an  active
            messaging  language  must provide some way to write programs
            with  better  user  interfaces,  without   sacrificing   the
            portability demonstrated by ATOMICMAIL.

            III.  The Safe-Tcl Language

            With  a  solid  history  of  experimental  and   proprietary
            technologies  demonstrated  for  various  aspects of Enabled
            Mail, the time seemed right to begin  designing  a  language
            that  would  be  suitable  for  all  the  various aspects of
            enabled mail.  Unlike previous research projects,  the  goal
            of  this  effort  was  not  pure  research  -- although some
            interesting problems remained, as described in the  previous
            section -- but rather the development of a language that was
            good enough to be a candidate  for  standardization.    That
            the  project was begun with this in mind does not imply that
            the  authors  think  the  language  should  necessarily   be
            standardized  as  it  now  stands, nor that it is impossible
            that a better candidate will appear.  Rather, the  goal  was
            to  produce an enabled mail language that was good enough to
            initiate a standards process in this area.














            In this section we will describe the basic technology of the
            Safe-Tcl  language.   A detailed description of the language
            is beyond the scope of this paper, but may be found in [14].

            Tcl and Tk:  A "Good Enough" Language Model

            The history of standardization efforts shows that  there  is
            no  such  thing  as  an  uncontroversial or simple standard.
            Indeed, most people don't realize that even such a basic and
            near-universal  standard  as  ASCII  remains  the subject of
            ambiguity and debate.  (There are several slightly different
            things that are considered "ASCII" in different communities;
            sticklers  for  detail  will  always  reference  a  specific
            standard  such  as  [15].)   However,  of all the things one
            might wish to standardize, it is hard  to  imagine  anything
            more   prone  to  controversy  than  programming  languages.
            Programming languages come in  a  very  rich  diversity  and
            differ   widely   in   their  basic  syntax,  features,  and
            philosophies.

            Fortunately, the world does not, in general, need  a  single
            standard   programming  language;  applications  written  in
            multiple languages can  coexist  happily  on  most  systems.
            Unfortunately, in the area of enabled mail, and particularly
            for active mail, a standard language is essential.  It would
            be  unrealistic  to expect that there could ever be a single
            language that satisfied all  interested  parties.   Instead,
            the goal of the effort that produced Safe-Tcl was to produce
            a language that was "good enough" for essentially  all  uses
            of  enabled  mail.   We  knew  that  the  choice of the base
            language would inevitably be  controversial  and  that  some
            people  would  hate any language we might choose.  It is our
            hope that those who dislike the language model we settled on
            will recognize the importance of converging on a single such
            language,  and  will   try   to   shape   their   criticisms
            constructively, helping to evolve the language by correcting
            whatever deficiencies they might perceive in it.

            The basic language model we chose was Tcl, the Tool  Command
            Language  developed  by John Ousterhout at the University of
            California at Berkeley.   The great strengths  of  Tcl,  for
            this application, are:

            -- It has an extremely simple, easily learned syntax.














            -- It is interpreted rather than compiled.
            -- It was explicitly  designed  to  be  embedded  in  larger
            applications.
            -- There is a  high  quality  multi-platform  public  domain
            implementation available.
            -- There is a high-level graphical  toolkit  (Tk)  available
            for X11 programming.

            Major drawbacks we perceived in Tcl were:

            -- There is no high-level  graphical  toolkit  for  non-UNIX
            platforms.    However,   the  elegant  structure  of  Tk  is
            convincing proof that such toolkits are eminently plausible.
            -- The variable scoping  mechanism  offers  no  intermediate
            scope  between local and global variables.  (However, access
            to other evaluation contexts  is  available  using  the  Tcl
            "uplevel"  and  "upvar"  facilities, which makes most things
            possible, if not graceful.)

            In the end, there was no candidate language  that  seemed  a
            closer fit to our needs than Tcl, but we recognized from the
            start that the language would have to evolve before it could
            be  standardized.    This is precisely the process we sought
            to initiate.

            MIME Types for Safe-Tcl

            With the emergence of MIME  [3]  as  the  widely-implemented
            standard  representation  for  multimedia mail, it was clear
            from the start that we wanted Safe-Tcl to be MIME-smart.  We
            defined two new MIME content-types for Safe-Tcl.

            The first, "application/safe-tcl", is the MIME  content-type
            for an actual Safe-Tcl program.  That is, a Safe-Tcl program
            may be included as  data  anywhere  in  a  MIME  message  by
            labeling  it  with  this  content-type value.  An additional
            parameter that may be provided on the content-type  line  is
            the  "evaluation-time"  parameter, which may have one of two
            values, "activation" or "delivery".  If the  evaluation-time
            is  "activation",  this  means  that  theprogram  is  to  be
            evaluated when the user reads the message, i.e. the  message
            is  an  active  mail  message,  as  described above.  If the
            evaluation-time is "delivery", then the program is  intended
            to  be evaluated in a non-interactive process at the time of
            final message delivery, i.e. when the message  is  delivered
            to  the  user's  mailbox.   In  neither  case are any unsafe












            primitives to be made available to  the  program.   (It  is,
            however,  desirable  to  have  a  mode in which the Safe-Tcl
            interpreter makes  the  unsafe  primitives  available  to  a
            program that is not received in the mail, but is supplied by
            the user as part of his  customization  environment.)   This
            reflects the basic enabled mail model set forth in [13].

            The second content-type we  defined  is  "multipart/enabled-
            mail".   This is a new MIME compound type, which (as per the
            MIME standard) shares a common syntax with  all  other  MIME
            compound  types,  but which has different semantics.  A MIME
            object of type multipart/enabled-mail has exactly  two  sub-
            parts.   The  first of these is an arbitrary MIME object (of
            any content-type, including possibly another compound type).
            The  second  is  of type application/safe-tcl.  The intended
            semantics are that the first MIME entity is not displayed to
            the  user, but rather is made available for the manipulation
            of the Safe-Tcl program.

            One advantage of this approach is that if a message of  type
            multipart/enabled-mail  is  read  using  a  mail  tool  that
            understands  MIME  but  does  not  understand  the  Safe-Tcl
            extensions,  the user will be able to view all the sub-parts
            (pictures,  sounds,  etc.)  even  though   the   interactive
            structure  is missing.  This means that the sub-parts can be
            ordered and structured with such  serial  viewing  in  mind,
            possibly  even  including explanatory textual parts that are
            never actually used by the Safe-Tcl program  when  it  runs,
            but  are  there only for serial-viewing by MIME readers that
            do  not  support   Safe-Tcl.    (Currently,   such   careful
            structuring must be done by hand, but tools to automatically
            generate this kind of message are perfectly plausible.)


























            Safe-Tcl Restrictions

            Safe-Tcl may be described as an  extended  subset  of  basic
            Tcl.  Certain Tcl commands were considered unsafe for use in
            active  mail,  and  are  not  made  available  to  untrusted
            programs.   These  include all commands that access files or
            execute system commands.  Once all of these are removed from
            Tcl,  however,  the  language has no remaining capability to
            interact with the user or the environment, so  the  addition
            of more limited commands for this purpose was essential.

            Safe-Tcl Language Enhancements

            The Safe-Tcl language supplements the restricted Tcl  subset
            with  a  number  of  commands that give untrusted programs a
            limited  ability  to  interact  with  the   user   and   the
            environment.

            Some Safe-Tcl  commands  are  used  to  store  and  retrieve
            persistent  data in a safe way.  (The storage mechanism used
            is implementation-dependent, but will  typically  involve  a
            single  file  or directory.)  The information that one Safe-
            Tcl program stores in this manner is available to any  other
            Safe-Tcl  program;  there is no mechanism for protecting one
            Safe-Tcl application from another, because there is  no  way
            of  telling  that  messages A and B are not generated by the
            same application as message  C.   This  situation  could  be
            remedied  with  authentication-smart  extensions,  using the
            mechanisms to be described below.

            A great many Safe-Tcl commands deal with  messaging-specific
            details  such  as  address  and  date  parsing,  MIME object
            composition  and  decomposition,  and  so  on.   This  gives
            language-level support for some of the most commonly-desired
            actions that users will want to take with Safe-Tcl.

            Additional Safe-Tcl commands  allow  untrusted  programs  to
            send  mail  and  print  data,  but  only  after  the data in
            question is presented to the user and the user's consent  is
            obtained.

            Another Safe-Tcl command is used  to  access  a  distributed
            library  of Safe-Tcl extension programs.  Such libraries may
            be obtained locally or  from  a  user-authorized  repository
            elsewhere  on  the network, but should only refer to sources
            trusted by the user.












            Safe-Tcl Interface Styles

            Most of the  remaining  Safe-Tcl  commands  deal  with  user
            interface  issues.   Safe-Tcl seeks to have the universality
            of interface of the ATOMICMAIL program, as described  above,
            but  without  precluding  the possibility of having Safe-Tcl
            programs actually be pleasant to use.  This goal is achieved
            by the introduction of a notion of user interface styles.

            Each Safe-Tcl user interface style is, in essence, a package
            of   Safe-Tcl   extensions   that   permit   user  interface
            programming  on  a  certain  platform  or   platforms.    In
            particular,  Safe-Tcl  defines  a  user  interface  style of
            "Tk3.6" for Tk-based graphical  interaction  under  the  X11
            window system.  Safe-Tcl also defines a user interface style
            of "generic" for user-interface-independent interaction,  in
            the  manner of ATOMICMAIL.   The Safe-Tcl interpreter always
            provides a global  variable,  SafeTcl_InterfaceStyle,  which
            contains  a  list  of  interface  styles  supported  by  the
            currently running Safe-Tcl interpreter.   This  list  always
            includes "generic".

            This means that, with the  current  system,  one  can  write
            Safe-Tcl   code  that  checks  the  locally  available  user
            interface styles, providing a  high-quality  graphical  user
            interface  if  X11 is running, and providing a less pleasant
            but  still  usable  interface  if  X11   is   not   running.
            Eventually,   it  is  anticipated,  there  may  be  Safe-Tcl
            interface  styles  for  Windows,  Macintosh,  or  any  other
            important   platforms.    (Eventually,   it  might  also  be
            desirable to define an abstract user interface style that is
            both   system-independent   and   graphically-oriented,  the
            higher-level  analog  of  the  "generic"  style.)   But  any
            program  that  has  a fallback to the "generic" case will be
            able to run with any Safe-Tcl interpreter.  In this  manner,
            Safe-Tcl  provides  a  user interface that is no better than
            ATOMICMAIL's in the worst case, but considerably  better  in
            many other cases.

            Safe-Tcl Multimedia Capability

            Designing Safe-Tcl with MIME in mind made it almost  trivial
            to  give  the  language rich multimedia capability, a marked
            contrast  with  previous  systems  for  enabled  mail.    In
            particular,  the  language includes primitives for getting a
            list of parts  inside  a  multipart  MIME  object,  and  for












            displaying any particular subpart.  The latter functionality
            is implemented by calling a general-purpose  MIME-displaying
            tool.   Our  implementation  works  with  either of two such
            interpreters, mhn or metamail.

            The simple Safe-Tcl primitives for MIME  access  open  up  a
            rich  range  of  multimedia  behaviors, such as offering the
            user a button to click on to see a  video  clip,  and  makes
            Safe-Tcl  suitable as the "control structure" for almost any
            interactive  multimedia  application.   In  fact,  when  the
            interpreter  is  run  without the "safe" mode, restoring all
            the  power  of  full  Tcl  while  retaining   the   Safe-Tcl
            extensions,  the  result  is an extremely powerful scripting
            language   for   arbitrary    (non-mail-based)    multimedia
            applications.

            Safe-Tcl Extensions

            Because Safe-Tcl replaces general Tcl primitives with  safer
            but  much  less  powerful  primitives, it is inevitable that
            application writers will think of things that could be  done
            safely,  but  only  with  the introduction of a new Safe-Tcl
            command.   In  previous  systems,  this  would   have   been
            intractable, especially in a distributed environment, due to
            the sophistication needed to modify the language interpreter
            and  even  more  importantly  to  the  extreme difficulty of
            getting such extensions installed everywhere on the network.

            Two aspects of Safe-Tcl's design make the problem much  more
            tractable:  twin interpreters and distributed libraries.

            Because the basic Tcl language was designed to  be  embedded
            in  larger  applications,  the  implementation  is extremely
            sensitive to the possibility that there  might  be  multiple
            Tcl-based  extension  languages  in  a  single  process  and
            address space.  For this reason, Tcl's key  data  structures
            are  not  global,  but  are tied to an object known as a Tcl
            interpreter.  Multiple Tcl interpreters in a  given  process
            can   implement   different  Tcl-based  extension  languages
            without interfering with each other.

            The  implementation  of  Safe-Tcl  relies  heavily  on  this
            feature,  and  is  based on a "twin interpreter" model.  The
            Safe-Tcl  process  contains  two  interpreters,  a   trusted
            interpreter  and  an  untrusted interpreter.  Untrusted code
            (such as  an  active  mail  message)  is  evaluated  in  the












            untrusted  interpreter,  which  is  modified in all the ways
            described above.  The  trusted  interpreter  never  directly
            evaluates  untrusted  code,  but  may  be used to extend the
            untrusted interpreter.  This is done by defining a procedure
            in  the  trusted  interpreter,  and then exporting it to the
            untrusted interpreter.  This effectively makes a new bit  of
            functionality   available   to  untrusted  programs  without
            actually modifying the underlying C program that  interprets
            the  Safe-Tcl code.  As long as the extensions are carefully
            designed and implemented, this kind  of  extensibility  does
            not  compromise  security,  although  it does give users the
            ability to "shoot themselves in the foot"  by  inadvertently
            creating  unsafe  extensions.  (An important thing to avoid,
            for example, is  having  the  extension  code  evaluate  its
            arguments as Tcl subprograms, which would effectively import
            untrusted code into the trusted interpreter.)

            The relationship between the two interpreters is one of  the
            most  subtle  and  important aspects of the safe-tcl system.
            In order to use the system wisely and  safely,  it  must  be
            understood  well  by  extension programmers.  A good analogy
            from the domain of  timesharing  operating  systems  is  the
            common  distinction between "user space" and "kernel space".
            The  trusted  interpreter  operates   in   an   unrestricted
            environment,  similar  to  the  kernel  in  a UNIX operating
            system.   The  restricted  environment  of   the   untrusted
            interpreter is analogous to user space, where a more limited
            set of capabilities are available.  In  this  analogy,  each
            time   the  unrestricted  interpreter  adds  a  new  bit  of
            functionality  to  the   restricted   interpreter,   it   is
            performing the analogue of defining a new system call to the
            kernel.

            The twin interpreter model makes it much  easier  to  safely
            extend   the   functionality   of  the  restricted  Safe-Tcl
            language, but does not address the problem  of  distributing
            extensions  on  the  network.  For this, Safe-Tcl provides a
            primitive called "SafeTcl_loadlibrary".  This primitive will
            attempt  to  find  and  load  a specified Safe-Tcl extension
            package.  By default, the interpreter will only look in  the
            local Safe-Tcl libraries for such extensions, but the system
            can be configured to download extensions from a trusted  FTP
            site  as well.  Thus a community of users who share trust in
            such a repository can all have their  Safe-Tcl  interpreters
            simultaneously extended by the addition of an extension file
            to an FTP repository.












            Authentication and Safe-Tcl

            Although  the  Safe-Tcl  interpreter  does   not   currently
            implement  any  authentication  mechanism,  the language was
            designed with authentication in mind.   In  particular,  the
            interpreter  provides  a  global associative array variable,
            SafeTcl_services, which is used  to  indicate,  among  other
            things,  the  authenticated  identity  of  the author of the
            program.  If such an authenticated  identity  is  available,
            then  the value of SafeTcl_services(authentication) contains
            it, and this identity may be used by Safe-Tcl extensions  to
            provide  different  levels of functionality to messages from
            trusted recipients.

            IV.  An Example Program

            As with almost any programming language, a  sample  Safe-Tcl
            program long enough to be truly interesting would not fit in
            a paper such as this one.   The  following,  however,  is  a
            simple  program  that  demonstrates  some important Safe-Tcl
            functionality.  It offers  the  reader  the  opportunity  to
            order a Bill Clinton T-shirt, using a graphical interface if
            Tk is running and a generic interface otherwise:

            proc ordershirt {} {
              SafeTcl_sendmessage  -to tshirts@nowhere.really \
                  -subject "Shirt request" \
                  -body [SafeTcl_makebody "text/plain" \
                          [SafeTcl_getline "What  size  t-shirt  do  you
            wear?"
                                      "medium"] "" ]
                exit
            }
            if {[lsearch $SafeTcl_InterfaceStyle Tk3.*] >= 0} {
                set foo [mkwindow]
                message $foo.m -aspect 1000 \
                 -text "Click below if you want a free Bill  Clinton  t-
            shirt!"
                button $foo.b -text "Click here for free shirt!" \
                    -command {ordershirt}
                 button  $foo.b2  -text  "Click  here  to  exit  without
            ordering" \
                     -command exit
                pack append $foo  $foo.m  {pady  20}  $foo.b  {pady  20}
            $foo.b2 {pady 20}













            } else {
                set ans [string index \
                            [SafeTcl_getline "Do you want a free Clinton
            t-shirt? "
                                        "No"] 0]
                if {$ans == "y" || $ans == "Y"} {ordershirt}
                exit
            }

            The screen images that follow show how this process proceeds
            when the Tk interface is in fact available.

                D'l 367p 0.0i'D'l 0.0i 180p'D'l -367p 0.0i'D'l 0.0i














            -180p'


                                 The second screen:

                D'l 364p 0.0i'D'l 0.0i 117p'D'l -364p 0.0i'D'l 0.0i









             -117p'

                                 The third screen:




















                D'l 498p 0.0i'D'l 0.0i 164p'D'l -498p 0.0i'D'l 0.0i













            -164p'


            V.  Status,  Availability, and Future Prospects of Safe-Tcl
            and Enabled Mail

            The Safe-Tcl specification and our implementation of it were
            made  freely  available  on  the Internet in December, 1993.
            With the exception of the  authentication  mechanisms,   the
            implementation completely implements the specification.  The
            documentation and implementation  may  be  obtained  on  the
            Internet via anonymous ftp from ftp.ics.uci.edu, in the file
            "mrose/safe-tcl/safe-tcl.tar.Z".    An   Internet   Safe-Tcl
            mailing  list  may  be  joined  by sending mail to safe-tcl-
            request@cs.utk.edu.

            Unlike prior languages for enabled mail, the authors believe
            that  the  Safe-Tcl technology is complete and robust enough
            to serve as the first real open platform  for  mail  enabled
            applications.   It  is  our  hope  that  many  people in the
            Internet community will develop  Safe-Tcl  applications  and
            extensions.

            If successful, this technology will  be,  for  most  of  the
            world, the first clear glimpse of the power of enabled mail.
            As such, we expect that it will teach us  a  lot  about  the
            design  requirements for an enabled mail language.  For that
            reason, we are not rushing to try  to  obtain  any  kind  of
            official  standardization  status for the language, but will
            consider taking that  step  after  accumulating  substantial
            real-world  experience  with  Safe-Tcl.  Eventually, we hope
            that Safe-Tcl will either evolve into the standard  language
            for  enabled mail or else strongly influence the design of a












            successor language that will fill that role.

            Acknowledgements

            Safe-Tcl was implemented  by  Marshall  Rose  and  Nathaniel
            Borenstein.    The   implementation   would  not  have  been
            possible, however, without the solid Tcl/Tk  code  base  and
            consistently helpful advice provided by John Ousterhout.  We
            have also benefited from the comments of several  people  in
            the process of designing Safe-Tcl, notably Dave Crocker, Ned
            Freed, Karl Lehenbauer,  Daniel  Newman,  Rich  Salz,  Allan
            Shepherd,  and  Peter Svanberg.  I am grateful to Ralph Hill
            and Marshall Rose for their comments on an earlier draft  of
            this paper.

            References

            1.  Borenstein, N; Thyberg, C.   "Power, Ease  of  Use,  and
            Cooperative  Work in a Practical Multimedia Message System",
            Int. J. Man-Machine Studies, April, 1991.

            2.   Forsdick,  H.C.,  et  al.,  "Initial  Experience   with
            Multimedia  Documents in Diamond", Computer Message Service,
            Proceedings IFIP 6.5 Working Conference, IFIP, 1984.

            3.  Borenstein, N., Freed, N.  MIME (Multipuprpose  Internet
            Mail Extensions), RFC 1521.

            4.Ousterhout, J., "Tcl: An  Embeddable  Command  Language.",
            Proc. USENIX Winter Conference, January 1990, pp. 133-146.

            5. Ousterhout, J., Tcl and the Tk  Toolkit,  Addison-Wesley,
            Reading Massachusetts, 1994.

            6.  Ousterhout,  J.,  "An  X11  Toolkit  Based  on  the  Tcl
            Language.",  Proc.  USENIX  Winter Conference, January 1991,
            pp. 105-115.

            7.   Goldberg,  et  al,  "Active  Mail  -  A  Framework  for
            Implementing Groupware",  CSCW '92 proceedings, Toronto.

            8.  Vittal, John, "Active Message  Processing:  Messages  as
            Messengers",  in  Computer  Message  Systems,  R.  P. Uhlig,
            editor, North-Holland Publishing Company, 1981.














            9.  Hogg, John, "Intelligent  Message  Systems",  in  Office
            Automation,  Dionysios Tsichritzis, editor, Springer-Verlag,
            1985.

            10.  Borenstein,  N.    "Computational   Mail   as   Network
            Infrastructure  for  Computer-Supported  Cooperative  Work",
            CSCW '92 proceedings, Toronto.

            11.  Linn, J., "Privacy Enhancement for Internet  Electronic
            Mail:   Part  I  -  Message  Encryption  and  Authentication
            Procedures", RFC 1421, IAB IRTF PSRG, IETF PEM WG,  February
            1993.

            12.    Zimmerman,  Phil,   "PGP   Users's   Guide",   online
            documentation, June, 1993.

            13.  Rose, Marshall, and Nathaniel Borenstein, "A Model  for
            Enabled Mail (EM)", draft in preparation.

            14.   Rose,  Marshall,  and  Nathaniel   Borenstein,   "MIME
            Extensions        for       Mail-Enabled       Applications:
            Application/Safe-Tcl and Multipart/enabled-mail", draft.

            15. Coded Character Set--7-Bit American  Standard  Code  for
            Information Interchange, ANSI X3.4-1986.



























