[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Remailing in safe-tcl



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: <[email protected]>

------- =_791623442
Content-Type: application/Safe-Tcl; version="7.3"; evaluation-time=delivery
Content-ID: <[email protected]>

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

------- =_791623442
Content-Type: text/plain
Content-ID: <[email protected]>

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.

Hal