[4749] in RISKS Forum
Risks Digest 24.35
daemon@ATHENA.MIT.EDU (RISKS List Owner)
Thu Jul 20 15:49:27 2006
From: RISKS List Owner <risko@csl.sri.com>
Date: Thu, 20 Jul 2006 12:49:07 PDT
To: risks@mit.edu
RISKS-LIST: Risks-Forum Digest Thursday 20 July 2006 Volume 24 : Issue 35
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/24.35.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
Air traffic control snafu around LAX (PGN)
20 inspectors suspended over refusing GPS cellphones (Monty Solomon)
PlusNet obliterates customers' e-mail (Mary Ellen Foster)
IEEE e-mail alias service with Comcast (Pete Klammer)
MSN Messenger blocking URLs on server side (Cody B)
Dirty Data contaminates Business Decisionmaking (Al Macintyre)
Corporate Risks (Al Macintyre)
Banks not yet aware enough of phone-phishing (John Pettitt)
The Risks of retro computing? (Edward G. Nilges)
Risks of relying on the Web in wartime (Tim Chmielewski)
Re: Yet another example of accidental disclosure of redacted info
(Amos Shapir)
Re: Subject: Deceiving a computer is now a crime (David H Smith)
REVIEW: "Insider Threat", Eric Cole/Sandra Ring (Rob Slade)
REVIEW: "Practical VoIP Security", Thomas Porter et al. (Rob Slade)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Thu, 20 Jul 2006 09:35:11 -0700 (PDT)
From: "Peter G. Neumann" <neumann@csl.sri.com>
Subject: Air traffic control snafu around LAX
A power blackout shut down the Los Angeles Air Route Traffic Control Center
in Palmdale CA for three hours on the evening of 18 July 2006, following a
power outage and the failure of the backup power system. The original power
outage was caused by a pickup truck hitting a utility pole. This
automatically caused a cutover to the backup power system, but the switching
system failed an hour later. The Palmdale ATC was without phones (!),
computers, and radar for two hours, and another hour was required to get
things running again. As a result, 348 flights around the U.S. were
canceled, delayed, or diverted, 221 of them at LAX. One flight from Canada
to LAX was diverted to San Jose. The problem even delayed a test launch of
a Minuteman III missile from Vandenberg Air Force Base, which would have
required controlled access to the airspace. [Source: Daisy Nguyen,
Associated Press, seen in the *Palo Alto Daily News*, 20 July 2006; PGN-ed]
------------------------------
Date: Sun, 16 Jul 2006 23:29:34 -0400
From: Monty Solomon <monty@roscom.com>
Subject: 20 inspectors suspended over refusing GPS cellphones
The Massachusetts public safety commissioner yesterday suspended 20 state
building and engineering inspectors for refusing to accept cellphones
equipped with global positioning systems. Only two inspectors accepted the
phones; another two were out on vacation when Commissioner Thomas Gatzunis
tried to distribute the phones, which supervisors want to use to keep track
of the inspectors during the work day. ... [Source: Andrea Estes, 20
inspectors suspended over GPS: Public safety chief metes out discipline,
*The Boston Globe*, 11 Jul 2006]
http://www.boston.com/news/local/articles/2006/07/11/20_inspectors_suspended_over_gps/
------------------------------
Date: Thu, 20 Jul 2006 10:43:35 +0100
From: "Mary Ellen Foster" <foster@in.tum.de>
Subject: PlusNet obliterates customers' e-mail
[Source: Chris Williams, PlusNet obliterates customer e-mails; Punters
cut-off by bungling storage update, *The Register*, 11 Jul 2006; PGN-ed]
http://www.theregister.co.uk/2006/07/11/plusnet_email_fiasco/
In the process of upgrading its storage management, PlusNet deleted more
than 700GB of its customers' e-mail and disabled the ability of about half
its 140,000 users to send and receive new e-mail. "At the time of making
this change the engineer had two management console sessions open one to the
backup storage system and one to live storage. These both have the same
interface, and until [then] it was impossible to open more than one
connection to any part of the storage system at once." Patches were
installed, but the engineer assumed he was working with the backup rather
than the live server. Thus, "the command to reconfigure the disk pack and
remove all data therein was made to the wrong server."
------------------------------
Date: Thu, 13 Jul 2006 17:07:29 -0600
From: "Pete Klammer" <NETRONICS-PE@comcast.net>
Subject: IEEE e-mail alias service with Comcast
As necessary as it is, blacklisting purportedly for SPAM control has
terrible potential for abuse and mischief, especially when Internet service
providers outsource the function to third parties, such as BrightMail, and
entrust them with screening decisions. In my own recent experience, known
good legitimate e-mail messages from a critical vendor (OrCAD software) were
deleted without a trace, without recourse, without explanation, and neither
I nor my ISP nor my address forwarder could to a damn thing about it -- we
couldn't even get logs evidence of the deletion, nor rules documenting
whether or not the deletion should take place (but we could prove it by
sending the same messages to a different address). Worse, I have seen
skewing of issue-oriented (political, etc.) e-mail being filtered or not --
should this be in the hands of unaccountable third parties?
Dear IEEE Alias User,
... The IEEE became aware that "comcast.net" was blacklisting IEEE's
e-mail servers. As a result "ieee.org" e-mail forwarded to "comcast.net"
e-mail accounts was being rejected. ...
Peter F. Klammer, P.E., NETRONICS Professional Engineering, Inc.
3200 Routt Street, Wheat Ridge, Colorado 80033-5452 (303)274-6182
[If anyone sent e-mail to me at pklammer@ieee.org, it should be good again.]
------------------------------
Date: Tue, 4 Jul 2006 12:53:06 -0400
From: "Cody B." <cody@zone38.net>
Subject: MSN Messenger blocking URLs on server side
Blogger Arve Bersvendsen, back in February of this year, posted a summary of
a Swedish magazine article mentioning that the MSN Messenger service (or
Live Messenger, as it's known now) has been automatically blocking the
transmission of certain messages based on very primitive keyword matching
<http://virtuelvis.com/archives/ 2006/02/microsoft-censoring-msn-messenger>.
The post went largely unnoticed for much of the year, but recently it
surfaced on Digg.com, where it suddenly garnered a lot more attention.
<http://digg.com/software/Microsoft_censors_MSN_Messenger>
The concept underlying MSN's block was perfectly reasonable-- they were
simply trying to prevent the spread of certain worms via malicious web
links.
The execution, on the other hand, was severely lacking. There's absolutely
no notification to the receiver that anything was blocked, and only an
extremely delayed notification to the sender.
The worst part of the execution, however, is the actual choice of strings
that MSN deemed worthy of blocking. Though no master list has been made
public, various users have discovered that "download.php", "gallery.php",
"profile.php?", and even ".pif" and ".scr" contained anywhere in a message
will prevent that entire message from going through. Apologists will
rightly claim that every one of these strings has been used in the URLs of
malicious worms at some point-- but there's far more potential for false
positives, as a cursory Google search for "download.php" will quickly
reveal, and besides, the worm writers can easily stay ahead of the block by
just changing a few filenames before their next release.
The Risks here should be obvious to anyone who wishes to send a link to Dave
Winer's blog at <http://www.scripting.com/>, the Scranton Times-Tribune at
<http://www.scrantontimes.com/>, or any one of numerous other perfectly
legitimate URLs that happen to contain one of the blocked strings.
Cody "codeman38" Boisclair cody@zone38.net http://www.zone38.net/
------------------------------
Date: Sun, 09 Jul 2006 23:08:39 -0500
From: Al Macintyre <macwheel99@sigecom.net>
Subject: Dirty Data contaminates Business Decisionmaking
Companies can be plagued with bad dirty data. Companies make business
decisions based on their data. The soundness of those decisions is
negatively affected by the degree to which there is bad data.
The degree to which various CASE tools, spread sheets, queries, etc. have
helped just anyone get at data, has also had the effect of lowering quality
control on data going into reports, because while many people are skilled at
data processing, and testing veracity of data, many are not.
http://www.itjungle.com/tfh/tfh071006-story08.html
------------------------------
Date: Tue, 18 Jul 2006 19:33:53 -0500
From: Al Macintyre <macwheel99@sigecom.net>
Subject: Corporate Risks
What are the odds?
1 in 6 of laptop or PDA stolen
4 in 5 data files stored unencrypted
2 in 3 data files transferred unencrypted
1 in 2 limits users ability to install whatever they please, irrespective
of risks
1 in 5 suffered data or network sabotage
1 in 4 not know if computers have been illegally accessed
2 in 5 not keep log of computer security incidents
9 in 10 suffered a computer security incident during the past year
ALL enterprises have some software installed on desk tops that computer
staff not know are there, and would not approve of if they did know
Other common problems
* Systems for security, that are so complicated that no one uses them, are
as bad as having no security at all,
* Computer systems functionality depends on various configuration files ...
who has access to them?
* Security needs to be documented, otherwise investigators will assume you
did not do it
* Employees bring unsecure home systems to the office, plug them into
corporate systems and guess what? now the corporate systems are
unsecure. Example, some employee at a financial institution had a lap top
from home with the wireless port wide open, plugs it into the system at
work, which is now wide open over the wireless port
* Each new technology has new security weaknesses unknown to people
installing them
* Executives consider corporate security rules do not apply to them, they
are free to break any of them
* People think the laptop breach laws do not apply to other portable
devices that can carry corporate data ... they are wrong
* Data is backed up, but can it also be restored in a crisis ... there
should be periodic checks that backups are getting everything they ought to
What keeps IT up at night?
http://www.infoworld.com/article/06/07/17/79603_29FEnightsweats_1.html
------------------------------
Date: Wed, 19 Jul 2006 17:47:23 -0700
From: John Pettitt <jpp@cloudview.com>
Subject: Banks not yet aware enough of phone-phishing
I got a call this week from a Florida number. When I answered a recorded
voice said that the fraud early warning dept of Citibank had a detected
activity on my card and would I call them back at 888-...-....
RISKS readers will no doubt see the problem here - I could be calling
anybody. Since the first thing the Citibank system asks is that you touch
tone or speak your card number customers are already expecting to give this
information. It would be trivial to also then ask for the CVV number and
exp date. Combine this with a name and address obtainable from numerous
databases to complete the data needed for fraud. With PC based VOIP systems
constructing such a scam that would call hundreds of people, trolling for
numbers, would be close to trivial and very hard to track. I suspect it
would actually work better than having a real human ask for the info in that
we are all conditioned to provide whatever the auto attendant says it needs
...
The answer is simple customers should call the number on the back of the
card never a number given on the phone and banks should not ask customer to
call unknown numbers.
(P.S. as it happens this call was real but a false positive, the Citibank
system has a lot of those, but that's another risk entirely)
------------------------------
Date: 2 Jul 2006 03:47:20 -0700
From: spinoza1111@yahoo.com
Subject: The Risks of retro computing?
Retro computing, also known as "computation for old guys" is all rather
charming, and creates a valuable historical record.
As an old guy who started on the IBM 1401, I suppose I should support the
(re)building of a working 1401 at the Computer History Museum in Mountain
View. But I have serious reservations.
The hardware system is being rebuilt down to the bare metal using original
technology including devices of some toxicity. This adds a somewhat useless
object to the world's stock of useless objects in view of the fact that the
IBM 1401 can be completely simulated on a modern computer without additional
toxicity: without making a new artifact of questionable usability.
It will when complete demonstrate what old computing was like, which was
noisy and rather satisfying if you were a young guy which I was.
However, this presents as an "important document" just one of many
computers, a computer which even in 1959 had significant limitations.
The 1401 was slow even in 1959 with an 11.5 ms cycle time. It used a strange
technique for addition and subtraction, called CADT (cannot add and does not
try) in which transistors essentially acted as decimal addition
tables. Modular programming was discouraged because there was no indirect
addressing.
The 1401 was aggressively marketed by IBM worldwide in a rather dishonest
campaign in which fearful, uncertain and doubtful managers were told it was
nothing more than a glorified printer, an accounting machine, and not really
a computer. Unfortunately it was and had marvelously arcane secrets. But,
these secrets also constituted a waste of time.
What's needed in place of weekend projects for retired engineers would be a
truly global encyclopedia in the form of software simulators (perhaps in the
form of a computer game) for all or most early world computers.
I don't think that recreating the actual hardware of the 1401 will damage
silicon valley's water table any more that it has been damaged; yet I cannot
escape a sense of recursive inelegance in the idea of having to rebuild a
system. Scaling up into the future, will more and more Old Guys be involved
in recreating more and more outdated systems until we're all so busy doing
retro computing we have no time for lunch?
When I visited the Computer Museum, I sensed somehow its psychology to be
hardware oriented, oriented toward a work ethic in which reification, making
a concept into a thing, reigned supreme. Lost in the reified history is of
course the programmers who had to write a divide routine because IBM was too
greedy to appropriately bundle the "extra cost hardware" into the
system. Lost in the reified history is the code that simulated divide
incorrectly, and lost too is the Fortran compiler in which I discovered a
handcoded multiply divide routine, inserted as a machine-language patch, by
an IBM customer engineer who thought the machine had no multiply/divide
hardware (it did) but didn't realize that there was no memory for the patch
at all on a minimal Fortran machine.
Lost in the reified history is the story of Labor. Resources currently
wasted in building working models of old devices could be used to create
oral histories of early computing. Of course, such an history would be
necessarily a critical history offensive to the sensitivities of the
Computer Museum's corporate sponsors.bouffant
Such an history would include not the professional models who pose so
elegantly in front of advertising snapshots of the 1401 in business suits
and bouffant hairdos but also operators in tears and exhausted programmers
(whose IBM training course was silent on Modify Address).
Cf. David Noble, Forces of Production. History is herstory and history, not
itsstory, the story of devices.
What's being reassembled is a device driven too much by exchange value and
not enough by use value. It deserves to be simulated but, perhaps, not
rebuilt.
------------------------------
Date: Thu, 20 Jul 2006 13:03:17 +1000
From: "Tim Chmielewski" <tim@humanedge.biz>
Subject: Risks of relying on the Web in wartime
Another Australian in Beirut says the Australian consulate refused to
register his presence in Lebanon, instead referring him to a website.
Austin Mackell has been living in Lebanon since February and says that with
electricity out in much of Beirut it is almost impossible to register his
presence online. (The Australian Government closed the consulate as soon as
the bombing started.)
http://www.theage.com.au/news/world/downer-defends-evacuation/2006/07/20/1153166495858.html
Tim Chmielewski, Webmaster, Human Edge Software
http://www.humanedge.biz <http://www.humanedge.biz/>
------------------------------
Date: Thu, 20 Jul 2006 18:32:55 +0300
From: "Amos Shapir" <amos083@hotmail.com>
Subject: Re: Yet another example of accidental disclosure of redacted info
(Emigh, RISKS-24.34)
I once received a TIF file of a document that was exactly that: a scanned
faxed image. But since the faxed printout was intended as a temporary step,
the sender used the back side of old printed pages for that. When I noticed
that the background of the sent TIF file was not completely white, it only
took a few b&w enhancement steps in a graphics application, to clearly
reveal what the sender did not intend to send!
There is even a risk in using blank paper for that, keeping in mind the
"secret" yellow-dot identification code which is generated by many
printers...
------------------------------
Date: Thu, 20 Jul 2006 09:07:50 +0100
From: "David H Smith" <d.smith@fnc.co.uk>
Subject: Re: Subject: Deceiving a computer is now a crime (Prevelakis, R 24 34)
> .. the attempt to attribute human characteristics to machines is bound to
> cause problems.
Er, not quite. The UK Government web site says
"Revised offence of obtaining services dishonestly (to fill a legal
loophole, since a machine cannot be 'deceived') with a maximum penalty of
five years' imprisonment."
http://www.commonsleader.gov.uk/output/page1221.asp
Frazer-Nash Consultancy Limited, Stonebridge House, Dorking Business Park,
Dorking, Surrey RH4 1HJ +44 (0) 1306 885050
------------------------------
Date: Mon, 10 Jul 2006 08:32:01 -0800
From: Rob Slade <rMslade@shaw.ca>
Subject: REVIEW: "Insider Threat", Eric Cole/Sandra Ring
BKINSTHR.RVW 20060615
"Insider Threat", Eric Cole/Sandra Ring, 2006, 1-59749-048-2,
U$34.95/C$48.95
%A Eric Cole
%A Sandra Ring
%C 800 Hingham Street, Rockland, MA 02370
%D 2006
%G 1-59749-048-2
%I Syngress Media, Inc.
%O U$34.95/C$48.95 781-681-5151 fax: 781-681-3585 www.syngress.com
%O http://www.amazon.com/exec/obidos/ASIN/1597490482/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/1597490482/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/1597490482/robsladesin03-20
%O Audience n- Tech 1 Writing 1 (see revfaq.htm for explanation)
%P 397 p.
%T "Insider Threat"
Abuse of your systems by insiders, those who have intimate knowledge of an
enterprise and its protective controls because they are either employees or
close partners, has always been a great security risk. In most cases these
people are aware of the existing safeguards, and usually some means to get
around them: in a large number of situations inside people actually operate
and manage security countermeasures and auditing functions. Protecting
yourself against insider attack is tricky.
(However, while we all know about insider attacks, insider abuse, and that
these are major problems, the term "insider threat" may be incorrect, and
the phrase itself an obstacle. In viewing employees, staff, contractors,
and partners as threats, instead of assets, we are making a serious mistake
in our definitions, and one that can have serious negative consequences for
the overall security of the enterprise.)
Part one examines insider threat basics. Chapter one points out that
insiders are threats. Various technologies for carrying or hiding
information are described in chapter two (although the text does admit that
one possibility for info release is the fact your employees simply leave the
building every night with everything they know).
Part two looks at government. Chapter three, about state and local
authorities, notes the type of functions that are managed at this level, and
the damage that can be done if this information is misused. The material
seems to be bundled together in a random fashion. There are a number of
"case studies," which are really just stories of situations where an insider
has abused his or her position. Much the same is done with the federal
government in chapter four.
Part three turns to corporations. Chapter five starts off with an extremely
odd statement, seeming to imply that nobody was much aware of the insider
threat until a 1998 study. (However, this may signal one of the major
problems with the book: the term "insider threat" was first used in a
classified paper in 1997.) It has a brief, but useful, examination of
various types of damage that an insider can do in a commercial enterprise
(sabotage, theft of intellectual property, theft of customer data, damage to
reputation, and direct financial fraud), and then we are back to the stories
again. More case studies are given regarding the banking and financial
sector, in chapter six, and government subcontractors, in seven.
Part four is entitled "Analysis," but there isn't all that much. Chapter
eight looks at profiles, despite the fact that the second last case study
(in chapter seven) noted that the insider was so successful because he
didn't fit the commonly perceived profile. The basic profile provided may
be helpful in distinguishing low-end threats who may deserve further
examination: the "high-end" profile identifies most senior managers. The
responses suggested in chapter nine are primarily basic protections (and
mostly suitable for defending against outside threats); some of the
additional measures are only effective if you already have a suspect. Most
of the content in chapter ten relates to fundamental risk analysis.
The risks posed by insider knowledge are important. Unfortunately, other
than providing a fund of illustrative stories, this book does not provide
much material that would be of assistance to those concerned with
protection. And, as noted previously, the title, and the general tone of
paranoia pervading the work, are risks in themselves.
copyright Robert M. Slade, 2006 BKINSTHR.RVW 20060615
rslade@vcn.bc.ca slade@victoria.tc.ca rslade@computercrime.org
http://victoria.tc.ca/techrev/rms.htm
------------------------------
Date: Mon, 03 Jul 2006 09:41:29 -0800
From: Rob Slade <rmslade@shaw.ca>
Subject: REVIEW: "Practical VoIP Security", Thomas Porter et al.
BKPVOIPS.RVW 2060602
"Practical VoIP Security", Thomas Porter et al., 2006, 1-59749-060-1,
U$49.95/C$69.95
%A Thomas Porter
%C 800 Hingham Street, Rockland, MA 02370
%D 2006
%G 1-59749-060-1
%I Syngress Media, Inc.
%O U$49.95/C$69.95 781-681-5151 fax: 781-681-3585 amy@syngress.com
%O http://www.amazon.com/exec/obidos/ASIN/1597490601/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/1597490601/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/1597490601/robsladesin03-20
%O Audience i- Tech 2 Writing 1 (see revfaq.htm for explanation)
%P 563 p.
%T "Practical VoIP Security"
VoIP (Voice over Internet Protocol) is something of the new kid on the
technology block, and computer folks may have limited experience with
telephony. It therefore seems a bit strange that chapter one, as an
introduction to VoIP security, starts out by talking about computer security
and attacks. However, the structure of the book is rather odd in any case.
The basics of telephony, and the Public Switched Telephone Network (PSTN),
are not covered until chapter four. Even then, while there is some useful
trivia, most of the content is a list of telephony protocols. Chapter three
covers some of the basic hardware and element information, discussing PBX
(Private Branch eXchange) systems, VoIP components, and even power supplies.
That material, in turn, would be helpful to those who try to understand
chapter two, which is supposed to be about the Asterisk PBX software
package. Although the text purports to deal with configuration and features
of Asterisk, most of the section's content covers PBX operations and
functions, dial plans, telephony numbering plans, and even a terse piece on
the vital aspect of circuit versus packet switching.
With chapter five, the book moves into some of the specifics of VoIP,
discussing H.323, a protocol to specify data formats that is used
extensively in commercial IP telephony products. SIP, the Session
Initiation Protocol (used to negotiate interactive sessions over the net),
gets a more detailed treatment (along with examination of related protocols)
in chapter six. Other IP telephony architectures are briefly listed in
chapter seven: the very popular Skype, H.248, IAX (Inter Asterisk eXchange),
and Microsoft's Live Communications Server 2005 (MLCS). Diverse protocols
used in support of VoIP are discussed in chapter eight. Most of these are
commonly used in other Internet applications: some; such as RSVP (Resource
reSerVation Protocol), SDP (Session Description Protocol), and Skinny; are
more specialized. All the listed protocols have some review of security
implications, which marks the first time in the book that security seems to
be a major issue.
Chapter nine examines specific threats and attacks, mostly related to denial
of service and hijacking. Securing the infrastructure used for VoIP is
important, although the material in chapter ten is fairly standard
information security. Chapter eleven reviews a number of ordinary
authentication tools that are frequently used in VoIP. "Active Security
Monitoring," in chapter twelve, is the traditional intrusion detection and
penetration testing, and has nothing specific to IP telephony applications.
Similarly, chapter thirteen examines normal traffic management and LAN
segregation issues: the only telephony related content is in regard to VoIP
aware firewalls. The IETF (Internet Engineering Task Force) has recommended
certain existing security protocols in regard to IP telephony, and one
addition (SRTP, Secure Real-time Transfer Protocol): these are outlined in
chapter fourteen. Chapter fifteen lists various (United States) data
security related regulations and the European Union privacy directive. The
IP Multimedia Subsystem (IMS) structure is reviewed in chapter sixteen.
Chapter seventeen repeats the recommendations made in chapters ten through
fourteen.
It is handy to have a number of the issues related to VoIP addressed in one
work. There is some depth to the content of the text as well, and those
dealing with system internals may find that useful. However, for those who
need to manage or make policy or purchasing decisions in regard to VoIP,
this book may not have the forcefulness of complete analysis, or a structure
that would assist in learning the background. While there is a considerable
amount of helpful information, it reads more like an accumulation of
miscellaneous facts than a directed study.
copyright Robert M. Slade, 2006 BKPVOIPS.RVW 2060602
rslade@vcn.bc.ca slade@victoria.tc.ca rslade@computercrime.org
http://victoria.tc.ca/techrev/rms.htm
------------------------------
Date: 2 Oct 2005 (LAST-MODIFIED)
From: RISKS-request@csl.sri.com
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@csl.sri.com
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@csl.sri.com or risks-unsubscribe@csl.sri.com
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@newcastle.ac.uk>.
=> SPAM challenge-responses will not be honored. Instead, use an alternative
address from which you NEVER send mail!
=> SUBMISSIONS: to risks@CSL.sri.com 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 [subdirectory i for earlier volume i]
<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
------------------------------
End of RISKS-FORUM Digest 24.35
************************
