Remailing in safe-tcl

Hal hfinney at
Thu Feb 2 16:15:01 PST 1995

Suppose someone runs safe-tcl to process incoming mail, and supports the
"delivery-time" mode, where incoming mail programs are executed as soon
as they arrive.  (Support for this mode doesn't really exist yet, but
I am putting together a simple script to enable it.)  Here then is an
example of how a self-remailing message might look:

[Other headers]
Content-Type: multipart/enabled-mail; boundary="----- =_791623442"
Content-ID: <2269.791623082.4 at cryo>

------- =_791623442
Content-Type: application/Safe-Tcl; version="7.3"; evaluation-time=delivery
Content-ID: <2269.791623082.2 at cryo>

# Get the other sub-part of this message and send it to the desired address
SafeTcl_sendmessage -to hfinney at \
        -subject {Remailed message} -body [SafeTcl_getbodyprop 1.2 all]

------- =_791623442
Content-Type: text/plain
Content-ID: <2269.791623082.3 at cryo>

This is the body of the message, which will get remailed.  It could be
a PGP message if the server supported automatic decryption of incoming
PGP mail.  Then it could have nested remailing instructions in it.

------- =_791623442--

This is a MIME format message with two sub-parts.  The first is the
script which gets run on delivery, and the second is the "payload", the
message to be remailed.  The script is a simple one-liner which sends
the second subpart to my email address.

Safe-Tcl does allow (rather vaguely) for automatic decryption of incoming
mail, as well as authentication (so you might allow messages signed by
certain people to get access to some special functions).  There is a
rudimentary mechanism for communication between scripts and server, and
(I think) among scripts themselves, with SafeTcl_getconfigdata and
SafeTcl_setconfigdata.  These let you put in {key, value} pairs that
other scripts can read.

I don't see any straightforward way for a script to suspend itself and
re-activate on some future event (such as the arrival of another
message).  Maybe it could put its whole self into the config database as
a {key, value} pair and rely on future messages to pull it out and
execute it.  But that doesn't seem too great.

There is a lot of interest in this notion of mail messages as scripted
agents which go zipping about the network gathering data which they send
home.  I am optimistic that we will be able to get remailing capabilities
out of this infrastructure largely for free.


More information about the cypherpunks-legacy mailing list