TidBITS#442/10-Aug-98
=====================

  After writing several articles about data security and the
  importance of a good backup system, Adam and Tonya find themselves
  putting that information to the test after thieves break into
  their house and abscond with a PowerBook. Also in this issue,
  Geoff explains in detail how to respond to spam, WebSTAR 3.0.1
  ships, Qualcomm sells Now Utilities to Power On Software,
  Connectix updates RAM Doubler 8, and we announce a Chinese TidBITS
  mailing list.

Topics:
    MailBITS/10-Aug-98
    Responding To Spam
    Ripped Off!

<http://www.tidbits.com/tb-issues/TidBITS-442.html>
<ftp://ftp.tidbits.com/pub/tidbits/issues/1998/TidBITS#442_10-Aug-98.etx>

Copyright 1998 TidBITS Electronic Publishing. All rights reserved.
   Information: <info@tidbits.com> Comments: <editors@tidbits.com>
   ---------------------------------------------------------------

This issue of TidBITS sponsored in part by:
* APS Technologies -- 800/443-4199 -- <sales@apstech.com> -- How
   do you back up your APS hard disks? Try APS tape, removable,
   magneto-optical, and CD-R drives! <http://www.apstech.com/>

* Northwest Nexus -- 1 888-NWNEXUS -- <http://www.nwnexus.com/>
   Internet business solutions throughout the Pacific Northwest.

* Small Dog Electronics -- Special Deal for TidBITS Readers!
   MS Office 98 & 4.2.1, Grolier's, Blockbuster, and Dogs: $299!
   UMAX Astra 610s (refurb) flatbed scanner (Mac/PC software): $79
   For Details: <http://www.smalldog.com/> -- 802/496-7171

* Cyberian Outpost -- the Cool Place to Shop for Computer Stuff! <- NEW!
   Kensington security products to safeguard all your hardware!
   Order online or call 860/927-2050 x228
   <http://www.tidbits.com/tbp/kensington-microsaver.html>

* TERRY MORSE MYRMIDON
   Turns any Mac file into a Web page with one click!
   QuarkXPress, PageMaker, FreeHand, FileMaker Pro -- anything.
   FREE DEMO --> <http://www.terrymorse.com/> <-- FREE DEMO
   ---------------------------------------------------------------

MailBITS/10-Aug-98
------------------

**Eudora Pro Security Hole for Windows Only** -- After last week's
  CIAC advisory regarding possible security problems in primarily
  Windows email clients, a different security issue has been
  revealed in Windows versions of Eudora Pro. Eudora Pro 4.0, 4.01,
  and 4.1 betas for Windows can utilize Microsoft's HTML viewer when
  displaying messages, and that viewer can permit automatic
  execution of items included in the message, such as Java applets.
  In theory, other Windows applications that use Microsoft's HTML
  viewer could also be vulnerable. Qualcomm has released an updater
  to 4.0.2 that makes Eudora Pro ask for permission before executing
  programs automatically. As a workaround, disable Microsoft's HTML
  viewer in the Viewing Mail settings panel of Eudora's Options
  dialog box. Eudora Light is not vulnerable, and Macintosh versions
  of Eudora have been safe for years because they encapsulate any
  attached applications so users must specifically choose to execute
  them. However, the bottom line remains unchanged: don't launch any
  attachments unless you're sure they're safe. [GD]

<http://db.tidbits.com/getbits.acgi?tbart=05018>
<http://eudora.qualcomm.com/security.html>


**Chinese Mailing List Available** -- Thanks to renewed efforts on
  the part of our Chinese translation team, a separate mailing list
  is now available for people who want to receive TidBITS via email
  in Chinese, using the Big-5 character encoding standard. To
  subscribe, send email to <tidbits-b5-on@tidbits.com>, and please
  tell friends who might like reading TidBITS in Chinese. (Chinese
  versions of TidBITS are also available via the Web.) As always,
  our thanks to the Chinese translation team along with all the
  polyglot folks who translate TidBITS into other languages for
  their outstanding work and for making TidBITS available to a much
  wider audience. [ACE]

