
On Aug 18, 96 11:12:16 am, Joel M Snyder, Now Overwhelmed Again wrote:
Back to the original topic: email-to-snail-mail. That's not hard, technologically. The problem as I see it is billing. If I were to offer such a service, I'd want to keep my cost to the consumer low, on the order of $0.75 to $1.00 per message, with marginal charges for additional pages. I might possibly barely be able to find some slave labor to make a profit at doing it, IF I HAD THE VOLUME (which I probably wouldn't), but the overhead of setting up a billing arrangement with every TDH who wants to do it would eat the profits up instantly.
It's difficult to conceive of a setup which a technomad would use in sufficient volumes to be cost-effective.
How about the sender provides a Digicash e-cash payment for the appropriate amount with each message, kind of like a electronic postage stamp? A script on the receiving side could automatically check the payment amount, bouncing the message back to sender with an "insufficient payment" message if necessary. Or you could use a web page to submit messages and payments. Either way no one needs to worry about billing, account tracking, etc. Payment/billing is taken care of immediately. Of course, there is some overhead with the fees on e-cash, but it probably would be more cost effective than other methods. P.S. I have an alpha version of a program which may be of interest to technomads: it automatically executes scripts received by email from a remote machine and then mails back the results. The scripts (shell scripts, perl scripts, or whatever) are encrypted and signed with PGP before being sent to provide security and prevent unauthorized users from executing scripts on your machine. The program runs on unix systems, and submissions can be from anything that runs PGP and is able to send email. See: http://www.bmen.tulane.edu/~carpente/emscrypt/emscrypt.html for more info. --Matt -- mcarpent@mailhost.tcs.tulane.edu PGP mail preferred, finger for public key.

-----BEGIN PGP SIGNED MESSAGE----- From: Rick Campbell <campbell@c2.org> To: Alan Horowitz <alanh@infi.net> CC: cypherpunks@toad.com In-reply-to: Alan Horowitz' message of "Sun, 18 Aug 1996 23:52:05 EDT." <199608190352.XAA07594@larry.infi.net> From: Alan Horowitz <alanh@infi.net> Date: Sun, 18 Aug 1996 23:52:05 -0400 (EDT) P.S. I have an alpha version of a program which may be of interest to technomads: it automatically executes scripts received by email from a remote machine and then mails back the results. The scripts (shell scripts, perl scripts, or whatever) are encrypted and signed with PGP before being sent to provide security and prevent unauthorized users from executing scripts on your machine. The program runs on unix systems, and submissions can be from anything that runs PGP and is able to send email. See: Does your mechanism do anything to prevent replay attacks? Rick -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMhiD+Bj0UvMeUesFAQF7ywP6ApwUwUWcSAs8+6HIvGkfogn69sFXJSc5 ExiktjjvzrG0903M/iihokr/xiICAAfeyylKJ4U6kbc7Ks4Tw2e0CJt5Bfrise/x nlkcSn1+3vV7vOBfSusvVEqhIzVCdFcoi3UgavwBFp9JanldsxUhEmyuZEgc0sgU Pg8QdEWcteo= =ghZA -----END PGP SIGNATURE-----

Rick Campbell writes:
P.S. I have an alpha version of a program which may be of interest to technomads: it automatically executes scripts received by email from a remote machine and then mails back the results. The scripts (shell
...
Does your mechanism do anything to prevent replay attacks?
Rick
Alan apparrently forwarded my message from technomads to cypherpunks, but since I'm on cypherpunks too, I got this message. Anyway, yes it does have a simple replay attack prevention mechanism. It keeps track of the most recent time and date stamp from the PGP signature info and refuses to executed any message that doesn't have a stamp more recent than previously executed script. This simple mechanism can cause unwanted rejection if scripts are received out of order, but multiple scripts can be batched into a single message to help overcome this. See the following URL for a discussion of known limitations and security concerns with emscrypt: http://www.bmen.tulane.edu/~carpente/emscrypt/emscrypt_doc.html#limits --Matt -- mcarpent@mailhost.tcs.tulane.edu PGP mail preferred, finger for public key.
participants (3)
-
Alan Horowitz
-
Matthew Carpenter
-
Rick Campbell