- cypherpunks-legacy - lists.cpunks.org

Re: Cypherpunks Distributed Remailer (fwd)
by E. Allen Smith 17 Dec '03

17 Dec '03

From: IN%"ravage(a)EINSTEIN.ssz.com" "Jim Choate" 12-FEB-1997 23:19:40.35 >> From: "E. Allen Smith" <EALLENSMITH(a)ocelot.rutgers.edu> >> Someone with more experience correct me if I'm wrong (I'm just >> starting to learn about mailing list management), but isn't saving >> at least the first bounce from a given address good in order to check >> what address is the one that's actually bouncing? Admittedly, this only >> applies to badly-formed bounces. The rest can just have the address >> noted. >Hmmm, I can see saving the address causing the bounce in some sort of array >that is indexed to the majordomo subscription list for a given remailer. It >would not cost anything but overhead to save the entire message. I guess my >motivation was not that I cared their mailbox was full or it was a invalid >address but that I wouldn't be able to deliver at this time. I just don't >see any reason that it helps me to know why they can't receive mail only that >they can't. Well, if you can't deliver mail because their mailbox is full, then you should simply wait a few days before trying to deliver mail to that address. If it's because the address isn't there any more, you should delete it from the subscription lists. Otherwise, the instant people's mail quotas overflow (e.g., they're on AOL and they haven't been able to get through the clogged lines), they get bounced... or you're left with a lot of invalid addresses. The address causing the bounce is not necessarily determinable automatically from the bounce message; if it isn't, then you need to keep a copy around for a human to look at. [re: bi-directional news-mail gateways] >> >Want to volunteer? >> >> Give me some idea of how much programming knowledge, time, etcetera >> is required, please, before I can answer. I'd be renting space on some other >> computer (e.g., an account on cyberpass.net) to do it in; the only higher-level >> programming language (i.e., beyond Applesoft Basic) that I know anything of >> is Perl (and I don't know that all that well); and I am somewhat busy with >> other stuff. In other words, it depends. >Hmmm, not shure how much programming it would take - never done it myself. >I think Perl would be an acceptable language. I certainly hope to do the >majority of the scripts on the CDR in Perl myself. Perhaps there is somebody >who knows the fine points of how INN cache's messages. Redbeard and I had a >short discussion about this issue today relating to tracking messages to >reduce mail-loops. I will discuss it with him and see what happens. Given that there are pre-existing news-mail gateways, I'd think that the programs should be available. My concern on the programming is more in the realm of keeping the thing up and running. >I know exactly what you mean. I have two full-time jobs and hadn't really >thought of taking on the cpunks list in any manner. But hey, that is the >spice in life... Understood; my busy-ness with other stuff comes from being a grad student. >Give me a couple of days to look at the situation and if somebody don't beat >me to it I'll post what I find out. Cool? Looks OK. I'll also take a look around for what information I can find. -Allen

2 1