<http://www.tidbits.com/tb-issues/lang/b5/>
<http://www.tidbits.com/about/translations.html>


**WebSTAR 3.0.1 Update Ships** -- StarNine Technologies last week
  released WebSTAR 3.0.1, a free update to the company's popular
  $499 Web server. Along with bug fixes, enhancements include
  improved compatibility with FTP clients, enhanced HTTP support,
  and better site indexing and searching capabilities. The download
  is a beefy 15.3 MB. [ACE]

<http://www.starnine.com/webstar/webstar.html>


**Now Utilities Powers On** -- Qualcomm announced that it is
  selling Now Utilities to Power On Software, creators of ACTION
  Files. Like Now Super Boomerang, Action FILES enhances file access
  within Open and Save dialog boxes (see "Get a Piece of the ACTION
  Files" in TidBITS-434_). Power On will continue to sell and
  provide support for Now Utilities, and it's likely that components
  of Now Utilities will be rolled into Power On's upcoming ACTION
  Utilities. Owners of Now Super Boomerang, which hasn't been
  updated to work under Mac OS 8, will be directed to ACTION Files.
  Terms of the purchase were not disclosed. [JLC]

<http://www.actionutilities.com/html/nowutilities_press_release.html>
<http://db.tidbits.com/getbits.acgi?tbart=04931>


**RAM Doubler 8 Upgrade Adds Speed, Stability** -- Connectix
  Corporation released a free upgrade to its memory optimization
  tool RAM Doubler last week, tweaking the utility's speed and
  offering greater stability. This release follows on the heels of
  the RAM Doubler 8 upgrade, free to registered users of RAM Doubler
  2.x (see "Free RAM Doubler 8 Update" in TidBITS-439_). Version
  8.0.1 resolves problems using the RAM Doubler control panel with
  older versions of the Finder in low-memory situations, speeds up
  application launches on PowerPC-based Macs with large amounts of
  memory, and fixes a rare problem where a write-protection fault by
  other applications could freeze the computer. The updater is a
  390K download. [JLC]

<http://db.tidbits.com/getbits.acgi?tbart=04992>
<http://www.connectix.com/html/rd__mac__update.html>


Responding to Spam
------------------
  by Geoff Duncan <geoff@tidbits.com>

  Nearly two years ago, I wrote an article in TidBITS-347_ called
  "Those Bulk Email Blues," which outlined issues surrounding
  unsolicited commercial email ("spam"), and how to respond to those
  messages.

<http://db.tidbits.com/getbits.acgi?tbart=00863>

  Although much of that article remains relevant, times have
  changed. Spam continues to increase: since 01-Jun-98, I've
  received nearly 800 spams, an average of more than 11 per day.
  Further, spammers frequently probe my network looking for mail
  servers to exploit - my servers are locked down, but occasionally
  I run a dummy server that reports attempted spamming back to the
  originating network (and laughs gleefully when it does so). I'm
  also a party in the TidBITS lawsuit to test Washington's anti-spam
  legislation.

<http://www.tidbits.com/anti-spam/>


**Don't Be Complacent** -- During the last two years, I've become
  convinced that failing to report spam responsibly contributes to
  the wider spam problem. By failing to report spam, Internet users
  send an implied message to network providers, and hence to
  spammers: "This message didn't bother me enough to report;
  therefore, it is acceptable." If Internet users want spamming to
  stop, they must send a consistent, explicit message: spamming is
  _unacceptable_. Users can send that message by working toward
  effective legislative and technological solutions, and by
  reporting spamming incidents.

  The problem is how to report spam. Most spammers try to cover
  their tracks: they use bogus return addresses, insert false
  headers, and relay messages through unsecured mail servers.
  Nonetheless, it is possible to figure out where you should report
  most incidents. Doing so requires time and some knowledge - but,
  as with all things, the more you do it, the easier it gets.


**Identifying the Server** -- To report a spamming incident, you
  must determine what Internet server sent the spam message to you,
  which means looking through the message's Received headers. Ignore
  return addresses or From lines: they're easily forged. Received
  headers are typically grouped near the top of a raw email message
  and appear in a particular order: the topmost header is the most
  recent, and (in theory) the bottommost indicates the message's
  origin. Email messages always have at least one Received header.

  The bottommost Received header may not always identify the
  originating system. Spammers often forge one or more Received
  headers to throw you off the trail, but they can't forge them all.
  Forged Received headers appear beneath any legitimate Received
  headers and are often obviously different.

  The only guaranteed way to figure things out is to start from the
  topmost Received header and work down. Look for the first Received
  header that claims to have sent the message to the domain where
  you receive email. If you have an account with EarthLink, for
  example, look for the first header that mentions an EarthLink
  system. Here's a fictional header that points to a location on my
  network:

> Received: from Fred (pointless.quibble.com [204.57.207.56])
>   by smtp100.earthlink.net (8.8.8/8.8.8) with SMTP id MAA17789
>   for <your_name@earthlink.net>; Sun, 9 Aug 1998 12:55:13 -0700

  You can see the system smtp100.earthlink.net received a message
  from a machine calling itself "Fred," a name probably supplied by
  the spammer. However, EarthLink's mail server didn't blindly
  accept Fred's statement of identity and performed a DNS lookup,
  discovering that Fred's canonical name is pointless.quibble.com.
  (All Internet machines have at least one unique IP number;
  machines don't require any assigned name, but can have many names,
  only one of which is canonical.) EarthLink's mail server inserted
  pointless.quibble.com in the Received header along with the
  machine's IP number to make it easier to track the origin of the
  message. This is good - these days, mail servers at many
  responsible Internet providers tag messages in this manner. Now
  you know the message came to EarthLink from quibble.com, and
  that's probably where you want to send your spam report. Let's
  look at a more complex example:

> Received: from pointless.quibble.com (pointless.quibble.com
>   [204.57.207.56]) by smtp100.earthlink.net (8.8.8/8.8.8) with
>   SMTP id MAA17789 for <your_name@earthlink.net>;
>   Sun, 9 Aug 1998 12:55:13 -0700
> Received: from Fred by pointless.quibble.com id QQfbjb05104
>   Sun, 9 Aug 1998 12:54:34 -0700 (PDT)

  Here we can see that a machine calling itself Fred connected to a
  machine calling itself pointless.quibble.com, which didn't do any
  checking on Fred. Then, pointless.quibble.com connected to
  EarthLink, which confirmed the machine's name and delivered the
  message to you.

  This second instance is probably a case of "relaying," where a
  spammer found an exploitable mail server in the quibble.com
  domain. This particular server would be a spammer's dream because
  it doesn't identify the machine that sent the message in the first
  place. The administrators of quibble.com may not be involved with
  the spammer and may not even be aware their system was used to
  distribute spam. You still want to report the incident to
  quibble.com and strongly encourage them to disable relaying on
  their mail server. Unfortunately, there isn't enough information
  to track the spammer further; hopefully, quibble.com's mail server
  keeps logs that would enable its administrators to determine the
  spam's origin.

  If any of your mail is forwarded to you from another address, you
  may need to ignore one or more topmost Received headers. For
  instance, all mail to <geoff@tidbits.com> is forwarded to me at
  quibble.com. The topmost Received line in spam to
  <geoff@tidbits.com> always says that quibble.com received the
  message from tidbits.com. But the TidBITS server didn't originate
  the spam; I need to look at subsequent Received headers to see
  what machine sent the message to the TidBITS server.


**IP Numbers & Ranges** -- Sometimes even a well-configured email
  server won't be able to look up a canonical name for the machine
  giving it an email message. A Received header might look like
  this:

> Received: from 204.57.207.56 ([204.57.207.56])
>   by smtp100.earthlink.net (8.8.8/8.8.8) with SMTP id MAA17789
>   for <your_name@earthlink.net>; Sun, 9 Aug 1998 12:55:13 -0700

  To report this incident, you need to figure out who's responsible
  for the IP number 204.57.207.56. First, try a DNS lookup yourself
  to see if the number has an assigned name. Many utilities will
  perform a DNS lookup. For the Mac, I recommend Peter Lewis's $10
  Mac TCP Watcher or Peter Sichel's $20 IPNetMonitor, both of which
  also include traceroute tools.

<http://www.stairways.com/mtcpw/>
<http://www.sustworks.com/~psichel/products/product_ipnm.html>

  Looking up 204.57.207.56 should reveal pointless.quibble.com,
  which indicates that you should report the incident to
  quibble.com. But let's say no name turned up. Your next best bet
  is to use a Whois server to determine who's responsible for that
  IP number. The Whois protocol enables you to ask a network
  authority for information about domains, systems, and points of
  contact for Internet sites. Unfortunately, there is no central
  network authority for the entire Internet. The American Registry
  for Internet Numbers (ARIN) maintains a good Whois database for
  domains registered in the U.S.; I always try ARIN first. Other
  network authorities include the InterNIC, RIPE (for European
  domains), and APNIC (Asia Pacific). Services like Allwhois.com try
  to be comprehensive but are more useful for determining if a
  particular domain is available, rather than figuring out IP number
  assignments.

<http://whois.arin.net/whois/arinwhois.html>
<http://rs.internic.net/tools/whois.html>
<http://www.ripe.net/db/whois.html>
<http://www.apnic.net/reg.html>
<http://www.allwhois.com/>

  You may have to check with several authorities before you find
  who's responsible for an IP number. You may also have better luck
  searching for a range of IP numbers using an asterisk
  ("204.57.207.*") than looking for a single IP number, although
  you'll need to be careful interpreting the results. Multiple
  searches are awkward via the Web; you can also use a dedicated
  Whois client to query the databases directly. On the Mac, try
  IPNetMonitor or Peter Lewis's $10 Finger, which can query Whois
  servers.

<http://www.stairways.com/finger/>

  If you look up 204.57.207.56 or 204.57.207.* via appropriate Whois
  servers, you find Northwest Nexus, which is my upstream ISP. If
  you were to report a spam incident from my domain to Northwest
  Nexus, I'd be taken to task quickly. Not all providers are that
  responsible, however; if spamming persists from a domain or an IP
  number after you've reported a few incidents, you can use a Whois
  server to figure out who's upstream from the responsible party -
  usually AT&T, Sprint, UUNET, or another large network provider.
  Most high-level network providers have a low tolerance for spam,
  but may only be able to forward complaints to their customers,
  such as regional ISPs. In my experience, reporting spam to upper-
  level network providers is only moderately effective.

  If you can't use Whois to figure out who controls an IP number,
  your last option is a traceroute utility. Traceroute essentially
  figures out the path that packets are taking between two Internet
  machines. This path should show you what sites are "closest" to
  the IP number that sent the spam. You could send spam reports to
  the domain indicated as "closest" to the IP number that sent the
  spam message. However, be aware that Internet routing is dynamic:
  although the specific path between two machines usually doesn't
  change from moment to moment, it _can_ change at any moment.
  Machines near your target IP number may have nothing to do with
  the spammer or the organization responsible for the IP number. If
  you report a spam incident using data obtained from traceroute, do
  so politely.


**How to Report Spam** -- When reporting a spam incident, include
  the complete text and headers of the message you received:
  administrators need this information to verify the incident. A
  courteous, professional message is always more effective than a
  vitriolic rant. I begin my reports with this boilerplate text:

  I received the following unsolicited commercial email ("spam")
  that was either sent directly by one of your users, relayed
  through a mail server on your site or network, or sent from a
  dialup pool or downstream network administered by your
  organization. I've enclosed the complete message below with full
  headers; please ensure this doesn't happen again.

  Since I live in Washington State, my messages also point to
  information about Washington's anti-spam legislation and mention
  the per-incident damages Washington residents can try to collect.

  Send spam reports to the username "postmaster" and, optionally,
  "abuse" at the domain you've determined is responsible for the
  spam. The postmaster address is almost universally valid for a
  domain; the abuse address is less common but is often set up as a
  reporting address for spamming incidents.

  For best results, always report spam to an address at a domain,
  not to a specific machine. In the examples above, you would use
  <postmaster@quibble.com> rather than
  <postmaster@pointless.quibble.com>. If the spam originated from a
  site using a two-letter country code (such as .us) rather than a
  three-letter top-level domain (such as .com or .edu), the domain
  will contain at least three parts (reno.nv.us) rather than two
  (quibble.com).


**Removal Services** -- What about removal services listed in spam
  messages, or sites purporting to be "global remove" lists? Two
  years ago, I recommended these removal services, figuring that
  responsible bulk mailers (there are a few) will remove your name
  from their lists and irresponsible ones have your address anyway,
  so there's no harm in trying.

  Today, I can't recommend any removal services. Although a few are
  legitimate, far too many are either non-existent or simply
  address-collection clearing houses. One instance I chased down
  turned out to be a sophisticated operation used by several
  spammers: they collected the removal requests, then sold the
  senders' addresses to other spammers as "fresh addresses."


**Don't Just Take My Word for It** -- The issues surrounding spam
  are often the subject of debate. Although this article contains
  technical information and tips, in the end it's just my opinion.
  If you're interested in learning more - including other opinions
  about responding to spam or current legislative and technology
  initiatives - some of the links Adam has collected regarding
  TidBITS's anti-spam lawsuit are a good place to start.

<http://www.tidbits.com/anti-spam/spam-info.html>

  Will the techniques outlined here stop the flow of spam into your
  mailbox? No. Is reporting spam simple? No. But at least reporting
  spam appropriately is an alternative to complacency, and you'll
  have the satisfaction of hearing from providers who have shut down
  spammers thanks to your reports. For that alone, many people will
  thank you.


Ripped Off!
-----------
  by Adam C. Engst <ace@tidbits.com>

  Let me tell you a story that highlights the importance of some of
  the issues surrounding backups and information security that I've
  been harping on in TidBITS lately.


**A Weekend Away** -- Two weekends ago, on Saturday morning, Tonya
  and I were getting ready to visit friends for the weekend. I was
  finishing an Indian dish for dinner and checking the weather
  forecast on our "kitchen Mac" - a PowerBook 5300 connected via
  Ethernet to the rest of our network and to the Internet. Suddenly,
  the PowerBook beeped and displayed a dialog from Retrospect Client
  telling me that it hadn't backed up for a while. I tried to use
  Timbuktu to connect to our backup Mac, a Centris 660AV, realized
  that the machine had crashed, and went downstairs to restart it. A
  while later I remembered to check on it again. Curses! The crash
  had messed up Retrospect's catalog file, and Retrospect wanted me
  to verify it before proceeding. I started the verification, but
  Retrospect's log claimed the tape drive needed its heads cleaned.
  Muttering about the universe being after me, I popped in the
  cleaning tape, then replaced the backup tape and started the
  verify process again. About this time, Tonya was giving me those
  "We should have left ten minutes ago and you're messing around
  with the computer" looks, so I decided the verify process could
  work on its own, closed the PowerBook, locked the door, and left.

  The weekend was marked primarily by aquatic sports and sunburns
  courtesy of defective sunscreen. Our time was relatively
  Macintosh-free, aside from maintenance on a PowerBook 165 used by
  our friends's son to communicate via voice synthesis and typing
  with head switches (he has cerebral palsy and is confined to a
  wheelchair). Sunday evening on the way home, we had dinner with
  Geoff Duncan, who mentioned our 56K frame relay connection was
  down. I checked from his place, and while the router responded to
  pings no other machine on our network responded. Weird.


**Arriving Home** -- When we returned home, the mystery resolved
  itself in an ugly fashion. The door was unlocked, and on the
  kitchen floor were the boxes that the PowerBook 5300 had sat on,
  with the 10-Base2 Ethernet cable pulled out of the wall. The
  PowerBook was gone. I checked the rest of the computers, but
  nothing else had been touched, aside from a broken window pane at
  the back of the house.

  Slowly, we pieced together what must have happened. The thief
  probably rang the doorbell, noticed that no lights came on (our
  other car was there, so we could have been home), and decided to
  case the joint. Looking in the kitchen window, the thief saw the
  PowerBook and our alarm system sticker, and decided on a fast job.
  Slinking around back, the thief picked a window without an alarm
  sticker, broke it in, and immediately went to the kitchen (passing
  by Tonya's Mac). Once there, the thief grabbed the PowerBook and
  all the cables attached to it, and then took a wooden stamp box
  Tonya gave me years ago from a drawer beneath the PowerBook
  (though not the stamps - go figure). That done, the thief unlocked
  the door and fled.

  The burglary took place about 1:45 AM Sunday morning, since the
  thief's clumsy efforts to disconnect the PowerBook caused our
  Ethernet network to go down at exactly 1:48 AM. That explained why
  the router answered pings, but all other machines were dead to the
  world. Later, the police came, took down the details, and said
  they'd keep an eye out for the PowerBook at pawn shops. The next
  day, I started the claim process with the insurance company, which
  has been reasonable so far. Although we have a $1,000 deductible,
  I should be able to get a PowerBook G3 to replace the 5300.


**Backup Lessons Hammered Home** -- After I picked up the pieces
  and restored the network, I went to check on the backup.
  Retrospect's verification had finished but had prevented backups
  from running Saturday night. When I dismissed the verify
  completion dialog and started the backup server, Retrospect
  started reporting errors with the current tape. In short, although
  I might be able to recover some data from that tape, there's no
  telling.

  Remember all those articles I wrote about backup? Here are some
  real-world examples of what did and could have gone wrong.

<http://db.tidbits.com/getbits.acgi?tbser=1041>

* Always make multiple backup sets. Thanks to the dubious tape I
  was fighting with on Saturday, I'll probably have to return to the
  previous week's set to recover the PowerBook's files.

* Off-site backups are essential. I've recently made a point of
  rotating a backup set to an off-site location each week. Although
  the backup tapes weren't stolen, they could have been.

* Fight backup complacency. The universe has a twisted sense of
  humor and an unknown agenda, which means that something will go
  wrong just when you least expect it. We seldom go away for the
  weekend, the backup Mac seldom crashes, tapes seldom develop
  errors, and we've never been burglarized before. The entire point
  of a backup strategy is to prevent unhappy coincidences from
  mutating into catastrophes.


**Security Musings** -- In situations like this, you immediately
  start obsessing about security and what you could have done. Here
  are a few of my more realistic thoughts (i.e., those that don't
  involve automated gun turrets on the roof).

* I'm planning to enable password protection in Retrospect for my
  backup sets. It's unlikely a thief would steal the backup tapes
  and know what to do with them, but if the backup Mac was also
  stolen, there's no telling what could happen. We don't have much
  sensitive information, but we still don't want miscreants poking
  through personal email and financial records.

* Situations like this are a great example of why Web Confidential
  (see TidBITS-441_) can be useful. I didn't keep confidential data
  on that PowerBook, but many people do, especially heavy
  travellers. And, even if you kept that information on paper in a
  safe deposit box, it's still vulnerable en route to the bank, and
  even safe deposit boxes aren't completely safe.

<http://db.tidbits.com/getbits.acgi?tbart=05020>

* On the back of many of Apple's hardware devices, there's a
  security slot (sometimes two, in different sizes). Metal clips
  plug into that slot and provide an anchor point for lockable
  cables. The larger slot seems to be older, and folks on TidBITS
  Talk report that Apple used to sell security kits. Nowadays you
  get them from Byte Brothers, Security Solutions, or University
  Accessories. The smaller slot is the Kensington Security Standard,
  and Kensington and other companies offer security products to fit.
  TidBITS sponsor Cyberian Outpost sells the Kensington MicroSaver
  products; check the sponsorship area above for details. I'm
  contemplating investing in one of these solutions for all my Macs.

<http://www.bytebros.com/macsecu.htm>
<http://www2.security-solutions.com/security/ssproducttdcmac-1.html>
<http://www.usecure.com/mackits.html>
<http://www.kensington.com/products/>

* I keep thinking there should be a way to have our computers
  watch the house more carefully. I have an analog-to-digital
  converter (the EnviroMac from Remote Measurement Systems, which I
  plan to write more about soon). I could check light level changes
  and play sounds or control lights, for instance. Email or
  telephone alerts are also possible, but false alarms are too
  likely, so I'd settle for scaring away robbers.

<http://www.measure.com/>

  This isn't a topic I've thought much about before, so I'd like to
  open it up to discussion on TidBITS Talk. If you've set up a
  security system involving Macs (perhaps via a Connectix QuickCam
  and DigitalRadar) send your story to <tidbits-talk@tidbits.com>
  and I'll post the best ones. To subscribe to TidBITS Talk, visit
  the second URL below.

<http://www.connectix.com/html/digitalradar.html>
<http://www.tidbits.com/about/tidbits-talk.html>


**Stolen PowerBook Registry** -- I found a new service offered by
  the good folks at O'Grady's PowerPage. O'Grady's Stolen PowerBook
  Registry is a Web database with which you can register stolen
  PowerBooks by serial number and check to see if a PowerBook you're
  thinking of buying was stolen. I've already registered my
  PowerBook, and I encourage other victims of PowerBook theft to do
  so as well.

<http://celebs.ogrady.com/larceny/>

  Laptops are an increasingly common target, since they're expensive
  and small. I've seen numbers claiming as many as 1 in 14 laptops
  are stolen, and Safeware Insurance said recently that companies it
  insures filed $1 billion worth of claims for almost 310,000 stolen
  laptops in 1997, up 28 percent from 1996. Laptops are simply too
  attractive as theft targets, as evidenced by the fact that our
  thief stole little else. Ironically, the claims coordinator I've
  been working with said that Macs are far more commonly stolen than
  PCs - perhaps we aren't giving thieves sufficient credit. In the
  end, the moral of the story would seem to be that you should do as
  much as is reasonable without succumbing to paranoia that would
  have you afraid to leave your possessions for even a few moments.




$$

 Non-profit, non-commercial publications may reprint articles if
 full credit is given. Others please contact us. We don't guarantee
 accuracy of articles. Caveat lector. Publication, product, and
 company names may be registered trademarks of their companies.

 This file is formatted as setext. For more information send email
 to <setext@tidbits.com>. A file will be returned shortly.

 For information: how to subscribe, where to find back issues,
 and more, email <info@tidbits.com>. TidBITS ISSN 1090-7017.
 Send comments and editorial submissions to: <editors@tidbits.com>
 Back issues available at: <http://www.tidbits.com/tb-issues/>
 And: <ftp://ftp.tidbits.com/pub/tidbits/issues/>
 Full text searching available at: <http://www.tidbits.com/search/>
 -------------------------------------------------------------------




