December 2003 - cypherpunks-legacy

Threats from Detweiler
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

>Brian D Williams writes: > > Just want to wish everyone a safe and happy holiday. > > Party on! > >Party? PARTY?!? How the heck am I supposed to RELAX and ENJOY myself >when we're all here just WAITING for the FINAL JUDGEMENT to fall on >our TENTACLES?!? I'm a BASKET CASE! > >-- >Mike McNally I said I wouldn't comment further on Detweiler unless and until something changed and new information came to light. Folks, this is the time to really take care of yourself. "The Executioner" announced the "time's up" and that more drastic measures are about to occur. "an12070(a)anon.penet.fi" is beyond any doubt Larry Detweiler. Many other folks have posted analyses of why this is so: the use of TeX quotes, the same vocabulary, the same agenda (against TENTACLES of the MEDUSA), and even the same arrival times of messages (I get my death threats from S. Boxx and The Executioner every night around 10 p.m. to midnight, the same time as Detweiler's rants appear). I take him seriously. He's deranged. A lot more than just slightly neurotic, he's transitioned into insanity. His religious rants ("You will be hung by the neck until dead and then sent to Hell"), his death threats, his wailings and moanings....not a lot of doubt that he's psychotic. Me, I'm keeping my guns loaded in case he decides to drive out to California and end his misery by "cutting off the Tentacles," as he keeps threatening to do.I consider this unlikely, though. Too far to drive when he's got closer targets. The "Colorado Tentacles" should be especially careful, I think. Phil Zimmermann is currently back on Larry's good side (I quote: "Phil is God"), but this may not last long. (Hint: Phil Z. was not at all happy with Larry's rant about Tentacles and his quoting of Phil's comments at that Colorado talk he gave. If Larry discovers this, as he surely will, Phil may be back in the boat with the rest of us Spawns of Satan.) I don't think I'm being alarmist in advising you all to watch out for this guy. --Tim P.S. As long as I'm on the subject, let me again say that I'm not sending Detweiler any messages at all. I don't know if he's really getting anonymous messages ("pseudospoofers"), but if he is, they're not from me. And they never have been. John Gilmore wrote a very reasonable piece, addressing Detweiler's source of confusion, and has since been flamed and ranted against. Typical. And now I'll fall silent on this matter until something new happens. I just hope it isn't a "Texas Tower" sort of violent encounter. If you've got a gun, now's the time to make sure it's handy. If you don't have a gun, consider getting one. --TCM -- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: by arrangement Note: I put time and money into writing this posting. I hope you enjoy it.

1 0

Re: holiday
by Jef Poskanzer 17 Dec '03

17 Dec '03

> Here is the secret to understanding everything. It also contains the >TRUE identity of Dark Unicorn, S.Boxx, and in fact everyone on the list. >Unfortunately, it is encrypted in an unbelievably complex algorithm based >on the factoring of infinity. Well, here it is. Crack it if you can! Since infinity is the product of all numbers, it was fairly easy to factor. Decrypted text appended. --- Jef o&#&o. ____ ___o\_ d| "9, ?H##""'`"'""'`""`"&o. ,M |b__o=q\ .d*" ___. ,==\\`Ho. H| `"" J* .,MT ,H$odH? dH#DqHD `&?. M| ,&' .dM*' +R96]#P `HMbHP `9b. Mi .HP .#HP' `""""' `9#. M| |H' HH `H, `b H| dP # `H, H |M JM .o 9HdH |b |M. |L MT ,o,HP M| M_ M. M M| ""HM. ,. .&"#HH MM H' T.HH `Mb &#?| `\.JM M# H| |b|M `Hb.^d| .,d#' ,H T| 9L*b. `M##o______oood#&9H" dH' |M `HL`H?. `H/H&$$??????o/?&' dM* |M. `Hb ?M#b_ `*&$P#MMMM#*$/*' ,H#' Mb HHH? `*Mb. `"#H###d*'' ,MP' MM. ?H' "HHb\ .##" TMb .dP' `"#MHbooooooooodHHM *M| ,#H' ""TM"'""""' *M| MH,.oH' .d| .M| |MMH' .H* HP TH, ,H' .dP'

1 0

Re: Archiving mail-lists...
by mcb＠net.bio.net 17 Dec '03

17 Dec '03

