[risks] Risks Digest 22.11

From: RISKS List Owner (riskoat_private)
Date: Thu Jun 06 2002 - 17:20:41 PDT

  • Next message: RISKS List Owner: "[risks] Risks Digest 22.12"

    RISKS-LIST: Risks-Forum Digest  Thursday 6 Jun 2002  Volume 22 : Issue 11
    
       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.11.html>
    and by anonymous ftp at ftp.sri.com, cd risks .
    
      Contents:
    Impact of inadequate software testing on US economy (Rick Kuhn)
    "Truncation error" found in GPS code on Int'l Space Station (George White)
    FBI's Carnivore hampered anti-terror probe (Marc Rotenberg)
    Sex, Truth and Videotaping (Gary Marx)
    Kursk submarine: to test or not to test ...? (Ken Knowlton)
    Deja vu: Stockholm power outage hits high-tech companies (Ulf Lindqvist)
    Inadvisable instructions from Sun on StarOffice 5.2 (John Sullivan)
    Confirming cricket score reason for delay (R. Jagannathan)
    Students provide bulk of tech support in schools (NewsScan)
    More on typos and homographs (Martin Wheatman)
    Please ignore the anti-shoplifting device! (Mario Hendricks)
    Re: The Klez Effect (Paul van Keep, Greg Searle)
    Re: Klez and mail loops (A. Harry Williams)
    More on Klez (Hal Lewis)
    Abridged info on RISKS (comp.risks)
    
    ----------------------------------------------------------------------
    
    Date: Wed, 05 Jun 2002 14:53:35 -0400
    From: Rick Kuhn <kuhnat_private>
    Subject: Impact of inadequate software testing on US economy
    
    NIST has released a new study conducted by the Research Triangle Institute
    that should be of interest to readers: "The Economic Impacts of Inadequate
    Infrastructure for Software Testing".  Comments and discussion are welcome.
      http://www.nist.gov/director/prog-ofc/report02-3.pdf
    
    Rick Kuhn
    
     From the summary:
    
    NIST engaged the Research Triangle Institute (RTI) to assess the cost to the
    U.S. economy of inadequate software testing infrastructure.  Inadequate
    testing is defined as failure to identify and remove software bugs in real
    time. Over half of software bugs are currently not found until downstream
    in the development process leading to significant economic costs. RTI
    identified a set of quality attributes and used them to construct metrics
    for estimating the cost of an inadequate testing infrastructure. Two in
    depth case studies were conducted. In the manufacturing sector,
    transportation equipment industries were analyzed. Data were collected from
    software developers (CAD/CAM/CAE and product data management vendors) and
    from users (primarily automotive and aerospace companies). In the service
    sector, financial services were analyzed with data collected again from
    software developers (routers and switches, financial electronic data
    interchange, and clearinghouse) and from users (banks and credit unions).
    ...the annual cost to these two major industry groups from inadequate
    software infrastructure is estimated to be $5.85 billion. Similarities
    across industries with respect to software development and use and, in
    particular, software testing labor costs allowed a projection of the cost to
    the entire U.S. economy. Using the per-employee impacts for the two case
    studies, an extrapolation to other manufacturing and service industries
    yields an approximate estimate of $59.5 billion as the annual cost to the
    nation of inadequate software testing infrastructure.
    
    ------------------------------
    
    Date: Thu, 30 May 2002 08:45:11 -0300 (ADT)
    From: George White <aa056at_private>
    Subject: "Truncation error" found in GPS code on Int'l Space Station 
    
    The following excerpt describes the resolution of a problem in the 
    GPS attitude control for the International Space Station.
    
    > From j.vanoeneat_private Thu May 30 08:28:31 2002
    Date: Wed, 29 May 2002 06:43:17 -0700
    From: Jacques van Oene <j.vanoeneat_private>
    Newsgroups: sci.space.news
    Subject: ISS On Orbit status 28-05-2002
    
    "The troubleshooting of the GPS (global position system) attitude
    errors has been successful. At first thought to be due to the high
    solar Beta angle (where fewer GPS satellites are in sight), the cause
    has now been traced to the software, which did not calculate attitudes
    correctly due to a truncated parameter. The error was eliminated, and
    the system is now working fine, even at high Beta angles, supplying
    state vector and attitude data. With Russian concurrence, GPS will now
    also provide the periodic updates of the SM's BINS strapdown
    navigation and guidance system, instead of requiring lengthy manual
    data takes by the crew using the optical PUMA system, thus saving
    valuable crew time."
    
    Not to mention the psychological benefits to the crew of one less "area of
    concern" in a setting where resolving glitches in a critical subsystem can
    easily become an exercise in "staying alive".
    
    George White <aa056at_private> Halifax, Nova Scotia
    
    ------------------------------
    
    Date: Tue, 28 May 2002 17:03:50 -0400
    From: Marc Rotenberg <rotenbergat_private>
    Subject: FBI's Carnivore hampered anti-terror probe
    
          FBI's CARNIVORE SYSTEM DISRUPTED ANTI-TERROR INVESTIGATION
      INTERNAL MEMO CALLS OVER-COLLECTION OF DATA PART OF "PATTERN" SHOWING
         "INABILITY OF THE FBI TO MANAGE" FOREIGN INTELLIGENCE WIRETAPS
    
    Washington, DC -- An FBI anti-terrorism investigation possibly involving
    Usama bin Laden was hampered by technical flaws in the Bureau's
    controversial Carnivore Internet surveillance system.  The incident, which
    occurred in March 2000, is described in newly-released FBI documents
    obtained under court order by the Electronic Privacy Information Center
    (EPIC).  A written report describes the incident as part of a "pattern"
    indicating "an inability on the part of the FBI to manage" its foreign
    intelligence surveillance activities.
    
    An internal FBI e-mail message dated April 5, 2000, and sent to M. E.
    (Spike) Bowman, Associate General Counsel for National Security Affairs,
    recounts how the Carnivore "software was turned on and did not work
    correctly." The surveillance system captured not only the electronic
    communications of the court-authorized target, "but also picked up E-Mails
    on non-covered" individuals, a violation of federal wiretap law.  According
    to the Bureau document, the "FBI technical person was apparently so upset
    that he destroyed all the E-Mail take, including the take on [the authorized
    target]."
    
    The botched surveillance was performed by the FBI's International Terrorism
    Operations Section (ITOS) and its "UBL Unit," which refers to the
    government's official designation of bin Laden.  The Bureau document
    indicates that an official at the Justice Department's Office of
    Intelligence Policy and Review (whose name has been deleted) became aware of
    the problem, and "To state that she is unhappy with ITOS and the UBL Unit
    would be an understatement of incredible proportions."
    
    The reported problem apparently was not the first to arise during the course
    of FBI implementation of the Foreign Intelligence Surveillance Act (FISA).
    The internal document concludes its report of the "UBL Unit" incident by
    noting, "When you add this story to the FISA mistakes covered in [another,
    unreleased document], you have a pattern of occurrences which indicate to
    OIPR an inability on the part of the FBI to manage its FISAs."
    
    Two Bureau documents written one week later discuss Carnivore's tendency to
    cause "the improper capture of data," and note that "[s]uch unauthorized
    interceptions not only can violate a citizen's privacy but also can
    seriously 'contaminate' onoging investigations" and that such interceptions
    are "unlawful."  An FBI lawyer (whose name has been deleted) writes that the
    Bureau must "go out of our way to avoid tripping over innocent third party
    communications."  The lawyer concludes, "I am not sure how we can proceed to
    test [Carnivore] without inadvertently intercepting the communications of
    others, but we really need to try."
    
    The Bureau lawyer notes that "missteps under FISA lead to mandatory
    reporting to the President's Foreign Intelligence Advisory Board, and such
    errancies must be reported/explained/justified to Congress."  The documents
    do not indicate whether the "UBL Unit" incident was reported to either body.
    
    Since its existence became public in 2000, the Carnivore system has been
    criticized by EPIC and other privacy groups, as well as members of Congress,
    because it gives the FBI unprecedented, direct access to the data networks
    of Internet service providers.  The FBI has publicly downplayed the system's
    potential for over-collection of private communications, although internal
    documents released earlier to EPIC confirmed such a risk.  An independent
    review of Carnivore commissioned by the Justice Department also found that
    the system is capable of "broad sweeps" and recommended technical changes to
    address the problem.  Neither DOJ nor the FBI has indicated publicly whether
    those recommendations were ever implemented.
    
    The newly-released FBI documents were provided to EPIC on 24 May 2002, in
    response to a court order issued by U.S. District Judge James Robertson in
    the privacy group's ongoing Freedom of Information Act lawsuit seeking the
    disclosure of material concerning Carnivore.  The order directed the Bureau
    to conduct a second search for relevant documents after EPIC successfully
    argued (over the Bureau's objections) that an initial FBI search was
    inadequate and likely overlooked responsive records.
    
    The case is being litigated by EPIC's General Counsel, David Sobel, who
    said, "These documents confirm what many of us have believed for two years
    -- Carnivore is a powerful but clumsy tool that endangers the privacy of
    innocent American citizens.  We have now learned that its imprecision can
    also jeopardize important investigations, including those involving
    terrorism."  Sobel added, "As we suggested when it first became public,
    Carnivore's use should be suspended until the questions surrounding it
    finally can be resolved.  Our FOIA lawsuit shows that there's a great deal
    about Carnivore that we still don't know."
    
    The newly-released FBI documents are available at:
    
        http://www.epic.org/privacy/carnivore/
    
    Contacts: DAVID SOBEL 202-483-1140 x105 WAYNE MADSEN x104
    
    ------------------------------
    
    Date: Tue, 28 May 2002 20:45:20 -0700
    From: "gtmarx" <gtmarxat_private>
    Subject: Sex, Truth and Videotaping
    
    At-Home Spying: Privacy Wanes as Technology Gains
    Surveillance may be legal, but is that the only standard?
    Commentary by Gary T. Marx, 28 May 2002, *Los Angeles Times*
      [Reprinted with the permission of the author]
    
    Recently in France, a father who was concerned about the possible
    mistreatment of his 3-year-old son by a baby-sitter's boyfriend hid a
    miniature camera in his home to record any suspicious behavior. The father
    found some, but it was not abuse of the child; the camera revealed the
    baby-sitter and her boyfriend amorously entangled while the child slept
    soundly in the next room.
    
    The father paid a penalty. In France, such videotaping is a violation of
    criminal and civil law. The father was arrested and ordered to pay a fine
    for invasion of privacy.
    
    Did the father do something wrong? Is there a victim here? As the ubiquitous
    advertisements for cameras concealed in teddy bears and other unlikely
    places remind us, parents have an obligation to protect their children. A
    hidden video camera offers an easy way to do this--to the extent that seeing
    is believing. If nothing is found, the responsibly vigilant parents rest
    well knowing that the child was not harmed. If something is found, there is
    tangible evidence for taking protective and even legal action. Different
    privacy standards characterize home and work, as well as areas within
    these. The baby-sitter after all was not filmed in her own home but at her
    place of work.
    
    Yes, the French parents had alternatives. They could have discussed their
    concerns with the sitter, checked to see whether other employers had had
    problems with her, banned the boyfriend or simply found another
    baby-sitter. If there are some grounds for doubt, why take a chance by
    spying? And, as it turns out, the law was on the baby-sitter's side.
    
    In the U.S., the employer largely sets the conditions of work. To use the
    French baby-sitter as an example, the camera was in the living room, not in
    a bathroom where the expectation of privacy would have been greater. The
    place and the video equipment belonged to the parents, and the baby-sitter
    willingly came to the home. The images weren't sold on the Internet, used as
    blackmail or stolen.
    
    To cast the best light on the father, he wanted to have the evidence in hand
    before deciding to fire the sitter. The use of hidden cameras is hardly an
    uncommon or exotic means for this. And, had the father been living in the
    U.S. instead of France, in most jurisdictions he would have broken no law.
    
    Yet this videotaping, even if well-intentioned and revealing nothing
    incriminating, is patently offensive. E.M. Forster captured this well in
    noting: "For it is a serious thing to have been watched. We all radiate
    something curiously intimate when we believe ourselves to be alone."
    Secretly recording people violates their dignity and can put the individual
    at an unfair strategic disadvantage.
    
    We assume, or at least morally expect, that under ordinary circumstances
    behavior behind closed doors, in darkness and at a distance will be
    protected from the eavesdropping of third parties. We also have a right to
    assume that interaction and communication are ephemeral and transitory and
    are not subject to being captured and preserved through hidden video or
    audio means without our knowledge. Another unintended consequence is that
    sometimes people seeking specific information--i.e., whether their child is
    being mistreated--may observe something even they didn't want to know.
    
    In addition, remotely transmitted signals might be picked up by others in
    the vicinity. The behavior of the spy is thus doubly troubling. Not only is
    he invading the privacy of those he is watching, but he may unwittingly
    enable others to invade as well.
    
    The fact that there is still a legal right to secretly record images in the
    U.S. does not mean that it is the right thing to do. We would do well to
    learn from the French the general principle of respect for private life, a
    principle that holds no matter what new technologies are offered to us that
    allow us to spy on others.
    
    Gary T. Marx, a Massachusetts Institute of Technology emeritus
    professor, is the author of "Undercover: Police Surveillance in
    Comparative Perspective" (Kluwer Law, 1995). Web site: garymarx. net.
    
    ------------------------------
    
    Date: Thu, 30 May 2002 08:23:45 EDT
    From: Ken Knowlton <KCKnowltonat_private>
    Subject: Kursk submarine: to test or not to test ...?
    
    Another Hubble Telescope story, of sorts: *Time Magazine* (3 Jun 2002)
    reports that when the Russian submarine Kursk sank, 23 of the momentarily
    surviving crewmen rushed to the floating rescue capsule located in the rear.
    But it failed to disengage.  It had never been tested.  
    
    ------------------------------
    
    Date: Thu, 30 May 2002 09:08:17 -0700 (PDT)
    From: Ulf Lindqvist <ulfat_private>
    Subject: Deja vu: Stockholm power outage hits high-tech companies
    
    In RISKS 21.27, Mar 15 2001, I reported about about a large and
    long-lasting power blackout in Stockholm, Sweden:
    
    > A fire in a tunnel containing power cables caused a long-lasting
    > blackout for 50,000 people and a large number of high-tech
    > companies in several Stockholm suburbs. [...] The largest employer
    > in the area, Ericsson, told 11,000 employees to stay at home
    > Monday as their workplace had no power.
    
    Guess what - something very similar happened again on May 29 2002 in the
    same tunnel, with roughly the same consequences. In a press release, the
    utility company Birka Energi claims that this is actually not exactly the
    same situation as last time. In March 2001, it was an 11 kV cable in the
    tunnel that caught fire, and they claim that the cause of that particular
    problem has been eliminated. This time, however, they received a ground
    fault indication on a 33 kV cable right before the fire. To their customers,
    who will be without power for a couple of days, that information will not
    make much of a difference.
    
    The risk is a familiar one: addressing specific symptoms instead of the
    underlying vulnerability. PGN's comment about tunnel vision is unfortunately
    still appropriate.
    
    Ulf Lindqvist, System Design Lab, SRI International, 333 Ravenswood Ave,
    Menlo Park CA 94025-3493, USA +1 650 859-2351 http://www.sdl.sri.com/
    
    ------------------------------
    
    Date: Wed, 29 May 2002 23:29:30 +0100
    From: John Sullivan <johnat_private>
    Subject: Inadvisable instructions from Sun on StarOffice 5.2
    
    I heard today that Sun are withdrawing the free download of StarOffice 5.2,
    so I went over to their website to investigate. Having downloaded the
    package (in this case a single .bin file which is actually an executable) I
    went to the installation instructions at:
    
    http://wwws.sun.com/software/star/staroffice/5.2/get/download.html
    
    Here we are told:
    
        Note for Linux and Solaris[tm] customers only:
    
        It will be necessary for a chmod command to be executed to set
        read, write, and execute permission.
    
        For example:
    
        % chmod 777 *.bin
    
        Once you have set the permissions, you can run the setup, and
        StarOffice 5.2 will do the rest.
    
    One hopes that anyone seriously likely to be at risk of exploit due to this
    would not be inexperienced enough to actually follow their instructions
    blindly!
    
    However a sufficiently inexperienced user, even though they are most
    probably not running a system shared with an adversary capable of attacking
    them because of this, may well absorb that command as some sort of "magic
    rune" and issue it at other times in the future when the window of
    opportunity is much wider.
    
    ------------------------------
    
    Date: Tue, 4 Jun 2002 00:48:23 -0700
    From: "R. Jagannathan" <jaganat_private>
    Subject: Confirming cricket score reason for delay
    
    http://www.cricket.org/link_to_database/ARCHIVE/CRICKET_NEWS/2002/JUN/012194_NATION_03JUN2002.html
    
    An interesting article from a "dependability" standpoint.  Mismatch between
    what a computer thought was the revised target and what the umpire manually
    computed caused a 20-minute delay during which the teams had to play without
    knowing the revised target.  The game between India and West Indies was won
    by India and the West Indian captain later rued the fact that their team did
    not know the score for 20 minutes, which affected how they played.  All this
    for a one-run difference between the manual and computed calculation.
    
    The Duckworth-Lewis method is an empirically-derived table (by the two
    mathematicians) to compute revised targets when a one-day cricket match gets
    shortened by rain or other similar disruptions.
    
    ------------------------------
    
    Date: Thu, 06 Jun 2002 08:48:37 -0700
    From: "NewsScan" <newsscanat_private>
    Subject: Students provide bulk of tech support in schools
    
    Fifty-four percent of U.S. schools rely on students to provide technical
    support for their computer systems, according to a report titled "Are We
    There Yet?" (http://www.nsbf.org/thereyet/index.htm), released yesterday by
    the National School Boards Foundation. In 43% of the 811 districts surveyed,
    students troubleshoot for hardware, software and other problems, and 39% of
    the districts, students are tasked with setting up equipment and
    wiring. Nearly as many districts also report that students perform technical
    maintenance. The fact that students are providing so much hands-on
    assistance is viewed as a "win-win" situation by John Bailey, director of
    education technology for the Department of Education. Their tech savvy helps
    compensate for a dearth of tech support funding in school budgets and
    teachers who are "unevenly prepared for using technology as a tool for
    teaching and learning," according to the NSBF, which reports that 69% of the
    survey respondents rated new teachers as average or novices in computer
    skills. The role reversal signals a shift in the relationship between
    teachers and students as online lessons become integrated into the school
    curriculum, says Anne Bryant, executive director of the National School
    Boards Association: "Teachers become the guide on the side, instead of the
    sage on the stage."  [AP 5 Jun 2002; NewsScan Daily, 6 June 2002]
      http://apnews.excite.com/article/20020605/D7JV8EP00.html
    
    ------------------------------
    
    Date: Tue, 28 May 2002 11:52:02 +0100
    From: Martin Wheatman <Martin.Wheatmanat_private>
    Subject: More on typos and homographs
    
    I use a national bank in the UK called Lloyds TSB (which is a recent
    amalgamation of Lloyds Bank and the Trustee Savings Bank), and I'm naturally
    keen to use their online services. However, I misspelt the name earlier this
    year (www.llyodstsb.com), and was taken to the real www.lloydstsb.com.  I
    didn't immediately spot the typing error until I noticed that the Webmaster,
    rather incompetently perhaps (if it were a real scam), was using a free Web
    host service (www.uk2.net), which displays the redirected Web site
    underneath their banner advertising free Web hosting (I use the same company
    as they do provide a good, cheap, "no frills" service). Writing a program to
    redirect traffic to the end service is trivial (no need to even provide Web
    content!), as would filtering usernames and passwords.
    
    It's slightly different to the homograph scam as it relies on the typist to
    make errors (ad htat nerver hapens!), rather than providing the links
    already embedded in Web content, and feeds off
    www.websiteswithreallylongnames.com , and probably the fact that there will
    (I suspect) be a lot more combinations of typos than homographs. Also, the
    simple (but probably unheeded) solution to display mixed character sets
    wouldn't work... :( One protection, in the UK at least, is to access
    commercial sites thought the ".co.uk" domain which is managed by Companies
    House (effectively the Government), who will only allow registered companies
    to use their registered names. Ok, so you could register a company wth the
    misspelt name, but I suspect that Companies House (and the company being
    scammed) will no doubt be interested in the reasons for the similar name
    (probably using the same mechanism as protection for trademark laws /
    passing off?).
    
    P.S. As a responsible citizen, I notified my bank (it was rather scary!),
    and although the site is still registered it is no longer used to redirect
    traffic (whether these two events are linked, I still don't know -
    presumably the Bank is still bothered by adverse publicity).
    
    ------------------------------
    
    Date: Thu, 06 Jun 2002 13:26:46 -0400
    From: Mario Hendricks <mario.hendricksat_private>
    Subject: Please ignore the anti-shoplifting device!
    
    The other day I went into my local Apple store to buy an external floppy
    drive.  On my way out of the mall to my vehicle, I decided to take the
    shortest route, through a nearby Eddie Bauer store.  As a I walked into the
    store, the anti-shoplifting device sounded an alarm.  As there were no other
    people within 5 or 10 meters, I realized that my recent purchase (from
    Apple) must have set off the alarm.  I also realized that the alarm would
    likely sound as I exited at the other end of the store. 
    
    When I got near the parking lot exit, I encountered an Eddie Bauer employee.
    Rather than to get accosted as attempting to shoplift by this employee, I
    decided to warn him that the anti-shoplifting device would probably sound as
    I exited.  The employee saw that I was carrying an Apple Computer bag (they
    have very distinctive shopping bags) and responded along the lines of "Oh,
    yeah, stuff from Apple always set off the alarm."  Sure enough, when I left
    the store the alarm sounded.
    
    The risks of such a false positive alarm are obvious.  The fact that
    employees know to ignore the alarm (in at least this one case) raises even
    more risks.  Of course, if anyone should ever want to shoplift from this
    store, there seems to be a tested procedure.  You would think that either
    the store's management or the anti-theft device manufacturer would be
    concerned about such issues.
    
    ------------------------------
    
    Date: Tue, 4 Jun 2002 10:43:54 +0200
    From: "Paul van Keep" <paulat_private>
    Subject: Re: The Klez Effect
    
    Yesterday I received a bounce from risksat_private because I 'allegedly'
    sent a Klez.H infected e-mail to Peter. Of course I didn't (I thoroughly
    removed Outlook from my system and only use Polarbar, a Java mailer). But
    the interesting side effect is that the virus firewall nicely bounces the
    message to me, first stripping the infection payload. But what doesn't get
    stripped is the document that Klez attaches to each mail it sends out. So
    with each bounce I get a nice bonus.  The Klez e-mails with me as originator
    come from somebody who seems to be a designer. I now have a collection of
    three different jpgs with nice pictures of jewelry and home appliances.
    (S)he must also be a RISKS reader, the only link between me and the RISKS
    e-mail. The risk is that virus firewalls, by not stripping all attachments
    from infected e-mails, not only block viruses from spreading, which is good,
    but also help in distributing potentially sensitive documents to third
    parties.
    
    P.S. I'm still waiting to get a nice Word document with good takeover
    information so I can do some serious insider trading
    
      [Classic case of address spoofing.  There are also lots of 
      spoofs allegedly from RISKS.  Don't Believe a Word!  PGN]
    
    ------------------------------
    
    Date: Tue, 4 Jun 2002 16:36:39 -0400
    From: "Greg Searle" <greg_searleat_private>
    Subject: Re: The Klez Effect
    
    Listmasters are really getting hit, but you don't need me to tell you that.
    Just today, another list that I subscribe to urged its members to rid
    themselves of the virus.
    
    There's good news, however.  According to MessageLabs
    (http://www.messagelabs.com/viruseye/), Klez is finally starting to slowly
    recede.  It peaked two weeks ago at about forty thousand viruses intercepted
    by the company per day.  Now it's around 27K/day.
    
    So far, I've only had a couple of firewalls send me warnings that I "sent"
    the virus.  No live person ignorant of Klez's forged header has complained
    yet.
    
    ------------------------------
    
    Date: Tue, 28 May 2002 09:26:18 EDT
    From: "A. Harry Williams" <HARRYat_private>
    Subject: Re: Klez and mail loops (Pool, RISKS-22.10)
    
    In discussing the Klez virus/worm, Martin Pool makes a common mistake among
    UNIX admins, assuming that what is available on their system in TCP/IP
    utilities accurately and completely implements RFC specs.  X- headers are
    user-defined headers, and therefore cannot be an RFC network standard
    header.  I just searched, and can only find Precedence: in RFC 2076, where
    it is defined as "non-standard, controversial and discouraged".  The real
    problem is that these auto-responders, including many Out of Office
    programs, try to use the email Headers, rather than the envelope headers.  A
    simple MAIL FROM:<> that was correctly honored would stop many loops, and
    that is its purpose.
    
    ------------------------------
    
    Date: Mon, 27 May 2002 19:27:19 -0700
    From: hal lewis <hlewisat_private>
    Subject: More on Klez (Garfinkel, RISKS-22.10)
    
     >It makes you wonder if there should be any liability for these individuals.
    
    Who needs to wonder? This is theft, pure and simple.
    
    ------------------------------
    
    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.11
    ************************
    



    This archive was generated by hypermail 2b30 : Thu Jun 06 2002 - 17:59:15 PDT