December 2003 - cypherpunks-legacy

CompuServe reports e-mail court victory
by Vipul Ved Prakash 17 Dec '03

17 Dec '03

*** CompuServe reports e-mail court victory CompuServe, after winning a court decision making unauthorized junk e-mail illegal, responded Thursday to a report that Cyber Promotions, Inc., a commercial mass e-mailer, would not accept a federal court's halting of its spamming activities directed against CompuServe subscribers. Cyber Promotions indicated that it would appeal the decision, which follows the settlement of a similar suit. That settlement allows Cyber Promotions to send junk e-mail … [View More]

1 0

RAM CHIP SALE!
by Rhode Island Business Net 17 Dec '03

17 Dec '03

RIBN appologizes for any inconvenience this e-mail may have cause. In no way does RIBN mean to offend or upset any persons, please delete the e-mail if you are not interested. Thank you. 16 Megs EDO - $76.99!! 8 Megs EDO - $36.99!! 4 Megs EDO - $19.99!! Rhode Island Business Nets Ram Blow-out SALE!! Why pay $10-15 per meg at major computer stores? Rhode Island Business Net Inc can upgrade your RAM for as low as $4.81 per meg EDO, NON EDO, or Parity. Includes installation … [View More]

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 … [View More]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." [View Less]

4 3

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.… [View More] 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 [View Less]

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 … [View More]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; } } [View Less]

1 0

Re: Cypherpunks-announce? Do we need to recreate this?
by paul＠fatmans.demon.co.uk 17 Dec '03

17 Dec '03

> Now that cypherpunks is moving, to both a newsgroup and one or more > mailing lists, there's still a need for cypherpunks-announce or > something like it. So far it's carried 1-2 announcements per month. > > Should we create it as a mailing list, moderated or unmoderated, > or as a newsgroup? (It's been a moderated mailing list, run by John and > Hugh.) I newsgrouped several sub groups along with alt.cypherpunks. alt.cypherpunks.announce alt.cypherpunks.social alt.… [View More]

1 0

Re: distributed mailing list architecture
by Peter Hendrickson 17 Dec '03

17 Dec '03

At 12:11 PM 2/7/1997, Adam Back wrote: >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. > Have one main majordomo. > Have many … [View More]mail-exploders. > 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). This mostly solves the performance problem, but performance was not the only choke point. It is important to have many machines which accept posts and which send them to other machines. (Also, many interconnections means that few messages have to go through more than two machines which should make message distribution extraordinarily fast and highly redundant. Standing in the way of the cypherpunks list will be like standing in the way of the wind.) I suggest we consider the problem of subscriptions to be independent of the problem of posting and distributing messages. Some machine owners may wish to pool subscription activities. The fast and easy approach is to have an official cypherpunks subscription page which lists all of the mail servers which will accept new subscribers. (The person who maintains this page would ideally not be somebody running a mail server.) The interested person looks at the page and then picks a majordomo to subscribe to. It seems beneficial to me from a technical and social standpoint to have a web of relationships between list managers and subscribers. If as a subscriber you have some sort of problem (technical or social), it will work better if there is just one person to talk to rather than a loose network of volunteers. Peter [View Less]

1 0

Re: anonymity and e-cash
by Sean Roach 17 Dec '03

17 Dec '03

At 10:28 PM 2/12/97 -0800, Hal Finney wrote: >From: Sean Roach <roach_s(a)alph.swosu.edu> ... >> Another idea that has been festering. If we could get a CPA involved in >> this forum, I would be willing to have h[im/er] sign my key, (which is >> seldom used, mostly because this is the only place I use e-mail), for that >> reasonable fee that CPA's can charge. I know that it is not a standard, or >> even legally recognized, post for CPA's, but I think … [View More]that enough people >> would trust them. > >The big question with identity certificates is what procedures were followed >in verifying the identity when the cert was issued. If the CPA publishes >some standard method, and his reputation is strong enough that people will >trust him to follow it, then it might well be worth money to you to have >him sign it. This is the traditional role of the Certification Authority. > >> This would take care of some of the "newly minted" key problems. Since >> getting someone who is trusted to sign your key is a recognized method of >> getting people to believe you are who you say you are. > >It depends on the circumstances where you expect to use your key. Within >a small to medium circle of associates there may be some group members >who sign keys and are trusted by other members of the group. There is >no particular reason for it to be difficult. If you want a signature which >will be accepted by everyone in the U.S. you have a harder problem. As far as I am aware, a CPA is supposed to require a photo ID. Since this is the method by which absentee voting is accomplished. A supposedly anonymous system, (using two envelopes, the postmaster only knows that you voted, the vote counter only knows that it came by mail, the public only knows how many people are absentee voters, and who, the voter assumes that the system works), requiring the CPA as a witness to the identity of the voter. The problem would be getting the public to recognize the CPA as a key signing authority. This would presumably require a public announcement, the backing of existing trusted users, etc. Personally, I think that the netherlands? toying around with the post office would be ideal for keys used solely for signing. I just wouldn't trust the government to have access to the one I used for encryption. Maybe that's a better idea. Let's all use a government accessable key for signing, making it as long as possible to reduce identity theft. And use homebrew, super encryption for the actual secrecy. Let GAK be our CPA. [View Less]

1 0

N.Y. judge rules for Planned Parenthood in web site case
by Vipul Ved Prakash 17 Dec '03

17 Dec '03

*** N.Y. judge rules for Planned Parenthood in web site case A federal judge has temporarily stopped an abortion foe from identifying his web site as belonging to Planned Parenthood and selling an anti-abortion book from that home page. The temporary restraining order, issued Wednesday, stops Richard Bucci from identifying his home page as "Planned Parenthood's Home Page" and using "plannedparenthood.com" as a domain name. Planned Parenthood, which has its own web site, sued Bucci for … [View More]

1 0

Re: alt.cypherpunks
by John Pearson 17 Dec '03

17 Dec '03

> Hey, folks, > > I thought all you had to do to create an alt.group was to have a news admin > somewhere just make a group; send out a control message of somekind. I > thought that alt groups didn't have to go through a charter, or voting > process, or anything else. They just happened. > > Then, everyone just has to tell their local news admin that they went to > see it, or they can wait until their news admin sees it flying by, and adds > it to the available … [View More]

1 0