Jim choate <ravage(a)wixer.bga.com> writes: > [Plan to archive Usenet on CD-ROMs] > > I would be interested in a discussion on the mail-list on this issue. Please > refrain from sending personal mail. In particular do you think such a archive > without every members permission is un-ethical? Would a archivist necessarily > need the permission of the mail-list sponser? Actually, I would like *not* to discuss this on Cypherpunks, not because it is not an interesting subject, but because this issue (and related issues such as archiving/republishing FAQs) are being discussed in a number of other places, notably the faq-maintainers mailing list, several of the news.* groups intermittently, the moderators mailing list intermittently, and some of the legal-interest groups on Usenet. Besides, cypherpunks is already very high-volume (even if you don't count the Detweiler spew) and the issue is really not that closely related to the purpose of the list (though there are some tangential points). -- Michael C. Berch mcb(a)net.bio.net / mcb(a)postmodern.com

1 0

Making unsubscribes easier
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

As with many mailing lists, we get a lot of mail about subscribes and unsubscribes. Perhaps we should make it easier for people to get off the list, or at least find out where the list maintainer really is. Some possible approaches: 1) Add a header line to all the postings saying something like X-Send-Subscription-Requests-To: cypherpunks-request(a)toad.com 2) Add a dummy subscriber to the list that greps for "subscribe" in Subject lines and uses the vacation-mailer to reply. Some untested code that should work: #!/bin/sh # Subscription-Request-Bouncer # Set your .forward file to read # | subscription-bouncer # and activate by running vacation -I # and putting a useful message in $HOME/.vacation.msg # cat $* > /tmp/msg.$$ if egrep -i 'Subject:.*subscri' /tmp/msg.$$ then /usr/ucb/vacation -t1d cypherpunks-info < /tmp/msg.$$ fi rm /tmp/msg.$$ # You may be able to make this work with the username # in the vacation command set to cypherpunks-request 3) One problem with standard listserv and majordomo software is that it tends to believe addresses as given, without munging anXXXXX into naXXXXX or other subtleties for subscription (though it can at least forward requests from different addresses to a moderator, etc.) - can they handle this, or at least be given the job of unsubscribing people? - do they have any forgery-detection capability? Otherwise some rude person could try unsubscribing lots of people. The austin-cypherpunks listserv sent me a password for use with the listserv; is this code available? Thanks; Bill # Bill Stewart NCR Corp, 6870 Koll Center Parkway, Pleasanton CA, 94566 # Voice/Beeper 510-224-7043, Phone 510-484-6204 # email bill.stewart(a)pleasantonca.ncr.com billstewart(a)attmail.com # ViaCrypt PGP Key IDs 384/C2AFCD 1024/9D6465

3 2

Remailers: The Next Generation
by trestrab＠GVSU.EDU 17 Dec '03

17 Dec '03

