RISKS-LIST: Risks-Forum Digest Wednesday 8 May 2002 Volume 22 : Issue 06 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/22.06.html> and by anonymous ftp at ftp.sri.com, cd risks . Contents: Unprepared for cyberattacks? (NewsScan) Ashcroft wants stiffer penalties for identity theft (NewsScan) The Console Buffer Knows... (Mark Bergman) Salespionage (Rob Slade) GNU in Not Unix (Dimitri Maziuk) More on Clez (Rob Slade) Moderated mailing lists and virus scanners (Matthew Byng-Maddick) CLUTS: Composable Low-assurance UnTrusted Systems (Ben Laurie) NRC report on porn (Herb Lin) ACM invitation (Lillian Israel) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Tue, 07 May 2002 09:01:12 -0700 From: "NewsScan" <newsscanat_private> Subject: Unprepared for cyberattacks? People with knowledge of national intelligence briefings say that little has been done to protect the country against a cyberattack. Senator Jon Kyl (R-Ariz.) says: "It's a big threat, because it is easy to do and can cause great harm," and vulnerable U.S. targets are said to include the Centers for Disease Control and Prevention; FedWire, the money-movement clearing system maintained by the Federal Reserve Board; computer systems that operate water-treatment plants or that run electrical grids and dams; facilities that control the flow of information over the Internet; the nation's communications network, including telephone and 911 call centers; and air traffic control, rail and public transportation systems. Rep. Jane Harman (D-Calif.) says: "What I fear is the combination of a cyberattack coordinated with more traditional terrorism, undermining our ability to respond to an attack when lives are in danger." (USA Today 6 May 2002; NewsScan Daily, 7 May 2002) http://www.usatoday.com/life/cyber/tech/2002/05/06/cyber-terror.htm ------------------------------ Date: Fri, 03 May 2002 08:20:55 -0700 From: "NewsScan" <newsscanat_private> Subject: Ashcroft wants stiffer penalties for identity theft U.S. Attorney General John D. Ashcroft is proposing legislation increasing by 2 to 5 years the jail time for persons convicted of aggravated identity theft a crime . "The Department of Justice is committed to seeing to it that criminals and terrorists cannot find refuge in the identities of law-abiding citizens of this country." Since October 1998, 2,223 criminal cases have been filed against 2,899 defendants. The call for tougher penalties won immediate support from Democrat Sen. Dianne Feinstein of California, who chairs the Senate Judiciary subcommittee on technology, terrorism and government. (*The Washington Post*, 3 May 2002; NewsScan Daily, 3 May 2002) http://www.washingtonpost.com/wp-dyn/articles/A24368-2002May2.html ------------------------------ Date: Mon, 06 May 2002 13:13:32 +0200 From: Mark Bergman <risksat_private> Subject: The Console Buffer Knows... The advantage (and risk) of being able to use screen buffers and scroll bars to go "back in time" and see what happened in a terminal session is fairly well known, but I associate that kind of thing with fairly "intelligent" GUI terminal emulators such as xterm. I happened to be using the "GSP" (Guardian Service Processor--a set of low level hardware and diagnostic routines) to check the cause of the blinking error LED on an HP "L" class server recently. I was using a very "dumb" console--just an 80x24 monitor and a keyboard with a serial connection to the server to access the GSP. Among the dozens of commands within the GSP is a selection to show the console log. I was pleased to see that the console log contained the many diagnostic messages that are displayed when the server boots up, before logins are available. I was also very surprised to find that the log also held the screen shots of the last console login session, including a telnet session into a network switch and the complete log (not just the commands, but all output as well) of the switch reconfiguration! No passwords were visible this time, and this discovery isn't a particularly earth-shattering revelation. However, I think that there's a RISK when someone uses an apparently "dumb" device with no intrinsic "history" to connect to another device (the switch) with no command history, and yet there's a record of every screen preserved weeks later. Mark Bergman ------------------------------ Date: Mon, 22 Apr 2002 19:50:21 -0800 From: Rob Slade <rsladeat_private> Subject: Salespionage Recently a RISKS reader has been regaling me with stories about life in the marketing trenches at--well, shall we just say A Very Large Technology Company. AVLTC (TC to its very close friends), like most other technology companies, has a marketing arm. The marketing people have managed to include directives to be issued to all incoming staff. Prime among these is indoctrination about the importance of Contacts. Contacts, are, of course, the life blood of Sales and Marketing. Every Contact is to be forwarded to Marketing for inclusion in the database. And, in order for the Contact to be useful, it must include as much information about the Contact as possible. (Remember the old joke price list for Answers, Correct Answers, and so forth? Well, in the TC world, an Answer costs you a name, address, and phone number, while a Correct Answer costs you a life history. Even a Dumb Look costs you a name and phone number, at the very least.) Since TC deals in Solutions (and don't we all?), many people approach TC speakers at conferences and seminars with Problems. In order to get a TC person to even listen to your Problem (hopefully thinking that they might get back to you with a Solution) you have to give them your Contact info. And that info goes into the database. And, of course, many of the people with the most interesting Problems might work for important agencies. Like, say, the military. So TC has a Very Extensive List of names and phone numbers of people in the military, as well as other agencies. Now, given the least benefit of the doubt, we can assume that TC is not interested in espionage. What TC *is* interested in is Aggressive Marketing. So they regularly have people call the numbers in the List. And, of course, if they have no other information, and if they are worthy of their Marketing headsets, they start asking questions. In security realms this would be known as social engineering, and it is a really neat way to get people to tell you things that they ordinarily wouldn't. If you have the right number, and the right name, there tends to be a presumption that you also have the right to ask questions. Particularly if you also know the right Problem. But remember, this is not espionage, just Aggressive Marketing. Now comes an interesting twist. Assume that TC has no interest in espionage. Assume that their Marketing and Sales people are all of the highest ethical calibre. (No, Peter, this is not a military pun.) Even granted all of this, TC does not use its own sales staff to gather this information. TC sales staff are highly trained and skilled workers, and are also paid more than three dollars per hour. So TC contracts out this information gathering work to outside companies. At this point, unfortunately, the tale gets a bit fuzzy, since we don't know an awful lot about these companies, except that they are likely also the people who phone you at dinner time to sell excess credit cards and unwanted magazines. Well, we do know slightly more about these companies. Said companies provide a valuable employment opportunity to any number of rather low paid workers who are very likely industrious and entrepreneurial. And, if the lack of command of the English language is any indication, also recent immigrants to these shores. rsladeat_private rsladeat_private sladeat_private p1at_private http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: Mon, 6 May 2002 14:52:30 -0500 From: dmaziukat_private (Dimitri Maziuk) Subject: GNU in Not Unix (Re: Markettos, RISKS-22.05) Well, that particular risk is well known to professional Unix systems administrators -- in fact, I was rather surprised to see that Linux "killall" made the RISKS now: it's been [in]famous among Unix sysadmins for quite a while now. I see two issues here: one is that of false advertising, and another one -- of professionalism (not that they are entirely unrelated). Stallman's rants about "LiGNUx" have a perfectly good technical reason behind them: "Linux" (as in "OS based on Linux kernel and free software") has lots of GNU software in it, and "GNU is Not Unix". Hence, Linux is *Not* Unix, regardless of what Linux advocates may be telling us, it is "GNU". (And, BTW, Unix is Not GNU.) That was about false advertising, now let's look at professionalism. Linux killall is perfect illustration of what happens when a product is designed by a diletante. Back in 1975 professionals designed an OS called Unix. Being professionals, they realised the need for certain design principles. Such as splitting a task into a number of smaller subtasks and designing a separate tool to handle each subtask (that does one thing, and does it well)[0]. For example, shutting down a computer involves flushing (synchronizing) file buffers to disk ("sync"), killing all running processes ("killall"), and powering off the machine ("poweroff", at least on Solaris). All perfectly neat and logical. Along comes a layman who is unaware of the above principle, nor of the significant "prior art"[1]. Result? -- read Theo's message. (Various observations to show that isn't such a big problem (in no particular order): * professionals already know that similarly-named utilities often behave differently on different operating systems, * GNU folks never intended to uphold the aforementioned design principle in the first place (see EMACS), so no surprises there, after all, you'll only run "killall" on a Unix once.) We have a bigger problem with another Unix principle: source code portability. As software becomes more complex, it requires more sophisticated build tools. More and more open source software is being developed using GNU compilers and build tools, and it is becoming dependant on them. The result? -- While portability at the level of each compilation unit is still maintained, the whole thing is not portable anymore. It fails to build on non-GNU systems[2]. GNU project in particular did a great service to software community by promoting and popularizing free software. It also did a great disservice by turning the whole thing into a political issue, and pretty much ignoring the need for competence and expertise on the part of software developers. Instead of sound software engineering, we now have "Free Speech" flag-waving[3]. With more companies (individuals, governments) jumping on Linux bandwagon, the situation becomes eerily reminiscent of the recent dot-com boom; back then we had The Internet and e-words, now we have Open Source and Linux. Back then a few cautionary voices drowned in marketing hype, now they're likely to be branded Paid Advocates of Evil Entertainment Industry and Oppressors of Free Speech[tm] -- so they shut up and go learn Plan9, or something. (BTW, if it sounds like I'm singling GNU out, I'm not. Microsoft et al., did at least as much as GNU to get us where we are now. The whole thing would be very different if there was e.g. a liability clause in every software license.) But the $15 question remains: would you board an airplane designed by, say, 2nd year biology student as a night-time hobby? So what makes you think their software design skills are any better? Hmm. This came out sounding like a rant. Well, it probably is. Dima [0] Various aspects of the problems related to complex software systems are very familiar to RISKS readers. They come up in, what? -- every other RISKS issue? 25+ years ago Unix authors were well aware of them, too. [1] Irix and Solaris "killall", for examle, behave like HP-UX one -- not surprising, considering the "grand scheme of things" outlined above. [2] Anyone who ever tried building open source software on Solaris using native build tools knows that 9 times out 10 GNU "libtool" fails to link shared libraries. The remaining 1 time GNU ./configure script fails to determine compiler flags to make position-independent code (needed for said libraries). And since GNU compiler and build tools are unable to produce 64-bit code on Solaris, the libraries, and all software that uses them must be built as 32-bit binaries. Now, why did I pay for that 64-bit hardware, again? [3] And instead of one Shakespeare, we have a zillion monkeys with C compilers. As history of Usenet shows, we shouldn't expect them to come up with even "Hello World" anytime soon, not to mention "Hamlet". ------------------------------ Date: Tue, 7 May 2002 16:17:48 -0800 From: Rob Slade <rsladeat_private> Subject: More on Clez (Re: Slade, RISKS-22.05) Crying Klez: Maybe the sky *is* falling by Robert M. Slade Maybe it's because the name is unassuming, without the flash of a "Melissa" or "Loveletter" or "Chernobyl." Maybe it's because various reports have called it Klaz, Kletz, W32/Klez.[a-k]@mm, or I-Worm.Klez. Maybe it's because the public's attention has been exhausted by media viruses like Code Red. Maybe it's because there have been a number of versions, and only the latest one has made an impact. Maybe it's because the beast is bewilderingly complicated. Whatever the reason, a virus called Klez (or, more specifically, Klez.H) seems to be happily spreading far and wide, without much attention from anyone except antiviral vendors. Warnings have been issued about it, but these are often limited and unhelpful. The general media does not appear to have paid any attention to the problem at all. One of the most widespread and dangerous viruses of recent times, Klez is hard to identify, is difficult to track, is generating serious numbers, and carries a number of payloads. Also, it probably isn't the last of it's kind. Klez is actually a family of viruses. The limited information available seems to indicate that the same author or a small group, probably resident in China, is likely responsible for all of the Klez variants. Eight have been identified so far, seemingly released between the fall of 2001 and spring of 2002. Each variant has added new features and payloads. In little over half a year the Klez family has gone from being a minor nuisance to a major threat. The first version was so buggy that flaws in programming seemed to be the major concern. However, even then the virus was notable for its ambition and complexity. In addition to spreading itself, Klez dropped a virus called ElKern. (There have been reports of a new version of a new version of the CIH virus traveling with Klez, but this may be due to infection of the Klez program file itself.) The subject line, sender address, and filename attachment were all variable, avoiding the major means of e-mail virus detection. (Various Klez variant subject lines have promised games, humour, pornography, vague but important messages, and, interestingly, antiviral protection.) Klez also used a vulnerability in Microsoft's Outlook mailer (actually resident in Internet Explorer programming) that would automatically unpack and invoke the message attachment, in some cases before the message was even read by the user. (This mailer loophole, sometimes known as the IFRAME vulnerability, had actually been addressed and patched by Microsoft in March of 2001. Users who had regularly upgraded installed patches would not have been at risk of this specific function. The bug is addressed in www.microsoft.com/windows/ie/downloads/critical/q290108/default.asp and http://www.microsoft.com/technet/security/bulletin/MS01-020.asp. However, the more widely known Microsoft security bulletin, http://www.microsoft.com/technet/security/bulletin/MS01-027.asp, deals with a composite patch, and talks about browser certificates, rather than the mail problem. It is also interesting to note that, in order to use this function, Klez forms messages with a non-standard MIME [Multimedia Internet Mail Extensions] format. Non-Microsoft mailers, such as Pegasus and Netscape Communicator, may not even allow users to see the attachment, and thus, inadvertently, offer users additional protection.) The file attachment, as of version H, will have an extension of .EXE, .BAT, .PIF, or .SCR. The MIME file type will not match the extension (although that is not a reliable indicator of a virus infection). E-mail addresses used to create new infected messages are harvested from the infected machine. Recent versions of the virus also have code to use ICQ as a source of e-mail addresses. Klez.E (version 2.0, according to internal text), released in January of 2002, added file infection capabilities, so that the virus could spread using e-mail, direct copying to network shares, and infection of program files. (Windows system files were often corrupted by the infection attempts. Other files might be infected by a companion type method: the original file was renamed and hidden and a copy of Klez written with the original filename.) The virus carried its own SMTP (Simple Mail Transfer Protocol) program so that it did not need to use local mail clients. The "From" line was also faked such that if Alice received an infected message from Bob, it might not come from Bob but from Charles, who had addresses for both Alice and Bob on his infected machine. This function not only prevented tracking of the infected machine, but caused many people to try and track infections in the wrong place. In addition, the virus had a payload to overwrite text, Microsoft Word, MP3, HTML and other files with random data, thus destroying the contents. Early versions of the virus had a hidden message (in the body of the infected message) seemingly indicating that the author was trying to gain a reputation in order to get a better job. Later versions tried to kill processes of the Code Red family of worms, including Nimda, and included hidden messages suggesting that Klez was an antivirus virus. Klez.E, in addition to adding to the list of virus processes that would be stopped, also killed processes for a number of the most popular and effective antiviral programs. It would remove Windows Registry keys for antiviral software, and also corrupted checksums or deleted files for antiviral systems. (Text strings seemed to indicate that this was because the world had not offered the author a well- paying computer job.) The latest version (as of this writing), Klez.H, often sends itself in a message offering a tool to remove and immunize against Klez.E. (It purports to come from one of a number of well-known antiviral companies.) Klez.H also added a new function: it would frequently pick up a file from the infected computer and add it as an attachment to the infected message sent out. There is already one known case where a confidential negotiating document was transmitted to a mailing list of several thousand people in this manner. Fortunately, the file overwriting payload seems to have been removed. Any available virus tends to spawn variants. It is also not unusual for a virus author to improve on his (or her) own work, and release new versions. However, variants seldom involve additions of functions and features to the extent seen in Klez. The original version alone demonstrated effective social engineering and polymorphic techniques, as well as complex features that would be dangerous in conjunction with other forms of malware. In less than six months, the author (and the greatest probability is that there is a single author) has added features manipulating processes in memory, attacking antiviral and security software, increasing the means of reproduction and spread, and attacking data availability and confidentiality. It is unlikely that this is the last version of Klez that will be seen, and a number of common viruses could give the author new ideas for new payloads to add and new technologies to employ. In a sense, though, there is absolutely nothing new about Klez. Microsoft software is well-known to be full of bugs and security loopholes: Internet Explorer is much more dangerous to use as a browser than is Netscape Navigator. There are dangerous technologies in common programs that should be disabled or patched. There is a definite trend towards convergence in malware, with different types of programs supporting and distributing each other. Polymorphism has long been known in file infecting viruses: the use of variant subject lines in Klez is tame compared to the (literally) myriad forms of files generated by Tremor. Most importantly, however, your mother's old adage still holds true. "DON'T RUN THAT PROGRAM ON YOUR COMPUTER! YOU DON'T KNOW WHERE IT'S BEEN!" rsladeat_private rsladeat_private sladeat_private p1at_private http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade ------------------------------ Date: Tue, 7 May 2002 14:12:46 +0100 From: Matthew Byng-Maddick <mbmat_private> Subject: Moderated mailing lists and virus scanners Some readers of RISKS may be familiar with Dan Bernstein's ezmlm mailing list manager, and some more may have used the slightly more full-featured ezmlm-idx. In both of these, extensive use is made of a cryptographically hashed input address, to confirm particular actions. In particular, it almost always sets these addresses as the e-mail "Reply-To:" header, so that when you just hit your "Reply" button in your user-agent, things work sanely. The case of a moderated announce list managed by ezmlm-idx is no different. The moderation includes the full request (as with the rest of ezmlm), and a bit of text telling you how to moderate the message, and the "Reply-To:" header set. This would seem fine. Now let us consider the case where the moderator has some kind of virus scanning, a not entirely uncommon case in this modern world, and that we have a virus which picks senders and recipients out of addresses in your address book. The virus decides that it's going to send itself to the announce list. This should not be a problem, as the list is moderated, except, in this case, the message is included in its entirety at the bottom of the request for moderation. An online virus scanner, looking for signatures will decide (correctly) that there is a virus. It therefore replies to the sender of the message to tell them that there is a virus, but in this case, the virus software in question is slightly broken, and uses the From: and Reply-To: headers to work out where it should send the warning. But, any mail to the Reply-To: address will cause the held message to be sent out to the announcees. So the only time the protection doesn't work is when there are viruses, arguably when it most needs it. Of course, this doesn't just apply to viruses, but what happens with moderator "Out of office" autoreplies? The RISKS: Well, I can see several here * In the quest to make such things as moderation of a list easier, the MLM is using the Reply-To header so that all you need to do is reply to that virtual mailbox. There is no checking of, say, a subject line, or something that necessitates human input. * The virus scanner is non-compliant with the standards, and is delivering an effective Delivery Status Notification message (``We couldn't deliver your message because we believe it to be virus-infected.'') to address designated for user-agent rather than transport-agent use. * This case only occurs where the system sees a virus infected file, which is not a case that will be tested for when building the system. * Sending out a virus to your customers via your announce list is probably unlikely to make you popular. Matthew Byng-Maddick <mbmat_private> http://colondot.net/ ------------------------------ Date: Tue, 07 May 2002 14:10:47 +0100 From: Ben Laurie <benat_private> Subject: CLUTS: Composable Low-assurance UnTrusted Systems ezmlm, when running a moderated mailing list, sends messages to the moderators with the From and Reply-To addresses set to cause rejection and acceptance of the moderated message, respectively. If the moderators use certain virus scanning services that shall remain nameless, and a virus (such as the currently rampant Klez, which also forges the sender address, so is more likely to be accepted for moderation) is sent to the moderated list, those services report the virus to the Reply-To address (erroneously, IMO - these should be seen as delivery errors and reported to the Return-Path, see RFC 2821), causing the virus to be accepted and distributed to the list. One RISK is obvious. The other, IMO, is poorly defined standards for e-mail that make it incredibly difficult to work out what the right thing to do is in these cases. Incidentally, vacation(1) send to the From address, which will cause rejection - not such a bad outcome, but also wrong. But whose fault is the error? http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ------------------------------ Date: Mon, 6 May 2002 01:34:43 -0400 From: "Herb Lin" <HLinat_private> Subject: NRC report on porn Given RISKS readers' interest in these matters, the National Academies' report entitled "Youth, Pornography and the Internet" was released on May 2. The report examines approaches to protecting children and teens from Internet pornography, threats from sexual predators operating on-line, and other inappropriate material on the Internet. It discusses social and educational strategies, technological tools, and policy options for how to teach children to make safe and appropriate decisions about what they see and experience on the Internet. Chaired by former Attorney General Dick Thornburgh, it's the most comprehensive study yet on the topic. More information on the report is available at: http://www4.nationalacademies.org/onpi/webextra.nsf/web/porn?OpenDocument The report itself is available online at: http://bob.nap.edu/html/youth_internet/ If you are interested in a briefing on or discussions about the report, please contact the study director, Herb Lin, at 202-334-3191. ------------------------------ Date: Tue, 7 May 2002 14:26:40 -0400 From: Lillian Israel <israelat_private> Subject: ACM invitation [The Risks Forum is an official ACM activity. Although we normally never run advertising in RISKS, perhaps we owe the ACM this one. PGN] IT and computing professionals are invited to join ACM and receive a special 15% discount on their first-year membership, PLUS receive a FREE Limited-Edition IT book! A second free book is also available if you add a subscription to the optional ACM Portal (available at a 15% savings as well). ACM even has a special offer designed just for students! To learn more, and to Join ACM now, go to: http://www.acm.org/joinacm1 Some of the valuable benefits of an ACM membership include: * Full access to the Online Guide to Computing Literature (July 2002) * Free access to ACM's new Distance Learning Portal (July 2002) - 150+ online courses * A one-year subscription to "Communications of the ACM" * The option to subscribe to the enormous online ACM Portal - one of the world's largest databases of IT information and the ultimate resource for IT professionals! Find out more about the many benefits of an ACM membership, and read about the FREE Limited Edition books at: http://www.acm.org/joinacm1 ACM, the Association for Computing Machinery, is the world's leading scientific and educational society serving the IT and Computing communities. Founded in 1947, ACM has members in more than 100 countries. ------------------------------ Date: 29 Mar 2002 (LAST-MODIFIED) From: RISKS-requestat_private Subject: Abridged info on RISKS (comp.risks) The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Alternatively, via majordomo, send e-mail requests to <risks-requestat_private> with one-line body subscribe [OR unsubscribe] which requires your ANSWERing confirmation to majordomoat_private . If Majordomo balks when you send your accept, please forward to risks. [If E-mail address differs from FROM: subscribe "other-address <x@y>" ; this requires PGN's intervention -- but hinders spamming subscriptions, etc.] Lower-case only in address may get around a confirmation match glitch. INFO [for unabridged version of RISKS information] There seems to be an occasional glitch in the confirmation process, in which case send mail to RISKS with a suitable SUBJECT and we'll do it manually. .MIL users should contact <risks-requestat_private> (Dennis Rears). .UK users should contact <Lindsay.Marshallat_private>. => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risksat_private with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 21" for volume 21] http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. Lindsay Marshall has also added to the Newcastle catless site a palmtop version of the most recent RISKS issue and a WAP version that works for many but not all telephones: http://catless.ncl.ac.uk/w/r http://the.wiretapped.net/security/info/textfiles/risks-digest/ . http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/ ==> PGN's comprehensive historical Illustrative Risks summary of one liners: http://www.csl.sri.com/illustrative.html for browsing, http://www.csl.sri.com/illustrative.pdf or .ps for printing ------------------------------ End of RISKS-FORUM Digest 22.06 ************************
This archive was generated by hypermail 2b30 : Wed May 08 2002 - 17:50:46 PDT