Re: The Remailer Crisis
But is your Mac on the Internet on a more or less continuous basis? A remailer that only works when the owner happens to log on to collect his mail is not terribly useful (though not useless, as others have also noted....just a "very unpredictable lag time" remailer, sort of the "surface mail" of e-mail).
Yes, my machine has a 56k direct line in, 24 hrs. a day, 7 days a week (during school months!;-)) The server you just mailed to is on this machine.
It happens that the Net is mainly built up of Unix boxes, hence the focus here on Unix. OS/2, Windows, and Mac boxes will be used increasinly for constant connection applications, so the idea has merit, long term.
I understand this, and am trying my best to cope. I am currently in the process of developing a name server for the Mac, because the Mac has alot against it when it comes to being a real eintity on the 'Net.
(Another nit: the Mac, which is what I also use, currently lacks preemptive multitasking. Thus, if one's Mac is playing a multimedia CD-ROM when new mail comes in, it likely won't get remailed until the first app quits or is manually switched out. (Yeah, a few things like print drivers can run in background, and maybe the new TIA emulators can trick the OS into processing SLIP or PPP mail in the background, but who knows?) The consensus is that the Mac is powerful, but it ain't cut out yet to be a Unix box.)
I agree that the Mac lacks some of the more powerful Unix features, namely preemtive multitasking, but I also believe that, at least with the newer Macs, CPU time-sharing is more efficient than it used to be. Know of Chuck Shotton's MacHTTP WWW server for the Mac? An excelent piece of software that gives literally on demand, and at least with my copy, it is always in the background. Really about the only thing that cuts out CPU timesharing is multimedia, mostly 3D grahpis games and highly intense graphics software, neither of which I use (much!;-))
The language is a lesser deal. Remember that Eric Hughes knocked out the first remailer in Perl in a few days, and MacPerl exists for the Mac. Going to Pascal would probably be more trouble than it's worth.
I thought that it was in Perl. I have tried pulling Unix Perl scripts and running them under MacPerl, but it doesn't quite do it. In fact, it usually doesn't do anything but spew errors back at you.
But the most important feature to have is a solid, reliable connection to the Net. A computer that gets taken to classes, is not connected to the Net, etc., is not very useful as a remailer.
As I noted, I have a constant 56k line in/ out. And mine never moves... it's a bit large... mine is a Quadra 660av (ugh).
(The key is not that a remailer can sometimes remail, but that it can be counted on to be part of chain without the mail getting "dropped on the floor.")
--Tim May
As far as I can tell, and maybe you have other knowedge on this, my situation should work, assuming I can run the software. What do you think? Should the remailer Perl script run under MacPerl? aka: (-: Jaeson M. Engle || jme@josaiah.sewanee.edu :-) (-: www server: http://josaiah.sewanee.edu/ :-) (-: It's February 3rd! IT'S TIME!!! Ask me for details!:-) (-: Finger 'jme@josaiah.sewanee.edu' for my Public :-) PGP block.
Rhys Kyraden wrote:
Yes, my machine has a 56k direct line in, 24 hrs. a day, 7 days a week (during school months!;-)) The server you just mailed to is on this machine.
If it's up nearly all the time (23.8 hours a day), accepting mail, then I see no reason your machine can't be a remailer. If, however, it gets turned off, taken home for the holidays, isn't always in a state to accept mail, then your remailer will get pinged and downchecked by the testing programs. (And you won't easily be able to arrange for multple "accounts" on the machine, given the sorry state of such things on the Mac.)
I agree that the Mac lacks some of the more powerful Unix features, namely preemtive multitasking, but I also believe that, at least with the newer Macs, CPU time-sharing is more efficient than it used to be. Know of Chuck Shotton's MacHTTP WWW server for the Mac? An excelent piece of software ...
Others may know more about this means for running a remailer on a Mac. I do know that Scott Collins, a Mac programming wizard who works for Apple, chose to run his remailer on Netcom's Unix machines...he would be a person to ask about what you hope to do.
I thought that it was in Perl. I have tried pulling Unix Perl scripts and running them under MacPerl, but it doesn't quite do it. In fact, it usually doesn't do anything but spew errors back at you.
I can't help here. Try the Perl discusssion groups...there's probably a FAQ on both Perl and MacPerl that discusses incompatibilities and issues. As an aside, maybe working on another project, one that is actually new territory, would be a more interesting and useful thing to do. With a 660AV, and the various audio tools available, a Mac version of PGP Phone might be a lot more interesting. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@netcom.com | anonymous networks, digital pseudonyms, zero | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. Cypherpunks list: majordomo@toad.com with body message of only: subscribe cypherpunks. FAQ available at ftp.netcom.com in pub/tc/tcmay
From: Jaeson.M.Engle@josaiah.sewanee.edu (Rhys Kyraden) I thought that it was in Perl. I have tried pulling Unix Perl scripts and running them under MacPerl, but it doesn't quite do it. In fact, it usually doesn't do anything but spew errors back at you. Perl has a lot of Unix-ism in it. The original remailer, which was really simple and stupid, only used stdin and stdout and pipes, ... Oops! Pipes may or not be supported [well] on the Mac platform. I suspect a port won't be particularly straightforward. Eric
participants (3)
-
eric@remailer.net -
Jaeson.M.Engle@josaiah.sewanee.edu -
tcmay@netcom.com