distributed mailing list architecture (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > Date: Fri, 7 Feb 1997 20:11:15 GMT > From: Adam Back <aba(a)dcs.ex.ac.uk> > Subject: distributed mailing list architecture > Igor Chudov <ichudov(a)algebra.com> writes: > > I'd suggest a simplier solution: to connect each server with a couple, > > or maybe three, other servers. This scheme is rather robust, does not > > consume too much CPU time and bandwidth, and is easy to implement. > > I'm not sure what the architecture you are suggesting is, but this is > what I suggest as the simplest to set up. I envision it to look like a fishnet. > Have one main majordomo. There should be no "one main" anything on this project. > You subscribe to the main majordomo request address, and it forwards > your subscription request to a random mail-exploder. > > You unsubscribe to the main majordomo request address, and it forwards > your subscription to all the mail-exploders request addresses > (unsubscribe traffic is low anyway, keeping track of who is subscribed > where at the main major domo doesn't seem worth it). > > Each person who wishes to run an exploder is subscribed (manually) to > the main majordomo. > > You submit articles to the main majordomo, and it sends copies of the > articles to it's subscribers (the mail-exploders). > > The mail-exploders send mail to the address on their subscriber lists. > > (John Gilmore suggested this architecture, as a simpler alternative). Simpler? Hardly. With the remailer chain proposal we could have a working remailer network up in a couple of more days. What you propose will take weeks to write and debug code and then follow it through. No, this approach is neither simple or efficient. What I call a fishnet toplogy is much cleaner. Each node only has to filter messages where it was in the source chain. Easy to do with procmail, if you look at the first example on the man page, eg how to dump to dev/null, you find a perfect example of what procmail needs to do. It does not need to know who else is on the network (as in a star) and its traffic consists of one copy of each incoming instead of n copies from each of the 'star' remailers plus the outgoing from the local subscribers. A easy protocol can be arranged so that if the downstream remailer breaks it subscribes to the next one in the chain, again easy to do with just a few lines of code... If (bounce count of next site expires) { subscribe backup feed } If (next site returns) { unsubscribe backup feed } As to the actual architecture: A --> D ^ \ ^ \ / v / v C <-- B <-- E ^ | v N (mail-news gateway) Again, several nice features are: * Can be gotten up from a stock majordom/procmail install in a trivial manner * Site only has to filter mail from itself * It only has to keep up with two sites in the network instead of many (support for limited scope and anonymity) * Each site gets a critical feed from only 1 other site so traffic of duplicates is a minimum * Except for sites on the boundary of the net every site has two places to send its output, adding to robustness, if we allow the edges to wrap (eg torus) then no sites have less than 2 other sites to send traffic to. * Supports various levels of encryption or authentication on a link by link basis, not forcing all members to submint to a general architecture * Scales easily, something the star model does not do since hub machines must grow at a rate dependant on the total number of remailers in the chain this equates to mullah and lots of it should the network take off * The actual number of machines in a given chain is flexible, I would guess the number should match a plane tiling figure, triangle (n=3), squares (n=4), or hexagons (n=6) * Traffic analysis and sync floods are harder to impliment in this architecture than a star or hub based network * Supports 'little' machines and operators who are not guru's or have deep pockets Jim Choate CyberTects ravage(a)ssz.com

1 0

Re: Excerpt on SPAM from Edupage, 11 February 1997
by Sean Roach 17 Dec '03

17 Dec '03

At 09:23 PM 2/12/97 -0800, jim bell wrote: ... >I decided long ago (okay, well, many months ago) that the "solution" is to >invent a mechanism to allow spammers/advertisers to include a small amount >of ecash as a gift with every spam. I figure that if USnail junk-mailers >are willing to pay $0.32 for postage and probably $0.50 for production, >printing, and labelling costs, all for no guarantees of results, they should >even more happy to pay, say, 10 cents to each recipient. At that rate, an average >person would probably receive enough "spam" to pay for his Internet >account, quite analogous to the way advertiser-supported TV is presented to >the public for no explicit charge. First of all, they don't spend 32 cents per post. They get one of those bulk-mail permits which allows them to send those at a significant savings. The whole package complete with the cheap "Yes, I'll try your service, and send me the free gizmo"/"No, I don't need any more services, but I could use the free gizmo" stickers probably costs well within 50 cents. TV is not a gift per say, though your origional posts, involving a cookie, suggested something closer to TV. Currently, advertiser subsidized services, like hotmail, Yahoo, and similair, are closer in that you get the gift with only the minor distraction of the advertisement. A more functional system might be to include a cryptographic "key" of only a few bytes in the e-mail post that opens some online service of relative value. Along the lines of a hidden, no URL FTP site with all the best downloads. This would not be dependant upon e-cash being in place. Would require that the customer read at least part of the message in order to get the instructions on how to use the key. Prevent the user from just handing out the key to whoever asked as it would probably have a limited lifespan. And give the sender some location from which to conduct polling, headcounts, etc.

1 0

More on Digital Postage
by Timothy C. May 17 Dec '03

17 Dec '03

At 5:00 AM +0000 2/13/97, Attila T. Hun wrote: >on or about 970212:1525 "Timothy C. May" <tcmay(a)got.net> said: >+Having said this, the flaw remains that "junk mail" is "free" to the >+sender. This is a flaw in the ontology of e-mail, and needs to be >+fixed. Digital postage is one approach. > > probably cut down on our postings to cp as well! 32 cents to post? > I'm sure Attila does not believe any digital postage scheme would fix the message rate at 32 cents, but it's an issue worth expanding upon. First, the rate would be based on true market conditions, presumably. That is, carriers of traffic would negotiate rates. Multiple stages of carriage would involve negotiation between carriers. (As with shipment of physical goods, where a shipment from Alice to Bob might involve several carriers: trucks, trains, warehouse use, delivery vans, toll road fees. All are "folded in" to the $3 or whatever charge paid by Alice or Bob, depending.) Second, the carriage charges for an ordinary e-mail message would likely be in the sub-cents range. Third, I don't see this ontological restructuring happening anytime soon. People have gotten used to "free" services. Fourth, we need to be alert to moves by the U.S. Postal Service to get a foot in the door for "digital postage." There's nothing they'd like more than having people clamor for the government to "do something!" about spam and "unwanted mail" and thus get this foot in the door. > unfortunately, until the irresponsible tone down their greed, we > need the regulation to protect ourselves from the predators. > > in other words, I agree with you in my heart, but our society > refuses to cooperate. Attila and I have had this disagreement before (last time it involved Attila's support for curfews). Attila is free to hire agents to screen his mail so he does not receive spam. He is not free, in a free society, to force such screeners upon me. Talking about "irresponsible tones" and "greed" and how we need more laws to protect ourselves from "predators" sounds more like something from the Marin County limousine liberal set than from a Utah mountain man Cypherpunk. I'm shocked, simply shocked. (:-}) --Tim May Just say "No" to "Big Brother Inside" We got computers, we're tapping phone lines, I know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^1398269 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0

Re: Procmail during the transition, anyone?
by Derek Atkins 17 Dec '03

17 Dec '03

Anil Das <das(a)sgi.com> writes: [snip] > It detects duplicates by Message-Id. Unfortunately, the messages that make it through to the cypherpunks list have their MessageID changed when they get approved. So, checking for duplicates by MessageID fails, given the current approval mechanism. :( I've informed Sandy of the problem, but he doesn't know how to preserve the original MessageIDs. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH warlord(a)MIT.EDU PGP key available

2 1

Re: Procmail during the transition, anyone?
by ichudov＠algebra.com 17 Dec '03

17 Dec '03

subs-cri-be to the unedited list. igor Derek Atkins wrote: > > Anil Das <das(a)sgi.com> writes: > > [snip] > > It detects duplicates by Message-Id. > > Unfortunately, the messages that make it through to the cypherpunks > list have their MessageID changed when they get approved. So, > checking for duplicates by MessageID fails, given the current approval > mechanism. :( > > I've informed Sandy of the problem, but he doesn't know how to > preserve the original MessageIDs. > > -derek > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH > warlord(a)MIT.EDU PGP key available > - Igor.

2 1

Re: Cypherpunks Distributed Remailer (fwd)
by E. Allen Smith 17 Dec '03

17 Dec '03

From: IN%"ravage(a)EINSTEIN.ssz.com" "Jim Choate" 12-FEB-1997 23:19:40.35 >> From: "E. Allen Smith" <EALLENSMITH(a)ocelot.rutgers.edu> >> Someone with more experience correct me if I'm wrong (I'm just >> starting to learn about mailing list management), but isn't saving >> at least the first bounce from a given address good in order to check >> what address is the one that's actually bouncing? Admittedly, this only >> applies to badly-formed bounces. The rest can just have the address >> noted. >Hmmm, I can see saving the address causing the bounce in some sort of array >that is indexed to the majordomo subscription list for a given remailer. It >would not cost anything but overhead to save the entire message. I guess my >motivation was not that I cared their mailbox was full or it was a invalid >address but that I wouldn't be able to deliver at this time. I just don't >see any reason that it helps me to know why they can't receive mail only that >they can't. Well, if you can't deliver mail because their mailbox is full, then you should simply wait a few days before trying to deliver mail to that address. If it's because the address isn't there any more, you should delete it from the subscription lists. Otherwise, the instant people's mail quotas overflow (e.g., they're on AOL and they haven't been able to get through the clogged lines), they get bounced... or you're left with a lot of invalid addresses. The address causing the bounce is not necessarily determinable automatically from the bounce message; if it isn't, then you need to keep a copy around for a human to look at. [re: bi-directional news-mail gateways] >> >Want to volunteer? >> >> Give me some idea of how much programming knowledge, time, etcetera >> is required, please, before I can answer. I'd be renting space on some other >> computer (e.g., an account on cyberpass.net) to do it in; the only higher-level >> programming language (i.e., beyond Applesoft Basic) that I know anything of >> is Perl (and I don't know that all that well); and I am somewhat busy with >> other stuff. In other words, it depends. >Hmmm, not shure how much programming it would take - never done it myself. >I think Perl would be an acceptable language. I certainly hope to do the >majority of the scripts on the CDR in Perl myself. Perhaps there is somebody >who knows the fine points of how INN cache's messages. Redbeard and I had a >short discussion about this issue today relating to tracking messages to >reduce mail-loops. I will discuss it with him and see what happens. Given that there are pre-existing news-mail gateways, I'd think that the programs should be available. My concern on the programming is more in the realm of keeping the thing up and running. >I know exactly what you mean. I have two full-time jobs and hadn't really >thought of taking on the cpunks list in any manner. But hey, that is the >spice in life... Understood; my busy-ness with other stuff comes from being a grad student. >Give me a couple of days to look at the situation and if somebody don't beat >me to it I'll post what I find out. Cool? Looks OK. I'll also take a look around for what information I can find. -Allen

1 0

Re: distributed mailing list architecture
by Thomas Roessler 17 Dec '03

17 Dec '03

Maybe you have some use for the appended perl script. I created it for a list setup quite similar to what is currently being discussed on cypherpunks. It has never ever been used in production; you'll notice yourself that the code is not too nice. The script currently tries to handle majordomo and SmartList exploders; at least SmartList needs to be hacked a little bit to avoid daily subscription approvals to people being moved between different sub-lists. Distribute and use this script freely; credit is appreciated. tlr ------------------------------ #!/usr/bin/perl ############################################################ # # $Id: distlist.pl,v 1.2 1997/01/24 17:20:38 roessler Exp $ # # # Handle distributed mailing lists. # require 'getopts.pl'; $c_sublists='lists'; # Data about the sublists $c_distfile='dist'; # A list of mail addresses $c_datafile='dist.data'; # _Our_ list of addresses $c_contact='roessler(a)sobolev.rhein.de'; # Whom to contact in case of problems $sendmail="| /usr/sbin/sendmail -t -odq"; $debug=0; # Debugging output. Can also be # turned on by using the -x switch. $signature="-- \nThis mail has been generated automatically by the distlist\n". "program. Please contact $c_contact in case of problems.\n"; @sublists=(); @newsubs=(); # # Command line processing # &dprint (1, 'Processing the command line...\n'); &Getopts('s:d:D:c:x:'); $c_sublists=$opt_s if $opt_s; $c_distfile=$opt_d if $opt_d; $c_datafile=$opt_D if $opt_D; $c_contact=$opt_c if $opt_c; $debug=$opt_x if $opt_x; # # Read the data and config files, perform various checks. # # # sublists # &dprint(1, "Reading $c_sublists..."); # format: addr:maxsubscr:listtype:password:adminrequest:maintainer open(SUBLISTS, $c_sublists) || die("Can't open $c_sublists"); SUBLIST: while(<SUBLISTS>) { next SUBLIST if /^#/ || /^$/; chop; ($addr, $maxsubscr, $listtype, $password, $admin, $maintainer) = split(/:/, $_); $s_maxsubscr{$addr}=$maxsubscr; $s_listtype{$addr}=$listtype; $s_password{$addr}=$password; $s_admin{$addr}=$admin; $s_maintainer{$addr}=$maintainer; $s_onlist{$addr}=0; $s_addem{$addr}=""; $s_delem{$addr}=""; &dprint(3,"Parsed list $addr: maximum $maxsubscr people; listtype $listtype; password $password.; administrative address $admin; maintainer $maintainer"); @sublists=(@sublists, $addr); } close(SUBLISTS); # In addition, we define a special list for people to be redistributed later. $s_maxsubscr{'later'}=100000; # Very big. ;) $s_listtype{'later'}=""; $s_password{'later'}=""; $s_onlist{'later'}=0; $s_addem{'later'}=""; $s_delem{'later'}=""; # # Read our dist file # # format: user:list if(open(DATAFILE, $c_datafile)) { &dprint(1, "Reading $c_datafile..."); USERLINE: while(<DATAFILE>) { next USERLINE if /^#/ || /^$/; chop; ($user, $list) = split(/:/, $_); # Check if the list exists; handle user. if(! $s_maxsubscr{$list}) { &dprint(2, "While checking user $user: $list does no longer exist."); $list="later"; } elsif( $s_onlist{$list} >= $s_maxsubscr{$list} ) { &dprint(2, "Warning: $list is full. Redistributing people later."); $s_delem{$list}=join(':',$user,$s_delem{$list}); $list="later"; } $s_onlist{$list}++; $u_list{$user}=$list; $deletem{$user}=$user; } close(DATAFILE); &dprint(1,"$c_datafile finished."); } else { &dprint(1, "Warning: Can't read $c_datafile."); } # # Now, read the real distribution file. # &dprint(1, "Reading $c_distfile..."); open(DISTFILE, $c_distfile) || die("Can't open $c_distfile"); DISTLINE: while(<DISTFILE>) { next DISTLINE if /^#/ || /^$/ || /^\(/; chop; if(!$u_list{$_}) { # A new member. &dprint(2, "Found a new member: $_."); @newsubs=($_, @newsubs); } else { # We know him. &dprint(3, "Well-known: $_."); delete $deletem{$_}; } } close(DISTFILE); # # Handle deletions. # foreach $user (keys %deletem) { $list=$u_list{$user}; delete $u_list{$user}; $s_onlist{$list}--; $s_delem{$list}=join(':', $s_delem{$list}, $user); &dprint(3, "Removing $user from sublist $list."); } # # Handle postponed subscriptions: The later list. # foreach (keys %u_list) { next unless $u_list{$_} eq "later"; @newsubs=($_, @newsubs); delete $u_list{$_}; &dprint(3, "Adding $_ to the list of new subscriptions. Was postponed."); } &dprint(1, "Distributing new subscriptions..."); NEWSUBS: foreach $user (@newsubs) { $avg=0.0; foreach $l (@sublists) { $avg += $s_onlist{$l}/$s_maxsubscr{$l}; } $avg = $avg / ($#sublists + 1.0); if ($avg >= 1) { &dprint(2, "Warning: All sublists are full while trying to insert $user."); } undef $possible; foreach $l (@sublists) { if($s_onlist{$l} <= $avg*$s_maxsubscr{$l}) { $possible=$l; } if($s_onlist{$l} < $avg*$s_maxsubscr{$l}) { last; } } if($possible) { $l = $possible; } $s_addem{$l}=join(':', $s_addem{$l}, $user); $s_onlist{$l}++; $u_list{$user}=$l; } # # Write our own data file. # if(open(DATAFILE, ">$c_datafile")) { foreach (keys %u_list) { printf DATAFILE "%s:%s\n", $_, $u_list{$_}; } close(DATAFILE); } else { &dprint(1, "Warning: Can't write $c_datafile."); } # # The lists have been put together. Commit the changes. # &dprint(1, "Committing the changes..."); foreach $l (@sublists) { if($s_listtype{$l} eq "majordomo") { &commit_majordomo($l); } elsif ($s_listtype{$l} eq "smartlist") { &commit_smartlist($l); } else { &dprint(1, "While trying to commit changes for $l:"); &dprint(1, "Unknown list type $s_listtype{$l}.\n"); } } # # To be done: Print out some statistics. # print "Distlist results:\n"; print "-----------------\n"; print "\n"; printf "There are currently %d subscribers on %d sublists.\n\n", scalar(keys %u_list), $#sublists+1; $full_lists=0; printf "%-40s on max\n", "Name"; printf "----------------------------------------------------\n"; foreach $l (@sublists) { printf "%-40s %4d %4d", $l, $s_onlist{$l}, $s_maxsubscr{$l}; if($s_onlist{$l} >= $s_maxsubscr{$l}) { print " *** This list is full ***"; $full_lists++; } print "\n"; } if($full_lists) { print "\n$full_lists of the sublists are *full*. Please get in touch\n"; print "with the maintainers.\n"; } print "\n\n"; print $signature; ############################################################ # # Some helper functions. # # Print out diagnostics. sub dprint { if($_[0] <= $debug) { printf STDERR "%s\n", $_[1]; } } sub commit_majordomo { my $list=$_[0]; my @bla; my $ll; my $user; &dprint(2, "Committing changes to majordomo list $list"); &dprint(3, "to be added: $s_addem{$list}"); &dprint(3, "to be deleted: $s_delem{$list}"); ($ll, @bla)=split(/@/, $list); if(!open(SENDMAIL, $sendmail)) { &dprint(1, "Warning: Can't start sendmail when committing changes to $list"); } print SENDMAIL "To: $s_admin{$list}\n"; print SENDMAIL "From: $c_contact\n"; print SENDMAIL "\n\n"; foreach $user (@bla=split(/:/, $s_addem{$list})) { print SENDMAIL "approve $s_password{$list} subscribe $ll $user\n" if $u_list{$user}; } foreach $user (@bla=split(/:/, $s_delem{$list})) { print SENDMAIL "approve $s_password{$list} unsubscribe $ll $user\n" unless $u_list{$user} eq $list; } print SENDMAIL $signature; close(SENDMAIL); } sub smartlist_xcommand { my ($list, $to, $passwd, $command, $maintainer) = @_; if(!open(SENDMAIL, $sendmail)) { &dprint(1, "Can't start sendmail when committing changes for $list"); } print SENDMAIL "To: $to\n"; print SENDMAIL "From: $c_contact\n"; print SENDMAIL "X-Command: $maintainer $passwd $command\n"; print SENDMAIL "\n\n"; print SENDMAIL $signature; close SENDMAIL; } sub commit_smartlist { my $list=$_[0]; my @bla; my $user; &dprint(2, "Committing changes to smartlist list $list"); foreach $user (@bla=split(/:/, $s_addem{$list})) { &smartlist_xcommand($list, $s_admin{$list}, $s_password{$list}, "subscribe $user", $s_maintainer{$list}) if $u_list{$user}; } foreach $user (@bla=split(/:/, $s_delem{$list})) { &smartlist_xcommand($list, $s_admin{$list}, $s_password{$list}, "unsubscribe $user", $s_maintainer{$list}) unless $u_list{$user} eq $list; } }

1 0

Keep it Simple and the Cypherpunk Way
by Tim May 17 Dec '03

17 Dec '03

(A copy of this message has also been posted to the following newsgroups: alt.cypherpunks) At 11:42 AM -0500 2/13/97, Derek Atkins wrote: >Unfortunately, the messages that make it through to the cypherpunks >list have their MessageID changed when they get approved. So, >checking for duplicates by MessageID fails, given the current approval >mechanism. :( > >I've informed Sandy of the problem, but he doesn't know how to >preserve the original MessageIDs. I will phrase my message here as respectfully as possible vis-a-vis the goals of the moderation experiment. That is, I will only deal with one aspect, the one of _costs_ of the moderation experiment. To wit, the _costs_ of the moderation experiment--Sandy's time, our time spent debating moderation, and now the issues raised by Michael Froomkin and others about dealing with the chaos of multiple, overlapping lists--greatly exceed the relatively small amount of effort it took anyone to simply delete the insult posts, the ASCII art posts, etc. I respectfully submit that the huge costs incurred on several parties have cumulatively far exceeded the minor savings of not having a handful of the 'bot-generated insults of the day and some of the ASCII art generated. As to the "comity" of the list, the moderation experiment has clearly had just the opposite effect, predictably. (Imposing comity is rarely easy, especially given an independent bunch of folks who are suspicious of moderators screening their words for evidence of non-comity!). And the ill will generated toward certain folks has been regrettable, and vastly more costly than any minor savings in not having to see a few messages. "Keep it simple, stupid," the oft-quote KISS principle. A moderation scheme--except perhaps those run very tightly a la Peter Neumann's RISKS list--almost always bogs down into debates about the moderation criteria, the acceptability of certain posts, and so on. Now we see another effect: multiple lists and a confusing array of cross-posts, mail-to-News gateways, News-to-mail gateways, etc. The "Cypherpunks Way" is to encourage and empower people to filter their own stuff, or to hire outside contractors to do it for them. Failing that, to let them twist slowly in the wind. "Think of it as evolution in action." The Cypherpunks Way is also the simplest system. I hope this episode has reminded us of this lesson. --Tim May -- Boycott "Big Brother Inside" software! We got computers, we're tapping phone lines, we know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Licensed Ontologist | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

4 3

Private property & cypherpunks
by Jim Choate 17 Dec '03

17 Dec '03

Hi, After talking w/ Sten (firebeard) I have agreed to drop the explicit PD proviso. This means the Cypherpunks Distributed Remailer is operaing under the Burne Convention of implicit copyright. This is gonna be fun. Jim Choate CyberTects ravage(a)ssz.com

1 0