RISKS-LIST: Risks-Forum Digest Monday 15 September 2008 Volume 25 : Issue 33 ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at <http://www.risks.org> as <http://catless.ncl.ac.uk/Risks/25.33.html> The current issue can be found at <http://www.csl.sri.com/users/risko/risks.txt> Contents: Antivirus software in critical systems? (Rob Diamond, Robert P Schaefer, PGN) Re: States throw out costly electronic voting machines (Patrick J Kobly) Re: FAA redundancy -- or lack thereof (Mike Martin) Misleading headline: 'Big bang' experiment is hacked (Gabe Goldberg) Change name, get off no-fly list (David Magda) Re: Amos Shapir on Airport Photo ID Checks (Danny Lawrence) iPhone Takes Screenshots of Everything You Do (Brian X. Chen via Monty Solomon) Re: UAL, Automated trading gets spoofed! (Howard Israel) San Francisco officials looking for hidden network device (Gabe Goldberg) PayPal phishes their own customers (Andrew Pam) Re: Risks of better security ... (Chris Adams, Ron Garret on David Bliss) Re: Control-Z vs. Bourne-Again SHell (Philippe Pouliquen) Re: Weird Clock Issue -- a single bit error (David Magda) Re: Risks of GPS Devices ... (Sergei Patchkovski) Re: Automated Bill Payments Are a Cinch: Not So Fast (CBFalconer, Sten Carlsen, Erling Kristiansen) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Mon, 15 Sep 2008 23:14:28 +1000 From: Rob Diamond <robd_at_private> Subject: Antivirus software in critical systems? (Re: jared, RISKS-25.29) I've worked in real-time (SCADA) software and related areas for years. More and more vendors are using Windoze, for the client UI machines and often for the servers as well (when *will* they learn ?). Last year I saw a Denial of Service attack on some client machines by the anti-virus and configuration management/license checking software. The user might be in the middle of dispatching a tech. to a job when the anti-virus software would start up -- the client machine would (almost completely) freeze for several minutes, until the anti-virus or conf. management software had finished running. It's incredible that the anti-virus software vendors have no idea about co-operative multi-tasking -- their software grabs the disk by the short hairs and gets its almost undivided attention until it's finished -- while the shortcomings of the OS task and I/O scheduler are pretty obvious. Even funnier (you have to laugh or you'd cry) was the initial attitude of the IT outsourcer -- "What's the problem ? *Our* job is to protect the machines we supply from viruses and manage the software configuration and OS updates -- and that's what we're doing. If the machines are a bit busy for a while that's the user's problem. Or buy a more powerful machine." Eventually the problem was reduced, but not completely eliminated, by reducing run frequency and cutting back on the checks carried out. Since this was a public utility with over a million customers the risks of not being able to dispatch a (possibly safety-critical) job while anti-virus software runs are pretty obvious. Rob D. <robd_at_private> +61-412-607-361 ------------------------------ Date: Mon, 15 Sep 2008 11:07:07 -0400 From: "Schaefer, Robert P \(US SSA\)" <robert.p.schaefer_at_private> Subject: Antivirus software in critical systems? (Re: jared/pgn, R-25.29) Virus installation is not needed for the use of the application, but it is needed for the development of the application. What may be going on is the way systems are developed today which perhaps was not so true 10 years ago. Many critical systems and embedded systems are Windows based, you can get Windows on a single card computer, or an industrial PC, etc. The principal driver is familiarity and cost. For software development, the critical system is connected to the corporate LAN and the Internet, for many reasons, particularly file sharing, corporate configuration management. Access to the Internet allows access to vendor's device drivers, documentation and to register third party code. You can even test the system on the LAN from your corporate desktop, once you've walked over to the lab to flip the power-on switch. (All sorts of risks internal to the corporation here with visible IP addresses providing access to embedded and shared devices.) Corporate policy for responsible corporations is, if your computer is on the LAN or the Internet, then Virus protection must be installed, no ifs, ands, or buts. The sneaker-net still exists where LAN access is not available for embedded systems in the corporate world, but today the memory device is the thumb-drive and no longer the floppy disk. ------------------------------ Mon, 15 Sep 2008 8:26:34 PDT From: "Peter G. Neumann" <neumann_at_private> Subject: Antivirus software in critical systems? (Re: Schaefer, R-25.33) There is usually a huge gap between theory and practice. It clearly dominates this discussion. In principle, voting systems and other critical systems should not be developed on untrustworthy operating systems with unreliable development tools and flawed software engineering. Even more important, election systems should not have to rely on easily compromisible operating systems -- especially when there is essentially no accountability, poor configuration control, poor documentation, and perhaps even some Internet access for distributing results or even for voting, as well as unaudited devices for special user needs or for real-time operational maintenance. Anyone with access to such an OS can completely compromise elections -- in the development process, in configuration and set-up, and in execution. More than anything else, we need trustworthy operating systems and trustworthy application software with thorough accountability. But that is still nowhere near enough, considering all of the extrinsic problems in registration, voter authentication, and so on. Similar concepts should apply to critical infrastructure systems -- many of which somewhat surprisingly have live direct or indirect Internet connections. By contrast, consider gambling systems -- which are held to an enormously higher standard. Antivirus software should be unnecessary by construction of those systems. HOWEVER, in practice, Robert implies, well, that's impossible because that's just the way it is. That is a terrible state of affairs. ------------------------------ Date: Thu, 11 Sep 2008 20:02:35 -0600 From: Patrick J Kobly <patrick_at_private> Subject: Re: States throw out costly electronic voting machines (RISKS-25.30) One of the frustrating things about this discussion has always been how few people who comment on the subject are actually aware of the history. I would suggest that anybody who thinks that open source will be able to provide the solution to the disaster that is eVoting read about why Jason Kitcat shut down the GNU.FREE (Free Referenda & Elections Electronically) project in 2002. http://www.free-project.org/files/free_software_odyssey.pdf As an aside, the suggestion that jurisdictions ought to provide existing equipment to researchers is a non-starter. Contractual (and legislative) restrictions on the jurisdictions exclude them from providing access to this equipment. Patrick Kobly, 56 388 Sandarac Dr NW, Calgary, Alberta T3K 4E3 http://www.kobly.com 1-403-274-9033 [The contractual restrictions may get changed sooner than you think, at least in certain states. PGN] ------------------------------ Date: Sun, 14 Sep 2008 09:35:11 +1000 From: "mike martin" <mke.martn_at_private> Subject: Re: FAA redundancy -- or lack thereof (PGN, RISKS-25.31) The outage on 26 August in the FAA Flight Planning System was more likely due to a design deficiency than, as reports claimed, lack of capacity or redundancy. I struck a similar issue some years ago with a real-time system that drove a large number of NCR automatic teller machines. The machines were capable of processing withdrawal transactions while off-line to the central computer, a measure intended to provide a degree of customer service in the event of central computer or communication link failure. As first implemented, if the central computer went down for any length of time it was virtually impossible to bring it back up again. Every time we tried it would collapse under the onslaught of accumulated off-line transactions in the ATMs that were waiting to be posted. The subsequent report from Gabe Goldberg suggests that something similar happened with the FAA system. He quotes FAA spokesman Paul Takemoto: "Basically, all the flight plans that were in the system were kicked out," Takemoto said... The system switched to the FAA's backup flight planning computer in Salt Lake City, which was quickly overwhelmed by airlines trying in vain to enter flight plans. "They just kept hitting the 'Enter' button. So the queues immediately became huge," Takemoto said. "On top of that, it happened right during a peak time as traffic was building. Salt Lake City just couldn't keep up." The Georgia computer was fixed in two-and-a-half hours but it wasn't until the FAA asked airlines to stop filing flight plans that the backlogs started to clear. Yes, you _could_ build in sufficient capacity and redundancy to handle the anomalous peak. Or you could do what we did with the ATM system, and sequence the start-up so that communication links were brought online progressively, presenting a load that remained within maximum processing capacity. Presumably the next generation flight planning system will be design to fail-over seamlessly, thus avoiding an accumulation of backlog transactions. Then this problem will never happen again -- until it does. ------------------------------ Date: Mon, 15 Sep 2008 11:25:53 -0400 From: Gabe Goldberg <gabe_at_private> Subject: Misleading headline: 'Big bang' experiment is hacked After hackers inserted a message onto the CERN website, a spokesman for CERN (which houses the Large Hadron Collider, LHC) said that "The computer is used to monitor one of the experiments at the LHC, it's nothing to do with the LHC accelerator itself or any of the control systems." http://news.bbc.co.uk/2/hi/technology/7616622.stm So the collider wasn't hacked. But was the Web site hacked or was an experiment control system hacked? Unless they're experimenting with Web servers, those are different... [Well, the monitoring system is only a Collide-O-Scope, so perhaps what you see is only an apparition anyway?] ------------------------------ Date: Fri, 12 Sep 2008 09:19:48 -0400 From: David Magda <dmagda_at_private> Subject: Change name, get off no-fly list And this illustrates just how completely useless no-fly lists are: The U.S. Department of Homeland Security wrote a letter to Labbé in 2004, saying he had been placed on their watch list after falling victim to identity theft. At the time, the department said there was no way for his name to be removed. Although Labbé wrote letters to the U.S. department, his efforts were in vain, prompting him to legally change his name. "So now, my official name is François Mario Labbé," he said. "Then you have to change everything: driver's license, social insurance, medicare, credit card--everything." Although it's not a big change from Mario Labbé, he said it's been enough to foil the U.S. customs computers. http://www.cbc.ca/canada/montreal/story/2008/09/11/nofly-name.html http://www.boingboing.net/2008/09/12/canadian-man-changes.html ------------------------------ Date: Mon, 15 Sep 2008 10:08:26 -0400 From: "Danny Lawrence" <dantemann_at_private> Subject: Re: Amos Shapir on Airport Photo ID Checks (RISKS-25.32) > The newly formed U.S. TSA has a serious problem: they have to supply > Security, but they have no idea how (and it seems that they are unaware > that nobody else does, either). But they do know that Security causes > Harassment, and they do know how to do Harassment. So the obvious logic > is, the more Harassment they'd do, the more Security will be produced. QED Another problem is the blind reliance on "The Rules" without understanding why "The Rules" are there and what they are supposed to prevent. Case in point, a woman with pierced nipples tries to board a plane, and sets off the metal detector. The TSA screeners insist that she must pass through the metal detector without setting it off, instead of noting the nipple rings and realizing that they aren't a threat. Admittedly in this case the TSA admitted that its "procedures were faulty", but didn't seem to think that the screeners did any thing wrong. http://cbs2.com/local/nipples.piercings.rings.2.686169.html [The rules can also be questioned, For example, confiscating a toothpaste tube that is 90% empty because the label says 5 ounces seems rather silly. But I suppose rules of that kind are intended to prevent screeners from using any intelligence. PGN] ------------------------------ Date: Sat, 13 Sep 2008 22:03:37 -0400 From: Monty Solomon <monty_at_private> Subject: iPhone Takes Screenshots of Everything You Do (Brian X. Chen) iPhone Takes Screenshots of Everything You Do By Brian X. Chen September 11, 2008 | 1:26:34 PM Your iPhone is watching you. If you've got an iPhone, pretty much everything you have done on your handset has been temporarily stored as a screenshot that hackers or forensics experts could eventually recover, according to a renowned iPhone hacker who exposed the security flaw in a webcast Thursday. ... http://blog.wired.com/gadgets/2008/09/hacker-says-sec.html ------------------------------ Date: Mon, 15 Sep 2008 10:47:15 -0400 From: Howard Israel Subject: Re: UAL, Automated trading gets spoofed! (Re: RISKS-25.32) "As Tribune Co. and Google Inc. pointed fingers at each other over the glitch that cratered UAL's stock [on 8 Sep 2008,] blame spread to the computers that robotically troll the Web for news stories and execute stock trades automatically." [Source: Shira Ovide and Jessica E. Vascellaro, UAL Story Blame Is Placed on Computer, *The Wall Street Journal*, 10 Sep 2008; PGN-ed] http://online.wsj.com/article/SB122100794359017593.html?mod=3Dhpp_us_whats_news ------------------------------ Date: Fri, 12 Sep 2008 15:09:45 -0400 From: Gabe Goldberg <gabe_at_private> Subject: San Francisco officials looking for hidden network device As Deep Throat (Woodstein's, not the movie star) almost said, "Follow the packets..." San Francisco officials are trying to find a device on the city's computer network that was allegedly left there by an IT worker who was jailed for refusing to divulge passwords to the city network, the IDG News Service reported on Thursday. San Francisco network administrator Terry Childs was arrested in July on four felony charges of taking control of the city's computer network and locking administrators out. He remains in jail on $5 million bail despite giving up the passwords to the mayor in a secret jail cell meeting a week later. The device, which appears to be a router providing remote access to the city's fiber Wide Area Network, was discovered on August 28, the report says. However, officials didn't know where the device was located and didn't have the user name and password to access it. When they tried to log in, a message was displayed that said the system was the "personal property of Terry S. Childs," according to a screenshot officials filed with the court. http://news.cnet.com/8301-1009_3-10039650-83.html [Earlier items on this case in RISKS-25.24-25). PGN] ------------------------------ Date: Mon, 15 Sep 2008 12:25:35 +0930 From: Andrew Pam <xanni_at_private> Subject: PayPal phishes their own customers ... Your monthly account statement is available anytime; just log in to your account at https://SECURE.UNINITIALIZED.REAL.ERROR.COM/au/HISTORY. To correct any errors, please contact us through our Help Centre at https://SECURE.UNINITIALIZED.REAL.ERROR.COM/au/HELP. The error.com domain does not belong to PayPal. Andrew Pam Serious Cybernetics http://www.sericyb.com.au/ ------------------------------ Date: Thu, 11 Sep 2008 19:21:39 -0400 From: Chris Adams <chris_at_private> Subject: Re: Risks of better security ... (Garret, RISKS-25.32) > The fact that the process started on an insecure page and ended on a > secure one didn't seem relevant. I'm a bit surprised that this is considered risks-worthy: this is how web security should work. It allowed a legitimate user access to a network resource without distracting away from the actual task they wanted to perform. It didn't provide a password which had not previously been sent to the remote server, would not have blindly continued had the x509 checks not passed, etc. The drawback appears to be that Ron's Keychain didn't have one of the extra confirmation options enabled. Password managers have various permutations on this theme but with the exception of locking when the system is suspended to disk they're largely false security: if someone untrusted gets physical access to your computer they might not be able to login to etrade immediately but they can still trivially install malware, a physical keyboard sniffer, etc. Usability is a security feature and I think this is the right balance: more prompts would lead many users to either disable them entirely or blindly hit okay, even when they get the one legitimate warning in the flood of false-positives. The major security improvement I'd make would be adding a password generator into the browser to make the use of site-specific passwords even easier. ------------------------------ Date: Thu, 11 Sep 2008 14:57:49 -0700 From: Ron Garret <ron_at_private> Subject: Re: Risks of better security ... (Garret, RISKS-25.32) [In response to a message from David Bliss <david_at_private>, interstitiated here to simplify reading. PGN] >> I find myself at a loss to suggest how this particular risk might have >> been avoided. > Really? How about "prohibit the provision of features to 'remember' > passwords, the entire point of which being to verify the identity of > *people*, not *software*"? Prohibit? How? > Or at the very least refuse to use such features. I do. This "feature" is enabled by default on OS X. I was not aware of its existence until this incident. As soon as I figured out what had happened I disabled it (which was in itself a non-trivial exercise). > I don't think the web designers are the ones guilty of idiocy. Indeed not. I never meant to imply that they were. > (yes, yes, I know you thought you understood how that "feature" worked and > thought it would prompt you for a different password before helping > itself. Surely someone of your experience should know better than to have > any faith in any software, ever?) Please read: http://cm.bell-labs.com/who/ken/trust.html and then explain to me how you propose to get along in today's world without some faith in some software sometimes. ------------------------------ Date: Fri, 12 Sep 2008 08:44:56 -0400 (EDT) From: Philippe Pouliquen <philippe_at_private> Subject: Re: Control-Z vs. Bourne-Again SHell (jidanni/chau, RISKS-25.31-32) jidanni_at_private wrote that $ sleep 55; launch_rocket causes the "launch_rocket" application to run immediately if Ctrl-C is used during the sleep period, and that replacing the ";" with "&&" cures the problem. However, David Chau replied that the "&&" has its own problem with respect to stopping the sleep command (if the intent is to temporarily halt the count-down sequence). It seems to me that this problem can be solved by putting the two commands into a shell script, so that the Ctrl-C or the Ctrl-Z applies to the script as a whole, not the individual commands. This can also be performed on the command-line with: $ ( sleep 55 ; launch_rocket ) The caveat is that I only tested this on a FreeBSD and on a Linux system, and that job-control may be somewhat operating-system dependent... To go a little further, I use the following script for playing music (I have stripped out the code comments in the interest of brevity): for song in *.mp3 do /usr/local/bin/mpg123 "${song}" & trap "kill $! ; sleep 1" SIGQUIT wait done With the above code, Ctrl-C stops playback completely, Ctrl-Z pauses playback (fg resumes) and Ctrl-\ (SIGQUIT on FreeBSD) skips to the next song. Note that the "sleep 1" after the kill is a hack to allow the sound card buffer to drain, otherwise the next mpg123 may abort if the sound resources appear to be already in use. [Similar comment noted by Michael Loftis. PGN] ------------------------------ Date: Sat, 13 Sep 2008 11:40:19 -0400 From: David Magda <dmagda_at_private> Subject: Re: Weird Clock Issue -- a single bit error (Greenwald, RISKS-25.32) > I have a battery operated clock that syncs via radio signal reception with > the atomic clock in Boulder ... It currently shows the correct time (as > of writing: 9:05 PM EDT) but shows the date as Saturday September 27th > 2008 instead of the correct date of Monday August 18, 2008! If you want to know the time, use a clock: http://www.radiocontrolledclock.com/radconwalclo1.html If you want to the know the date, use a calendar: http://www.calendars.com/ Which day it is only changes once a day, so you only have to check in the morning and not have to worry about it changing until midnight. :) Ditto for day of the week. [Well, a caveat is needed. The date changes somewhere on the planet every hour (and in some places on the half-hour). PGN] ------------------------------ Date: Fri, 12 Sep 2008 17:24:03 +0000 From: "Sergei Patchkovski" <serguei.patchkovskii_at_private> Subject: Re: Risks of GPS Devices ... (Brader, RISKS-25.32) > When you are directed to press a key, you should press and quickly > release the key. (You may need to [hold it] down for a period of time > to start a secondary function, when the instructions tell you to do so.) [Bracketed PGN correction to simplify the discussion.] Given the right circumstances, this may be the right design choice to make, odd as it sounds. A similar approach is often taken on wrist-mounted dive computers -- a short press of a button would activate a more common function -- such as switching between the current and maximum depth display, or advancing to the next page of the dive log. A two-second sustained push would activate a less common function -- such as setting the oxygen content or the surface altitude. The rationale is simple -- making an externally-protruding push button waterproof is not easy, especially if they have to operate at a few bar external pressure in a salt-water environment. Having too many of those buttons may significantly increase the chances the device will leak and ruin your dive (or worse). ------------------------------ Date: Thu, 11 Sep 2008 20:36:24 -0400 From: CBFalconer <cbfalconer_at_private> Subject: Re: Automated Bill Payments Are a Cinch: Not So Fast (RISKS-25.32) I have a simpler, and, I believe, safer system. My bank (and others) allow you to set up delayed payments from your account, or regular at stated intervals. These create checks from me to an organization, identified with my account number, etc. This handles everything without any fuss, except the telephone, which doesn't allow you to set up a constant monthly payment. The other outlays go on one of two credit cards. So, each month, I only need to set payments to the credit cards and the phone co. I pay the credit cards off entirely, so they don't have any interest involved. ------------------------------ Date: Sat, 13 Sep 2008 13:40:26 +0200 From: Sten Carlsen <sten_at_s-carlsen.dk> Subject: Re: Automated Bill Payments Are a Cinch: Not So Fast (RISKS-25.32) In Denmark the normal function of this system is different: After the setup of this agreement: Every month the bank will send you (paper or electronic form) a list of payments that have been reported by those covered by the agreement and will be due during the next month. When this is received you have about 10 days to protest any payment to the bank; if you do, the payment will not be made and you have to settle the matter with the other party by other means. In my case the agreement with the bank is such that if the bank makes an error, the bank will pay to correct it, if I make the error, I have to take the consequences. Seems reasonable to me. Example: you have an account with your hairdresser (usually not big amounts), one month he has reported to your bank that he wants 20,000.00$ from you. If you sleep and do not read your statement, he will be paid; if you notice that this is wrong and ask the bank to stop the payment, he is not paid but you will have to go down there and ask him what ... he is thinking. This is a simplified version, there are of course more details to it than this but this is how it works. This has been available from before online banking was even possible in roughly the same shape. The risks of this are not so big specially compared with who takes the penalty if errors occur. We very rarely hear that this goes wrong. ------------------------------ Date: Sat, 13 Sep 2008 19:18:10 +0200 From: Erling Kristiansen <erling.kristiansen_at_private> Subject: Re: Automated Bill Payments Are a Cinch: Not So Fast (RISKS-25.32) An automatic payment scheme like the one described has been in operation in The Netherlands for many year, to almost everybody's satisfaction. There was some reluctance in the beginning, but it subsided rather quickly. I think the key to success is that you have one month to ask your bank to undo the transaction, no questions asked. You need not give a reason, you need not prove that anybody made a mistake. You may, of course, have to fight it out later with the company that charged you, if they think you owe them money. You can file the cancel request through on-line banking, or go to your bank branch. I barely hear about any mishaps or incidents with the scheme. If people know that transactions can be reversed, the incentive for wrong-doing is greatly reduced. An additional advantage is that you avoid the mistakes you might make if you do the transfer yourself. I recently typed the wrong account number on a rather large transfer. The bank said they could not reverse the transaction, and I had to rely on the good will of the erroneous recipient. To my great relief, he returned the money promptly. ------------------------------ Date: Thu, 29 May 2008 07:53:46 -0900 From: RISKS-request_at_private Subject: Abridged info on RISKS (comp.risks) The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. The mailman web interface can be used directly to subscribe and unsubscribe: http://lists.csl.sri.com/mailman/listinfo/risks Alternatively, to subscribe or unsubscribe via e-mail to mailman your FROM: address, send a message to risks-request_at_private containing only the one-word text subscribe or unsubscribe. You may also specify a different receiving address: subscribe address= ... . You may short-circuit that process by sending directly to either risks-subscribe_at_private or risks-unsubscribe_at_private depending on which action is to be taken. Subscription and unsubscription requests require that you reply to a confirmation message sent to the subscribing mail address. Instructions are included in the confirmation message. Each issue of RISKS that you receive contains information on how to post, unsubscribe, etc. => The complete INFO file (submissions, default disclaimers, archive sites, copyright policy, etc.) is online. <http://www.CSL.sri.com/risksinfo.html> The full info file may appear now and then in RISKS issues. *** Contributors are assumed to have read the full info file for guidelines. => .UK users should contact <Lindsay.Marshall_at_private>. => SPAM challenge-responses will not be honored. Instead, use an alternative address from which you NEVER send mail! => SUBMISSIONS: to risks_at_private with meaningful SUBJECT: line. *** NOTE: Including the string "notsp" at the beginning or end of the subject *** line will be very helpful in separating real contributions from spam. *** This attention-string may change, so watch this space now and then. => ARCHIVES: ftp://ftp.sri.com/risks for current volume or ftp://ftp.sri.com/VL/risks for previous VoLume <http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue. Lindsay 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/> . ==> 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 ==> Special Offer to Join ACM for readers of the ACM RISKS Forum: <http://www.acm.org/joinacm1> ------------------------------ End of RISKS-FORUM Digest 25.33 ************************Received on Mon Sep 15 2008 - 10:45:25 PDT
This archive was generated by hypermail 2.2.0 : Mon Sep 15 2008 - 11:11:46 PDT