[risks] Risks Digest 21.54

From: RISKS List Owner (riskoat_private)
Date: Mon Jul 23 2001 - 14:52:05 PDT

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

    RISKS-LIST: Risks-Forum Digest  Monday 23 July 2001  Volume 21 : Issue 54
       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/21.54.html>
    and by anonymous ftp at ftp.sri.com, cd risks .
    Tunnel fire derails Internet service (NewsScan)
    Calendar software and departed employee (Lawrence Kestenbaum)
    U.S. Tax refund inspires Home Depot snail-mail spam (Dawn Cohen)
    Renewal of digital certificate impeded by secure passphrase (Philip Bragg)
    Security system update leads to insecurity (Bob Van Cleef)
    Did download failures increase Code Red's success? (Scott Renfro)
    "This e-mail doesn't contain any viruses" (Aaro J Koskinen)
    The risks of moving and identity theft (Harry Erwin)
    Concerns for identity theft are often unheeded (Monty Solomon)
    What a gas! (William Paul Fiefer)
    "Know Your Customer" USPS style (Alex Wexelblat)
    US Airways credit-card snafu (Jed Graef)
    Bad domain name? (Gene Wirchenko)
    Banking and Internet broadcast technologies (Daniel Chalef)
    Re: Polarized sunglasses and LCD frustration (Stephen A. Boyd)
    Re: Even a fatal error can't kill it (Phil Anderson)
    Re: SSL encryption that isn't (Jacob Ofir)
    MSN security upgrade forces new e-mail address (Ami A. Silberman)
    ISW-2001 - Call for Participation (Howard Lipson)
    Abridged info on RISKS (comp.risks)
    Date: Fri, 20 Jul 2001 08:52:50 -0700
    From: "NewsScan" <newsscanat_private>
    Subject: Tunnel fire derails Internet service
    Derailed train cars burning in a Baltimore tunnel have seriously damaged the
    area's fiber-optic cables, slowing Internet service and other communications
    traffic in the Mid-Atlantic states, with a ripple effect across the
    country. WorldCom, PSINet and AboveNet all reported problems with service,
    but said they had not yet been able to quantify the severity of the
    problems. Keynote Systems, which measures Web site performance, said the
    delay experienced by Internet users was the worst it has ever seen.  "What
    we're seeing is a problem in the handshake between the backbones which serve
    as the Internet's infrastructure," said a Keynote spokeswoman.  "These
    backbone providers hand off traffic to travel between them across the
    country." Keynote reported major slowdowns as far away as Seattle and Los
    Angeles that may be attributable to the train wreck [or Code Red? The fumes
    also resulted in cancellation of Orioles games.  PGN]. [AP Jul 19 2001
    NewsScan Daily, 20 July 2001]
    Date: Mon, 23 Jul 2001 14:31:52 -0400 (EDT)
    From: Lawrence Kestenbaum <polygonat_private>
    Subject: Calendar software and departed employee
    Calendaring software plays a critical role in any sizeable organization.
    Local governments, in particular, hold innumerable meetings -- formal
    meetings of the local legislative body, of course, but also committee
    meetings, citizen board meetings, project meetings, and on and on.  And
    many of those meetings involve members of the public, or officials
    external to the organization.
    The county government here in Washtenaw County, Michigan (county seat: Ann
    Arbor), has about 1,300 employees.  Most or all county departments use
    Netscape Calendar version 4.6 to schedule and keep track of meetings.
    One particular county department, the Drain Commissioner's office
    (responsible for construction and maintenance of storm sewers and ditches
    all over the county) holds many meetings with local officials and property
    owners to discuss proposed or pending drain projects.  A specific employee
    was responsible for putting these meetings on the calendar.
    A few weeks ago, this employee left the County's employment, and her
    account was deleted from the system.  Here's the problem: all of the many
    meetings she had scheduled ALSO disappeared.
    As a direct result, the Drain Commissioner and other county officials, who
    relied on the automated calendar, were not in attendance at meetings where
    they were expected, resulting in inconvenience for the public and
    embarrassment for the officials and the County.  Only then was this
    problem discovered.  The number of future meetings that had also been lost
    was unknown.
    I asked if the deleted meetings could be retrieved from backups.  Nope,
    individual calendars cannot be restored, only the entire system, which
    obviously would disrupt over a thousand individual calendars.
    The RISK: calendaring software that doesn't recognize (1) the likelihood
    of turnover among employees, including meeting schedulers, (2) that there
    are more stakeholders in a meeting than just the one person who adds it to
    the official calendar, and (3) that access to information in backups may
    be needed on a less than all-or-nothing basis.
    Lawrence Kestenbaum, polygonat_private, Washtenaw County Commissioner, 
    4th District,  Mailing address: P.O. Box 2563, Ann Arbor MI 48106
    The Political Graveyard, http://politicalgraveyard.com
    Date: Mon, 23 Jul 2001 10:08:36 -0400
    From: "Dawn Cohen" <COHENDat_private>
    Subject: U.S. Tax refund inspires Home Depot snail-mail spam
    Bloomberg radio reports that Home Depot will do a targeted mailing
    synchronized with tax refunds.  Apparently the tax refunds are being sent
    out in an order related to the Social Security Number (I think it may be
    just the last 2 digits).  Home Depot has SSN information for a number of
    their customers (I believe those with Home Depot cards).  So they will send
    out advertising flyers to their customers in the SSN order, timed to be
    viewed just when the customer needs help deciding what do with the refund
    Date: Fri, 20 Jul 2001 16:42:09 +0100
    From: philip.braggat_private
    Subject: Renewal of digital certificate impeded by secure passphrase
    I work for a company which had purchased a digital certificate from BT
    Trustwise (now part of Ignite) 12 months ago, I now find that I am unable to
    renew it online.
    The problem is the "log in" passphrase contains some non- alphanumeric
    characters, this is a practice which would surely meet with industry-wide
    approval as it makes brute force attacks more difficult. At the time of
    purchase the BT Trustwise system accepted the passphrase and duly created
    and delivered a working certificate.
    Today the Web page where new passphrases are entered has a warning telling
    customers to use alphanumeric characters only, whether it stops users
    entering anything else is unknown at this time. I am told by the person who
    originally created the certificate that no such warning was displayed at the
    time of purchase.
    The software which processes the online renewals malfunctions if it sees
    anything but alphanumeric characters in an existing user's passphrase. It is
    possible to determine that the passphrase is being recognised as valid
    because after entering it correctly I get delivered to a mostly blank and
    useless page, entering something which isn't my passphrase takes me to a
    page telling me my passphrase is incorrect.
    If the system knows I am using the correct passphrase why won't it let me
    renew my certificate?
    It seems to me that Trustwise is covering up a minor programming error with
    a simple message saying "don't do this or it will break" rather than fixing
    the problem, something I find quite surprising given the business they're
    The risk of having no valid certificate became a different risk, that of
    having an insecure certificate, when the support person at the company
    concerned offered to enter the passphrase directly into their system if I
    read it over the phone to them.
    Then there is the risk of overlooking directions to use only insecure 
    Philip Bragg
    Date: Mon, 23 Jul 2001 10:41:20 -0700 (PDT)
    From: Bob Van Cleef <vancleefat_private>
    Subject: Security system update leads to insecurity
    The security service the monitors the building where I work recently
    upgraded its alarm monitoring software.  The people from their corporate
    office arrived, installed the upgrade, and left...
    Unfortunately, while they were here, they appear to have also deleted the
    configuration database and all backups... as the local people ended up
    manually re-entering all the system settings, for all their clients, by
    A month later our computer room air-conditioning went out and the
    over-temperature alarm did not go off.  They forgot to tell the computer to
    monitor that line.  Fortunately one of our staff walked into the room before
    damage was done. (Our manual backup sensor.)
    They tell me that everything is now working correctly.  Why am I still
    Bob Van Cleef, San Jose, CA   www.garg.com
    Date: Sun, 22 Jul 2001 18:43:09 -0700
    From: Scott Renfro <scottat_private>
    Subject: Did download failures increase Code Red's success?
      [For those of you who slept through it, the Code Red worm was intended to
      attack the whitehouse.gov Web site at 5pm EDT on 19 Jul 2001.  With
      just-in-time reverse engineering, the code was discovered to contain the
      target IP address, thus enabling the White House staff to reconfigure to
      avoid the attack.  (The attack clearly could have been more subtle.)  It
      is of course ironic that current efforts to outlaw reverse engineering
      (DMCA, UCITA, etc.) could ban efforts to stave off this and other attacks!
      The relevant CERT advisory is at
      http://www.cert.org/advisories/CA-2001-19.html pointing out that Code Red
      exploited a vulnerability noted earlier in CA-2001-13.  YABO: Yet Another
      Buffer Overflow, aimed at Microsoft IIS servers.  PGN]
    On the morning of 19 Jul 2001, I notified a small company (whom I sometimes
    advise since they have no dedicated IT staff) of the then-latest Microsoft
    advisory.  An hour later, they proudly replied, reporting success and noting
    that this hot fix was much easier to apply than most -- especially since
    this one didn't force a reboot.
    Suspicious that they hadn't really applied the hot fix, I downloaded a
    separate copy of the hot fix using Internet Explorer and sent it to them
    via e-mail.  This time they replied that the attachment I sent resulted
    in an error message: ''not a valid Windows NT application.''
    I soon realized that the connections were terminating prior to
    completion and Internet Explorer was not reporting the failures.  In the
    user's mind, silence was equivalent to success.
    We were able to successfully download the hot fix using wget on FreeBSD,
    which restarted the transfer four times due to reset connections -- each
    time picking up where it had previously left off.  The company's server
    was soon patched, and they have had no problems with the Code Red worm.
    I've confirmed that Internet Explorer 5.0 on Win2k reports no failures
    in (at least) the following situations:
     - When the user has selected 'Run this program from its current
       location' and the connection is prematurely reset, the download
       dialog silently disappears.  This is the same visual behavior as a
       program that was successfully transfered and completed execution
       without pausing for user input.
     - When the user has selected 'Save this program to disk' and the
       connection is closed normally but prematurely (i.e., before the
       number of bytes specified in the Content-Length header were
       received), the total file size is silently changed.  For example,
       during the download, the dialog displays:
         Estimated time left: 2 sec (87.2 KB of 236 KB copied)
       but once the connection has closed, the dialog changes to:
         Downloaded: 180 KB in 1 sec
    An error does result in the inverse of these situations (i.e., when running
    a program where the connection is closed normally but prematurely or when
    saving a program where the connection is reset).
    One wonders how many naive admins thought they *had* installed the hot fix,
    but ended up with a truncated download and a Code Red worm infestation
    P.S.  As of 22 Jul 2001, transfers from mssjus.www.conxion.com (to which
    download.microsoft.com at least sometimes redirects) still result in
    frequent resets from some networks.
    Date: Mon, 23 Jul 2001 16:59:02 +0300 (EET DST)
    From: Aaro J Koskinen <akoskineat_private>
    Subject: "This e-mail doesn't contain any viruses"
    I recently received e-mail from a stranger with the following note at the
    > This message has been scanned for viruses with F-Secure Anti-Virus for
    > Microsoft Exchange and it has been found clean.
    RISKS: Someone could actually take such a note for real and blindly trust it!
    There is no way to tell whether any scanning has been actually done. I might
    as well add a similar note to my .signature! Secondly, who would trust virus
    scanning done by the *sender* anyway?
    Aaro Koskinen, aaroat_private, http://www.iki.fi/aaro
    Date: Mon, 23 Jul 2001 18:08:04 +0100
    From: Harry Erwin <harry.erwinat_private>
    Subject: The risks of moving and identity theft
    In January 2001, I moved to the UK to take up a position as a Senior
    Lecturer of Computing at the University of Sunderland in the UK.  Today, I
    got the first bill for a credit card taken out fraudulently in my name back
    in the US.  I was fairly careful about these things -- I suspect this is the
    tip of the iceberg.
    The first step, of course, was to file fraud alerts with the three major
    credit bureaus.  Trans Union was very helpful, and even indicated that the
    incident I already knew about was the only one on my recent record.
    Experian was not as helpful -- I had to provide an obsolete ZIP code to
    reach the point of actually filing the data they needed, but then they
    recorded my voice as I provided the rest.  Equifax was hopeless.  They
    couldn't handle (UK) rotary phones, and they required a US phone number for
    contact purposes.  They also had problems reading my SSN, and they finally
    ejected me from the system, requesting a letter with about five pages of
    miscellaneous details, some of which (a pay stub with my SSN) are simply not
    available in the UK.  I filed a complaint on that with the FTC.  Next step
    is a letter to the credit-card issuer to follow up on my voice report.  I
    suspect my notary will be busy.
    Harry Erwin, University of Sunderland. Computational neuroscientist
    modeling bat bioacoustics and behavior. <http://world.std.com/~herwin>
    Date: Mon, 23 Jul 2001 14:58:15 -0400
    From: Monty Solomon <montyat_private>
    Subject: Concerns for identity theft are often unheeded
    Major financial institutions routinely give out confidential customer
    account information to callers, using security procedures that authorities
    say are vulnerable to abuse by fraud artists.  Regulators and law
    enforcement officials warned three years ago that identity thieves and
    information brokers were tricking clerks into giving them access to
    individuals' financial information.  [Source: Robert O'Harrow Jr.,
    Washington Post Staff Writer, 23 Jul 2001; Page A01,
    Date: Mon, 23 Jul 2001 14:10:45 -0500
    From: Paul <yamadaat_private>
    Subject: What a gas!
    I am a longtime customer in good standing with Nicor, a large natural gas
    utility serving portions of northern Illinois (United States). I recently
    had my gas shutoff, the meter locked, and the meter scheduled for removal
    from outside my house. Luckily I was home when the Nicor technician arrived
    to haul away the meter and I asked her to check the order.
    Armed with a telephone and e-mail client, I discovered anyone can cut anyone
    else's Nicor service off by supplying either an address or telephone number.
    One representative told me requests for shutoff are honored immediately.
    To a degree, this is understandable. Fire departments must, for example,
    kill the gas to a burning building. But the ease with which a cutoff under
    far less threatening circumstances can occur is remarkable.
    To their credit, Nicor is investigating the processes in place that allow
    this. Their default for each account, for example, is *not* to
    password-protect it (that is, mother's maiden name or some such checkpoint).
    Is this a software RISK? I think so. Shutoff requests are keyed into a
    system with under veil of the skimpiest verification.  Systems with "screen
    pop," which display the telephone number of the caller, also act as a
    checkpoint. This system appears divorced from a screen pop function. In this
    case, the final checkpoint is an onsite technician who can only debug the
    problem if the homeowner happens to be in. That's the type of debugging I
    expect from, say Microsoft, not my utility company.
    William Paul Fiefer (and please don't cut my gas off)
    Date: Sun, 22 Jul 2001 11:00:43 -0400
    From: Graystreak <wexat_private>
    Subject: "Know Your Customer" USPS style
    Insight Magazine reports [1] that since 1997, the US Postal Service has been
    reporting innocent activity it deems "suspicious" to federal law enforcement
    officials.  Evidence includes a training video with this chilling
    	 "It's better to report 10 legal transactions than
    	  to let one illegal transaction get by."
    The risks of a system that presumes guilt until innocence is proven are too
    numerous to list here.  Not least of them is the impossibility of proving a
    negative (I did not intend this cash to be used for illegal purposes).  A
    similar reporting system in the banking arena is known to generate ratio of
    99,999 false positives for every true positive. Yes, I do mean a ratio of
    10^5:1 errors to correct results.  I can't imagine any other system in which
    that error rate would be acceptable.
    The information on suspicious activities is, of course, kept in a database
    controlled in secret and used for purposes no one is willing to discuss.
    The Post Office will not discuss the parameters used to flag "suspicious"
    activity, though the video states that unwillingness to give out personal
    information such as date of birth and/or produce identification papers is
    automatically suspicious.
    Someone help me verify that I'm still living in America, please? [*]
    [1] http://www.moreprivacy.com/editorials/postaleye.htm
    Alan Wexelblat <wexat_private> http://wex.www.media.mit.edu/people/wex/
    CHI'02 Panels Chair, moderator, rec.arts.sf.reviews
      [* Alex, Yes, you are.  But privacy is continually being eroded, 
      despite the best efforts of the Risks Forum, the Privacy Forum at
      http://www.vortex.com/privacy, EPIC at http://www.epic.org, EFF at
      http://www.eff.org, Zero Knowledge at http://www.zeroknowledge.com,
      to name just a few.  PGN]
    Date: Fri, 20 Jul 2001 16:40:32 -0400
    From: "Jed Graef" <jgraefat_private>
    Subject: US Airways credit-card snafu
    Recently my wife needed to redeem US Airways miles for a ticket on short
    notice.  The fee for the last minute booking was $75, which I paid with a
    credit card at the airport.
    When the credit-card bill came, there were two charges for the $75.  The US
    Air representative I spoke to cheerfully reversed one of the charges and
    explained that, due to a known "programming error," after the card was
    swiped, the record of the transaction was not cleared upon completion.  When
    the next customer's card was swiped, the last transaction in the system
    (mine) was processed again, resulting in the double billing.
    He explained all of this to me so that I would not be concerned about seeing
    someone else's name as the passenger on the confirmation letter that would
    be sent.  Sure enough, the letter arrived with the name of the person whose
    card was swiped after mine.
    One has to wonder how long this error has been known.
    Jed Graef <jgraefat_private>
    Date: Fri, 20 Jul 2001 19:06:34 -0700
    From: Gene Wirchenko <genewat_private>
    Subject: Bad domain name?
    I live in Salmon Arm, British Columbia, Canada.  Suppose you wanted to
    create a Web site for promoting the downtown Salmon Arm area.
    These names are a bit long:
    The most common (and presumably obvious) abbreviation of the community
    name is "SA".  You could abbreviate -- as someone did:
    Unfortunately, this can easily be lexed to:
      sad own town
    The risk?  When mapping a name to another set of rules, watch that you
    aren't now saying something other than what you mean to say.
    Gene Wirchenko
      [This is of course a very old problem -- as in "together" vs "to get her".
      With the high price of fuel, the town may be dealing with "sa gas".  Perhaps
      "sa les girls"?  I presume the town song is "Salmon Chanted Evening".  PGN]
    Date: Sat, 21 Jul 2001 09:00:01 +0200
    From: Daniel Chalef <danielat_private>
    Subject: Banking and Internet broadcast technologies
    A local Internet-based bank (a joint venture of South Africa's largest ISP
    and a local banking group) ran into a spot of trouble with a mass e-mailing
    list of a sister company, MoneyMax.  MoneyMax provides online securities
    trading and securities-related information to the bank's customers.  It
    appears the wires got crossed, and confidential information in response to
    one person's credit-card application made it onto MoneyMax's daily financial
    newsletter.  Thankfully, somebody noticed after mailing to about 2% of the
    list, and pulled the plug on the mailserver.  [The e-mail apology entitled
    "Please delete previous Moneymax Newsletter" blamed an "unforeseen software
    error", and included the customary "Measures have been taken to ensure that
    it will not happen again."  PGN-ed]
    Date: Mon, 23 Jul 2001 13:35:46 EDT
    From: Stephen A. Boyd <UncleHonusat_private>
    Subject: Re: Polarized sunglasses and LCD frustration (Baker, RISKS-21.53)
    In response to Henry Baker's aggravation, it would take a broad, concerted
    effort on the part of several industries to coordinate LCD screen angle with
    the linear polarization manufacture methods for lenses.  It's my
    understanding that they come in sheets and their orientation is not a
    manufacturing concern when the sunglasses are manufactured.  This answers
    hbaker's wondering as to why he cocks his head at only a 15-degree angle for
    his wife's screen but 40 for his and 45 for his laptop.  He will see this
    (up to a full 90 degrees) for many to most of the LCDs that are so quickly
    emerging as standard equipment for displays, ATMs etc.
    This may be particularly RISKS relevant, since the "accutint" lenses or
    those that react with sunlight (UV rad.) may also react adversely, depending
    on the linear angle and whether it's merely arbitrary during manufacture.
    Imagine the risk, driving into a sunlit area (like after a tunnel or
    cloudcover or something).  Ugh!
    Stephen A. Boyd, Chief Information Officer, Premier Heart, LLC
      [Re: Brewster's angle of incidence: perhaps the 
      Brewster Rooster cocks its head cluckwise.  PGN]
    Date: Fri, 20 Jul 2001 12:14:45 +0100
    From: phil.andersonat_private
    Subject: Re: Even a fatal error can't kill it (Haynes, RISKS-21.53)
    > ... the software is supposed to catch cases of the same person making two
    > reservations on the same flight but in this case that didn't work either.
    That in itself sounds risky - I was on a trip once where the group included
    two sisters, same surname, same initial; the hotel manager had assumed that
    one of the entries on the list was an erroneous duplicate and only allocated
    one room.
    Philip Anderson, Alenia Marconi Systems Cwmbrn, Cymru/Wales
    Date: Thu, 19 Jul 2001 19:30:18 -0400
    From: "Jacob Ofir" <jofirat_private>
    Subject: Re: SSL encryption that isn't (Ron, RISKS-21.53)
    What the EAA Web page does is quite common. The web-browser submits the
    information using SSL to the server, and the server e-mails that information
    in cleartext to some destination.  I imagine that most small "registration"
    pages do similar things, with the main difference being that they hard-code
    the destination address in the server, rather than submitting it with the
    One risk is that users have been taught that a padlock on their browser
    means that _everything_ is secure. 
    A greater risk is that some (most?) developers believe the aforementioned
    statement and do not worry about the treatment of user data once it arrives
    at the server.
    Date: Mon, 23 Jul 2001 09:58:44 -0400
    From: "Ami A. Silberman" <silberat_private>
    Subject: MSN security upgrade forces new e-mail address
    My home account is with MSN. A couple of years ago, my address was
    blahblahat_private  After an upgrade, it became blahblahat_private
    However, I could still use the old address as a return address, and people
    could still send mail to me at both addresses.  Since then, I've joined a
    couple of mailing lists, with my e-mail address as blahblahat_private
    Recently, MSN required all its users to upgrade to some new security
    configuration which is supposed to remove spam. (It hasn't, and for the
    first time I'm getting spam purporting to be from actual old e-mail address.)
    In the process, my e-mail address changed again back to blahblahat_private
    The problem is that now I can no longer post to my mailing lists, which have
    me as blahblahat_private  Not only that, but although I can resubscribe
    with my new address, I cannot unsubscribe using my old address, since the
    MSN servers refuse to acknowledge it. (This is probably their
    spam-blocking.) I'm having to pester the administrators of several lists to
    unsubscribe me manually. Since this is probably happening to everyone who
    has an msn account, the problem is non-trivial.
    The risk? MSN's attempt to improve security (apparently by forcing spammers
    to modify their software to change fake msn addresses) has resulted in
    additional burden on list administrators.
    Ami Silberman (ami_silbermanat_private)
    Date: Fri, 20 Jul 2001 18:11:30 -0400 (EDT)
    From: Howard Lipson <hflat_private>
    Subject: ISW-2001 - Call for Participation
               Fourth Information Survivability Workshop (ISW-2001)
                  "Impediments to Achieving Survivable Systems"
                            The Delta Pinnacle Hotel
                              Vancouver, BC Canada
                              October 15-17, 2001
        Sponsored by the IEEE Computer Society and the US State Department
                  With support from the Government of Canada
    Organized by the CERT* Coordination Center, Software Engineering Institute
                      General Chair: John McHugh, CERT*/CC
               Program Chair: Corey Schou, Idaho State University
    Participation in the workshop is by invitation only. There are two ways to
    obtain an invitation:
       * Submit a position paper related to the theme of the workshop, by 
         31 August 2001.
       * Submit a request for an invitation, accompanied by a qualification 
         statement, by 15 September 2001.
    Please see the ISW Web site for the complete call for participation,
    including detailed instructions on submitting a position paper or a
    qualification statement.  Check the Web site periodically for updates about
    the workshop:
       Please send any questions or comments about ISW-2001 to:
    * "CERT" and "CERT Coordination Center" are registered in the U.S. Patent
       and Trademark Office.  Copyright 2001 Carnegie Mellon University.
    Date: 12 Feb 2001 (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
     which requires your confirmation to majordomoat_private .
     [If E-mail address differs from FROM:  SUBSCRIBE "other-address <x@y>",
     requiring PGN's intervention -- to block spamming subscriptions, etc.]
       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 20" for volume 20]
     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 21.54

    This archive was generated by hypermail 2b30 : Mon Jul 23 2001 - 15:41:37 PDT