Tim May writes concerning the need for "new and improved" cypherpunk remailers: ( His comments in " " or after > ) >FEATURES NEEDED IN A SECOND GENERATION REMAILER: >I. DIGITAL POSTAGE Requests for remailing would be accompanied with some form of digi-cash token, with the amount equalling (number of hops requested X price per 'stamp'). The remailers would keep the token that came with the message, and substitute one equalling # stamps -1 that would be digitally signed by it. This new token would be passed down the line, with each remailer keeping the tokens that come in and substituting their own. The tokens that are kept would be sent to a central remailer clearinghouse which would settle accounts. (See * at bottom of msg for further details on the clearinghouse.) >II. JUNK MAIL SCREENING I really don't know how best to accomplish this, either. >III. IDEAL DIGITAL MIX I'm not sure that we can achieve an 'ideal Chaumian digital mix' of messages at this time, but I have a few ideas on how we can improve on what is presently in place. Instead of padding individual messages to improve diffusion, batch several messages together to reach some 'standard' remailer msg length of n bytes, and then encrypt the batch with the next remailer's public key. Noone looking at the message as it leaves the remailer will be able to determine what # of msgs are in the batch, or which particular msgs are present (assuming they don't possess the private key of the remailer to which the batch is being forwarded). The individual msgs in a batch could be seperated with some standard remailer command, e.g. :: Cut here ------------ When the batch arrived at the next remailer, it would be decrypted and the Individual msgs seperated and placed in the remailing queue. Latency could be set by the customer with a command such as: :: Hops = x, Final = Remailer Z [ where x =1-9, and Z = either the remailer address or some alias that could be looked up in a table. 'Final' would be used in place of the nested encryption used now, so that the msg sender would only have to encrypt the final destination of his msg once. The # of Hops would be decremented by one as they were processed by each remailer. Remailers would send a msg to any other remailer randomly, except when Hops = 1, and would then forward the msg to Remailer Z. So I envision a typical msg looking like this: a. The instructions for # of hops and final remailer hop b. The instructions for final destination. c. The msg itself. c would be encrypted as the sender chooses, and then b + c would be encrypted using the public key of remailer Z ( Z to be chosen by the sender of the msg). a would be in the clear, or a+ b+ c could be encrypted with the public key of the first hop in the remailer chain. Of course, all of this ( a, b, and c ) could be done in the clear, but that would place your msg is jeopardy at each and every hop of being intercepted and read. That might be acceptable to some users, though its not very robust. Messages would be batched into groups by taking first m number of msgs whose lengths add up to the standard length n. Diffusion could be increased by shuffling the queue as each message entered the remailer. Latency and diffusion could be increased by inserting "null" msgs into the mix. A few months ago Eric Hughes mentioned that Hal Finney was forwarding list msgs encrypted to some unkwon number of persons. If he is still doing this, these msgs could be inserted into the mix by remailing each msg to _one_ of the remailers in a random fashion. These msgs could contain a command such as :: Hops = {1-9}; Final = Dev.Null They would be remailed within the remailer loop until Hops = 0, when they would be sent to the bit bucket, having served their purpose. > IV. NO LOGGING The important part of this is that the policies of individual remailers should be clear on this point, so that individuals can choose the initial and final remailers if that policy is a concern to them. As Tim says: " Sites which log but say they _don't_ is of course the real issue in the long run....I'll save this interesting topic for another article, maybe. Just be aware that this kind of "collusion" (not exactly, but this is what the literature calls related behaviors) is not easily solved with existing remailers.) " >V. HARDWARE-BASED REMAILERS No particular expertise here. I'll this to those that do. >VI. MARKETS I think it will work better if the routes are chosen randomly by the remailers ( except for final hop, see above ), as this process is more "user friendly". "Pinging" could be centralised into one clearinghouse (*see below), which handled settling of postage accounts between remailers. >VII. STANDARD FORMATS Needed, but to be decided upon. If noone else volunteers, I am willing to host a moderated Cypherpunks sub-list whose topic would be limited to remailers. Moderated, because I don't have the facilities to run an automated mail reflector and so that the signal to noise ratio is kept high enough that contributors don't drop out due to Detweiler or other noise sources. >VIII. RATINGS AGENCIES I think that diversified sources of info for "consumers" of remailers is a "good thing", but there should be a centralised clearinghouse which would concern itself solely with reconciling postage accounts and with "pinging" the remailer net at regular intervals and sending out msgs to remailers to avoid sending packets to sites which are not responding in an appropriate amount of time. ( "Appropriate" to de determined .) >IX. DIVERSE SITES Tim writes: "I also think we also need "virtual sites" which are themselves only accessible by remailers." I agree. "Other names for these sites might be "sacrificial sites" or "digital cutouts" " This can be accomplished now using the commercial site America On Line (AOL), which permits its customers to have a half- dozen or so distinct sign-on names per account. So you could run a site called "Remailer_17" (with apologies to Wm Holden) which received msgs to be remailed. These msgs could be downloaded, processed, and then uploaded through a different name entirely, "Fnord_OMF" or whatever. Unless the <insert favorite bad guy organization here> monitored _all_ possible alias accounts, they would not be able to do traffic analysis on the remailer network. >X. ATTEMPTS TO BREAK REMAILERS I'll leave discussion of this to those with greater knowledge of hacking and/or cracking than myself. * CLEARINGHOUSE The clearinghouse would not be accessible to users of remailers, but would be internal to the remailer network and handle accounting and "pinging" of remailers. Accounting example: I send a msg to remailer A, requesting # Hops = 3 and Final = remailer C. I enclose at the top of the msg digi-cash equalling the cost of three "stamps". ( One stamp for each hop.) Remailer A keeps the original digi-cash token, and substitutes one signed by it equalling two stamps. The msg is remailed to remailer B, which keeps the token supplied by remailer A and substitutes one signed by it equalling one stamp; remailer B notices that the # Hops now = 1, so it remails the msg in a packet to remailer C. Remailer C keeps B's token, and sustitutes nothing since this is the final hop for this particular msg. It then decrypts the msg and follows the remailing instructions encrypted in the "envelope". At the end of some accounting period ( day, week, month, depending on number of msgs passing through the system ) all remailers would forward their accumulated tokens to the clearinghouse, which would credit their accounts with the tokens received and debit them for the tokens sent out. The bookkeeping would get fucked up by lost transmissions, so that would have to be addressed at some point to ensure that remailers didn't just bit bucket incoming msgs and keep their stamps. The clearinghouse would also "ping" the remailers in the network at regular intervals and issue "route around" commands to the remailers if one or more sites didn't respond in a timely fashion. Thats all for now. Jeff trestrab(a)gvsu.edu

1 0

Re: The Digital Barter Economy
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

As Mike Berch pointed out, an economy can grow just fine without increasing the supply of whatever money is being used - as long as the currency is easy enough to divide into smaller quantities. That's one reason gold and silver are quite good, though paper money and numbers in a ledger do quite well also. Yes, there are difficulties with a fixed money supply in a growing economy - money that you save keeps increasing in value, and money that you borrow becomes harder to pay back. That's ok - markets adjust the interest rates on borrowed money to accomodate people's expectations. It's certainly better than having one group of people decide that there should be more money in the market, print it, and force everybody to accept it from them. On the other hand, in an international free market, no single government's fiat currency is mandated, and if the bank or its customers want to hedge their bets by using multiple currencies, it may be worthwhile to offer them, and any banking protocols we develop should probably accommodate that. Banks have to be more careful in a multi-currency environment - if gold or yen go way up in value, people can do a run on gold or yen accounts even though the dollar accounts aren't getting hit. (e.g. gold prices jumped about 20% at the beginning of the Yankee-UN-Iraqi War, and anything slumps in value after *I* buy much of it.:-) If a bank has all its assets in dollars, and Clinton decides to inflate the currency to pay for Nationalized Health Care, same problem, unless all its acocunts are in dollars and it has to convert when trading with people who use other currencies. As far as inflationary effects go, if you're a government and print lots of fiat currency, the value of that currency goes down. Same thing if you're issuing a private currency, except you can't force your citizens to accept your zorkmids in exchange for real stuff. So either you don't print more zorkmids than you can back with something, or your accountholders get upset, withdraw their money, and you're in big trouble unless you've got insurance - and insurance companies tend to make sure you have a reasonable audit program before they're willing to risk their money insuring you. Private deposit insurance *is* available - a credit union down the street from me insures accounts to $350K, which is $100K federal and $250K private insurance. The only reason it's not more widespread is that people have tended to believe government insurance was enough. Bill # Bill Stewart NCR Corp, 6870 Koll Center Parkway, Pleasanton CA, 94566 # Voice/Beeper 510-224-7043, Phone 510-484-6204 # email bill.stewart(a)pleasantonca.ncr.com billstewart(a)attmail.com # ViaCrypt PGP Key IDs 384/C2AFCD 1024/9D6465

2 1

Re: Remailers: The Next Generation
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

Phil Karn suggests we look at anonymous forwarders for IP as well as mail. It's an interesting idea - Eric Hughes and Matt Blaze have recently talked about "packet laundering" at Bay Area Cypherpunks meetings, and there's been some work done on multi-stage laundering with cutouts in the middle so it really stays anonymous. Some issues include how to pay for it (digicash is one obvious approach), how to set up rendevous, and the usual datagram-vs-circuit problems of how long to maintain an association between addresses at the forwarder. On the other hand, while the Internet is rapidly absorbing email, there are lots of email systems that are *not* IP-based, such as uucp-over-dialup, Fidonet, X.400-over-OSI, and commercial mail systems that may forward to and from the internet but run their own backbones, which help make remailers harder to trace. There's also the hybrid issue, where you tunnel IP across whatever transport medium is available - there are some people doing this over telnet, and it would be a convenient way to do things like get IP service from a flat-rate dialup access provider without paying $2/hour for SLIP, etc. Bill # Bill Stewart NCR Corp, 6870 Koll Center Parkway, Pleasanton CA, 94566 # Voice/Beeper 510-224-7043, Phone 510-484-6204 # email bill.stewart(a)pleasantonca.ncr.com billstewart(a)attmail.com # ViaCrypt PGP Key IDs 384/C2AFCD 1024/9D6465

2 1

Remailer Policies
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

A certain Tentacle of Medusa writes about problems with anonymous remailers being abused, and apparently speaks with some experience about mailbombing and other obnoxious behaviour. He suggests a few policies that he'd like somebody to enforce on remailer operators, as near as I can tell? > 1. Remailers should *not* be able to send anything to any list on the > Lists of Lists or any other known mailing list, by default. If the > moderator approves it, the remailers are allowed. Unless you control all the mail-users in the world, you can't stop this. On the other hand, it would be good if the standard remailer tools make it easy for remailer-operators to prevent the remailer from sending mail to specified destinations, and perhaps to restrict mail originating *from* certain users either in general or to specific destinations. The latter are more difficult, since networks of remailers do tend to make it difficult to tell where mail really came from, but sometimes remailer-operators need to do this in self-defense. It would also be worthwhile and courteous for remailer-operators to decide policies for blocking remailing. For example, Julf's anon.penet.fi remailer doesn't post news anonymously to newsgroups that have voted that they don't want it, and he's had to deal with a number of abusive users who he's blocked. > 2. Mailbombing through the remailers should be dampened with > limitations on the size of messages and the frequency. This is difficult to define or implement. I can often recognize mailbombing when I see it, if it's unencrypted, but a remailer operator has trouble determining whether something is a long train of abuses, or merely the transactions from the First Digital Bank Anonymous Credit Card or the responses from the ftp-by-mail server at NASA that somebody really wanted. On the other hand, letting a recipient specify throttles would be useful, and charging for remailing (whether by message, by size, or both) can also cut down on abuse. > 3. The ability for *anyone* to state that they do not want to receive > anonymous mail should be *automated*-- and the remailers should act as > a *whole network* in propagating these `requests for denial' between them. It's not difficult, if you're using a modern mail system, to filter out messages based on anything you can easily automate. There are some mailing list handlers, like the ones the Extropians bought for their list, that are friendly and flexible about it, so you can decide who to exclude, and a next generation of anonymous remailers should probably include similar capabilities. On the other hand, it's about like junk mail - there are groups of junk mail senders who will drop you from their list by a single request, and other junk mail senders who buy those requests to target you :-) I'd personally be disturbed if the software easily supported this sort of voluntary blacklisting without good authentication, since otherwise one of your Medusa buddies will go around unsubscribing people from anonymous remailer lists who don't want to unsubscribe; digicash banks and customers and political organizers are particularly vulnerable to this kind of abuse. > 4. You should keep and pass around lists of people that have caused one > remailer operator problems, so that others have the option of denying service. I thought *you* were the one who was just complaining about remailer operators who divulge the identity of their users, though maybe I misinterpreted you. While people who abuse remailers as publicly as you do are easy to put on these lists, most abusers are probably doing so for the fun of abusing people rather than to make a point about how easy these systems are to abuse, so they're more difficult to stop without violating privacy. This also opens up the possibility of forged abuse, with an attempt to get someone widely blacklisted, and censorship by remailer operators claiming a user is abusive. Then, of course, there are people who call for others to be Shunned, while making nuisances of themselves.... Bill # Bill Stewart NCR Corp, 6870 Koll Center Parkway, Pleasanton CA, 94566 # Voice/Beeper 510-224-7043, Phone 510-484-6204 # email bill.stewart(a)pleasantonca.ncr.com billstewart(a)attmail.com # ViaCrypt PGP Key IDs 384/C2AFCD 1024/9D6465

1 0

Re: Remailers: The Next Generation
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

The issue of bogus traffic between remailers is yet another parallel to the Crying of Lot 49 :-) Got to send at least one every week to keep the system going..... On the other hand, some of those mail folders are really named WASTE and not W.A.S.T.E., as I found out from my ATTMAIL friendly user interface one day :-) As far as telling real traffic from bogus traffic on remailers goes, the implementation issues are much different between cleartext remailers and remailers that accept encrypted mail. The latter, if anybody's written and implemented them, can easily handle bogus mail, since eavesdroppers can't tell it form the real stuff. It would be helpful if we agree on a standard format for mail that should be discarded by remailers, e.g. X-Anon-Discard: N would either be discarded immediately or possibly be forwarder to another destination with N replaced by N-1. Alternatively, sending mail to some remailers without the Anon-Remail-To: or equivalent header may cause it to be sent to a real person; creating a standard "discard" user on some machines or having the remailer discard mail from the local MAILER-DAEMON equivalent will allow anon-forwarding to bogususer on whatver machine. Bill # Bill Stewart NCR Corp, 6870 Koll Center Parkway, Pleasanton CA, 94566 # Voice/Beeper 510-224-7043, Phone 510-484-6204 # email bill.stewart(a)pleasantonca.ncr.com billstewart(a)attmail.com # ViaCrypt PGP Key IDs 384/C2AFCD 1024/9D6465

1 0

mailing list software
by rjc＠gnu.ai.mit.edu 17 Dec '03

17 Dec '03

If you really want to block posters and trap unsubscribe messages, cypherpunks is welcome to use the extropian's list software (by the end of next week it should be complete enough for someone else to run it without my help) Here's what it can do: Major: o modular design o mail delivered by custom "user agents" which can filter a user's mail at the distribution site (``remote kill file'') o remote system administraion (optional) o password authentication (optional) o accounting system for commercial "pay for use" subscription mode (optional) o caches messages (user definable) so users who filter a thread can retrieve it later o internalized cron for running time dependent activities (right now, the utilities that come with it generate weekly list statistics (with pretty ascii graphs), back up user list, move and compress logs, send digests, filterlists, and more) o incoming filter interface for doing useful things like decrypting signed messages or remapping anonymous id's into real e-mail addresses (``cryptofilt'' is a utility I wrote to try this out, although it needs lots of work) o user controllable digestification - users can turn digest mode on or off and alter the size of their digests o nightly filter list - when messages are filtered out by your filtering agent, you still get a list of who and what was filtered incase something was killed that you wanted to receive. You can then request to have it resent o anti-spamming routines * small messages can be configured to be trapped (such as 1 liner ``unsubscribes'' which are then forwarded to the list administrator) * large messages are truncated and stored for later retrieval for those who request them (configurable, I have it set to 50k right now) * blacklist - a regexp can be applied to incoming headers to prevent certain addresses getting through * ``members only mode'' - the list software rejects posts from those who are not subscribed o duplicate messages trapped - the list software keeps a recent database of message-ids and their header info o thread tracking via subject and ``in-reply-to:'' o built in help system o automatic sending of welcome/goodbye messages for subscribe/unsubscribe o automated billing (part of the accounting system) o complete logging of almost every list transaction (optional) o cpu cost logging (in case the list is run from a commercial service like the extropians where we have to pay to run the list) o distributed distribution - if your machine can't handle the mail bandwidth, the list software packs up the message and the list of users it is addressed to and sends it off to another machine for delivery The delivery agent which comes with the software supports the following: exclude messages by user exclude messages by thread include messages by user include messages by thread Several people on Extropians leave their agent settings in ``exclude all'' mode. They then view the list of filtered messages and include the threads which interest them. ``exclude user detweiler|sboxx'' would prevent Detweiler's posts from reaching you for example. (assuming he wasn't blacklist or he wasn't a subscriber and the list software was in members only mode) Other agent commands: private - automatically deliver response to a list of users privately and set ``reply-to'' to point to you resend - grab ranges of messages or messages by thread from the message cache sorts them into a digest and sends them to you search - performs an agrep on the cache and sends you a list of messages that match The disadvantages of running it: o command syntax learning curve for new users o documentation sucks (virtually nonexistent) o code needs to be cleaned up a lot. I learned perl at the same time I wrote it. Fortunately, perl is easy to learn and the greatest language in the universe. o cpu hog (5-8 seconds to process a message, only a problem if your list is high volume like extropian's which averages 50 messages per day) (extropians runs multiple agents so our cpu is much higher) o complicated to set up (but easy to administrate) o a little bugged, because I keep extending it however in the two weeks (before classes start) I have been doing nothing but bug killing Requirements o perl o a good dbm library (normal dbm is a little tight, so users won't be able to store that many exclude settings. about 10-15 is the max) I personally recommend the berkeley db/hashing package. I recompiled perl with it and the code is faster and the disk space used is a lot less o about 4 megs disk space * 1 meg for the message cache * 1 meg for the code * 1 meg for the recompiled perl with better libdbm * 1 meg to hold the logs (although you can disable this) you can get away with 2 megs of space or less o patience I would consider leasing it (free) to cypherpunks. Other people will have to wait to get it. The reason is because I am not yet done developing it, documenting it, and I don't own it. (I developed it on a contract with Extropy Institute and they own it.) Cypherpunks has already been given permission to use it if they want (and I wish they would, or atleast run a digest list so I can resubscribe) -Ray -- Ray Cromwell | Engineering is the implementation of science; -- -- rjc(a)gnu.ai.mit.edu | politics is the implementation of faith. --

1 0