TidBITS-J#442/10-Aug-98 TidBITS-J#442/10-Aug-98データのセキュリティ問題や良いバックアップシステムの重要性に関する 記事を書いてきたところで、Adam と Tonya は空き巣を狙われ PowerBook が盗難に遭い、自らを試すことになってしまった。そのほかに今週号では、 Geoff によるスパムへの対応方法の詳細説明、WebSTAR 3.0.1 の出荷、 Qualcomm 社から Power On Software 社へ Now Utilities 売却、Connectix 社の RAM Doubler 8 アップデート、TidBITS の中国語翻訳版メーリングリ ストのニュースをお送りする。
目次：
Copyright 1997 TidBITS Electronic Publishing. All rights reserved.
問い合わせは <info@tidbits.com> へ、感想は <editors@tidbits.com> へ。
TidBITS 日本語版は TidBITS 日本語版翻訳チーム メン バーのボランティアによって翻訳・発行されています。
今回の TidBITS のスポンサーは：
（翻訳：尾高 里華子 <rikako@pobox.com>）
Windows だけに開いた Eudora Pro セキュリティの穴 -- 主に Windows のメールクライアントで起りえるセキュリティ問題に関する先週の CIAC 報告の後、Windows 版 Eudora Pro の別のセキュリティ問題が判明した。 Windows 用の Eudora Pro 4.0、4.01 およびベータ版 4.1 はメッセージ表 示に Microsoft 社製 HTML ビューワーを利用できるようになっており、こ のビューワーが Java アプレットのようなメッセージに含まれるアイテム の自動実行を行いえるのである。この理論からすると、Microsoft HTML ビューワーを利用するほかの Windows アプリケーションも同様に危ないこ とになる。Qualcomm 社は Eudora Pro がプログラムを自動的に実行する前 に承諾を乞うようになる 4.0.2 へのアップデータをリリースした。とりあ えずの処置として、Eudora の Options ダイアログボックスの Viewing Mail 設定パネルで Microsoft HTML ビューワーを使わないようにすること ができる。Eudora Light は問題なく、Macintosh 版の Eudora も相変わら ず安全だ。どちらもユーザー自身が GO サインを出さないかぎり添付アプ リケーションは実行されないようになっているからだ。とは言え、肝心な ことを忘れないように。安全なものだという確信のない添付書類等は開か ないことだ。 [GD]
<http://db.tidbits.com/getbits.acgi?tbart=05018>
<http://eudora.qualcomm.com/security.html>
中国語用のメーリングリスト開始 -- 我々の中国語翻訳チームの努力の 末、繁体字のエンコード標準である Big-5 で書かれた中国語翻訳版の TidBITS をメールで受け取るためのメーリングリストができた。購読申し 込みは、<tidbits-b5-on@tidbits.com> 宛にメールを送付して行う。中国 語で TidBITS を読みたいという友人がいたらぜひ教えてあげて欲しい。 （TidBITS の中国語翻訳版は Web から読むこともできる。）中国語翻訳 チームのみならず、TidBITS を様々な言語に翻訳してくれている仲間の大 変な努力にはいつも感謝し、TidBITS がより多くの読者を得られることを ありがたく思っている。 [ACE]
<http://www.tidbits.com/tb-issues/lang/b5/>
<http://www.tidbits.com/about/translations.html>
WebSTAR 3.0.1 アップデート出荷 -- StarNine Technologies 社は先週 同社の評判の Web サーバ（499 ドル）の無料アップデート WebSTAR 3.0.1 をリリースした。バグフィックスのほかに、FTP クライアントとの互換性 の向上、HTTP サポートの強化、サイトのインデックスや検索機能の向上な どの改善点がある。ダウンロードサイズは 15.3 MB と結構な量である。 [ACE]
<http://www.starnine.com/webstar/webstar.html>
Now Utilities にパワーを -- Qualcomm 社は Now Utilities を ACTION Files の製作元でもある Power On Software 社に売却するとの発表を行っ た。Now Super Boomerang 同様 Action FILES は“開く”や“保存”の ダイアログボックス内でのファイルのアクセスを向上してくれる （ TidBITS-434 の“ACTION Files の使命”を参照）。Power On 社は Now Utilities の販売とサポートを続ける予定である。Now Utilities のコン ポーネントは登場間近の ACTION Utilities に組み込まれるであろう。Now Super Boomerang は Mac OS 8 で動くようにアップデートされておらず、 ユーザーが ACTION Files に流れるだろう。売却条件については明らかに されていない。 [JLC]
<http://www.actionutilities.com/html/
nowutilities_press_release.html>
<http://db.tidbits.com/getbits.acgi?tbart=04931>
スピードと安定性を増す RAM Doubler 8 アップグレード -- Connectix 社は先週同社のメモリ最適化ツール、RAM Doubler のスピードと安定性を 高めるための無償アップグレードをリリースした。今回のリリースは、RAM Doubler 2.x ユーザーに対する RAM Doubler 8 への無償アップグレード （ TidBITS-439 “RAM Doubler 8 無償アップデート”を参照）に続くも のである。バージョン 8.0.1 は、古いバージョンの Finder から RAM Doubler コントロールパネルを使用した際にメモリ不足だと起る稀な問題 を解決し、大量のメモリを積んだ PowerPC ベース Mac でのアプリケーショ ン起動のスピードアップを図り、他のアプリケーションによって誤って書 き込み禁止になってしまいコンピュータがフリーズするという珍しい問題 をフィックスしてある。アップデータのダウンロードサイズは、390K であ る。 [JLC]
<http://db.tidbits.com/getbits.acgi?tbart=04992>
<http://www.connectix.com/html/rd__mac__update.html>
by Geoff Duncan <geoff@tidbits.com>
（翻訳：尾高 修一 <shu@pobox.com>）
（ ：亀岡 孝仁 <tkameoka@fujikura.co.jp>）
（ ：高島 均 <hitak@kk.iij4u.or.jp>）
もう 2 年近く前、私は TidBITS-347 に“バルクメール・ブルース”とい う記事で押し売りメール（“スパム”）にまつわる問題と、こういったメッ セージにどのように対応するかについて述べた。
<http://db.tidbits.com/getbits.acgi?tbart=00863>
この記事で述べたことは今日でも大部分がそのまま通用するが、時代が変 わったということも事実だ。スパムの数は増大の一途をたどっている。98 年 6 月 1 日以来、私は 800 通近くのスパムを受け取った。これは一日平 均 11 通強に相当する。しかも、スパマーたちは標的にできるメールサー バを求めて私のネットワークに侵入してくる。私のサーバたちはすべてロッ クしてあるのだが、たまにはダミーのサーバを動かしておいて、スパム行 為の試みがあった場合には発信元のネットワークにその旨通知する（と同 時に楽しげな笑い声を発する）ようにしている。私はワシントン州の反ス パム法の試金石となる訴訟にも TidBITS 原告団の一人として参加している。
<http://www.tidbits.com/anti-spam/>
慣れは大敵 -- 過去 2 年の間に、きちんとスパムを報告するということ をしないことが、スパム問題の深刻化を助長するのだと私は確信するよう になった。スパムを報告しないことにより、インターネットユーザーは暗 黙のうちにネットワークプロバイダに対して、そしてスパマーに対して “このメッセージは報告するほど迷惑ではない。したがって許容すること ができる”というメッセージを送っているのだ。もしインターネットユー ザーがスパムを防止したいと思ったら、スパムは 許すことができない のだという明確なメッセージを一貫して送り続ける必要がある。そのため にユーザーができることとして、法的・技術的解決を求めることと、スパ ムの事例を報告するという方法がある。
問題は、どのようにしてスパムを報告するかということだ。ほとんどのス パマーは足跡を消す努力をしている。無効な返信用アドレスを使ったり、 偽のヘッダを挿入したり、無防備なメールサーバを経由してメッセージを 送信したりする。それでもほとんどの場合は、どこにスパムの事例を報告 すべきかを突き止めることは可能だ。そのためには少々の知識が必要だが、 ほとんどのものがそうであるように、やればやるほど簡単にできるように なるものなのだ。
サーバの割り出し -- スパム事件を報告するには、まずどのインターネッ トサーバがメッセージを送ったかを突き止めなければならない。そのため にはメッセージの Received ヘッダを見る。返信用アドレスや From フィー ルドは簡単に偽造することができるので無視する。Received ヘッダは通常 メールメッセージの上の方にまとめてあり、特定の順番に並んでいる。一 番上が最後のもので、一番下が（理論的には）メッセージの発信元となっ ている。メールメッセージには最低でも一つは Received ヘッダがある。
一番下にある Received ヘッダは常に正確に発信元を示しているとは限ら ない。スパマーは Received ヘッダを偽造して追跡から逃れようとするの だが、すべての Received ヘッダを偽造することはできない。偽造された Received ヘッダは本来の Received ヘッダの下に現れ、通常は一目で分か るほど偽物らしいものだ。
唯一確実な方法は一番上の Received ヘッダから始め、下に向かうことだ。 あなたがメールを受け取るドメインにメッセージを送ったとする Received ヘッダを探そう。たとえば EarthLink のアカウントを使っていたら、 EarthLink のシステムが最初に現れるヘッダを探すことになる。以下は私 のネットワーク上にある箇所を指し示すヘッダの架空の例だ。
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
ご覧のように、smtp100.earthlink.net というシステムが“Fred”と称す るマシンからメッセージを受け取っている。この名前はおそらくスパマー がそう言わせているのだ。だが、EarthLink のメールサーバは黙って Fred の名乗りを信じるのではなく、DNS 検索を行い、Fred の本名が実は pointless.quibble.com であることを発見している。（すべてのインター ネット上にあるマシンは最低一つの IP 番号を持っている。マシンに名前 がある必要はなく、多数の名前を持つこともできるが、本名は一つだけ だ。）EarthLink のメールサーバは、メッセージの発信元を逆探知しやす いように Received ヘッダに pointless.quibble.com と IP 番号も挿入し てあるのだ。これは良いことだ。多くの責任あるインターネットプロバイ ダーのメールサーバはこのようにメッセージに印をつけてくれている。こ れでメッセージは quibble.com から EarthLink に来ており、そこが多分 スパムを報告する先になるということがわかった。ではもう少し複雑な例 を見てみよう。
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)
この例では、Fred と称するマシンが pointless.quibble.com と称するマ シンに接続され、しかもそれは Fred に関しては何らのチェックもしてい ない事がわかる。次に pointless.quibble.com は EarthLink に接続され、 そこではマシンの名前が確認されメッセージがあなた宛に伝達された事に なる。
この二番目の例は“リレー”の事例と言って良いだろう、ここではスパマー は quibble.com ドメインの中に悪用できるメールサーバを見つけたのであ る。とりわけこのサーバは、そもそもメッセージを送ってきたサーバが誰 であるかを確認しないので、スパマーの夢と言えるであろう。おおかた quibble.com の管理者はこのは関係は無いであろうし、自分たち のシステムがスパムを配信するのに利用されていると言うことにすら気づ いていないかも知れない。そうではあっても、あなたは quibble.com にこ の事件を報告し、彼らのサーバ上でのリレーを断にするよう強く求めたい と思うであろう。しかし残念ながら、これ以上スパマーを追跡するに十分 な情報は無い；できることなら、quibble.com のメールサーバがログを取っ ており、そこから管理者がスパムの親元にたどり着ける事を願うのみである。
もしあなたのメールが他のアドレスから転送されてきたならば、Received ヘッダの一番上の一行は、時としてはさらに数行、無視する必要があるか も知れない。例えば、<geoff@tidbits.com> 宛の全てのメールが quibble.com から私宛に転送されたとする。<geoff@tidbits.com> に対す るスパムの一番上の Received 行は、常に quibble.com はそのメッセージ を tidbits.com から受け取ったと表示している。しかし、TidBITS サーバ がそのスパムを生み出したのではない；どのマシンがそのメッセージを TidBITS サーバに送って来たのかを知るには Received ヘッダのそれ以下 の行を調べる必要がある。
IP 番号と範囲 -- 時としてよく作られたメールサーバであっても、そこ にメールメッセージをよこしたマシンの正当な名前を捜せないときがある。 Received ヘッダは次のように見える：
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
この事件を報告するためには、IP 番号 204.57.207.56 の責任者は誰であ るか見当をつける必要がある。まず、自分でそのナンバーに割り付けられ た名前があるかどうか調べるため DNS 検索を試してみたい。DNS 検索のた めには多くのユーティリティが出ている。Mac 用としては、10 ドルの Peter Lewis 氏の Mac TCP Watcher か 20 ドルの Peter Sichel 氏の IPNetMonitor を推薦したい、どちらも traceroute のためのツールもつい ている。
<http://www.stairways.com/mtcpw/>
<http://www.sustworks.com/~psichel/products/product_ipnm.html>
204.57.207.56 を検索する事で pointless.quibble.com が出てくるはずで あり、それはその様な事件は quibble.com に報告すべきである事を意味し ている。しかしながら、ここでは名前は見つからなかったと仮定しよう。 その場合、IP 番号の責任者を探すのに次に有効な手は Whois サーバを使 うことである。Whois プロトコルを使うことで、ネットワーク当局に対し て、ドメイン、システム、そしてインターネットサイトの連絡窓口に関す る情報を求めることができる。しかし残念ながら、インターネット全体の ためのネットワーク当局というのは存在しない。The American Registry for Internet Numbers (ARIN) は米国内で登録されているドメインについ て質の高い Whois データベースを保持している；私は常に ARIN を最初に 試してみることにしている。他のネットワーク当局には、InterNIC, RIPE (ヨーロッパドメイン), そして APNIC (アジア太平洋) などが含まれてい る。Allwhois.com の様なサービスもありそれ自身包括的であろうとしてい るが、それは IP 番号が誰に割り当てられているかを探し出すためよりも、 あるドメインが割り当て可能かどうかを調べるのにより役に立つ様にでき ている。
<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/>
ある IP 番号の責任者を特定するまでには、いくつかのネットワーク当局 に対して調査をかけねばならないかも知れない。アステリスクを使った IP 番号の範囲 (“204.57.207.*”) に対する検索の方が、検索結果を解釈す るのに注意しなければならないが、固有の IP 番号を探すより有効な場合 もある。Web 上では多重検索は常にぎくしゃくしがちである；データベー スに対して直接問い合わせのできる専用の Whois クライアントを使う手も ある。Mac 用としては、IPNetMonitor か Peter Lewis 氏の 10 ドルの Finger を試されたい、どちらも Whois サーバに問い合わせる事ができる。
<http://www.stairways.com/finger/>
もしあなたが適切な Whois サーバ経由で 204.57.207.56 か 204.57.207.* の検索をしたならば、私の上流の ISP である Northwest Nexus に行き着 くであろう。それで、もしあなたが Northwest Nexus に対して私のドメイ ンからのスパム事件を報告したとすると、私はあっと言う間にお叱りを受 けることになるであろう。しかしながら、全部のプロバイダーがこれ程責 任感にあふれているとは言いがたい；従って、もしあるドメインからある いは IP 番号から、数回報告した後でも、スパムが繰り返され様であれば、 Whois サーバを使って関係者の内で誰が上流にいるのか探し出す事ができ る、通常は AT&T, Sprint, UUNET, あるいは他の大手ネットワークプロバ イダーである。上位のネットワークプロバイダーのほとんどはスパムに対 しての許容度は低いが、現実にはこれらの苦情を彼らの顧客である地域 ISP に対して転送する程度のことしかできない。私の経験から言えば、スパム を上位のネットワークプロバイダーに上げることはそこそこに有効な程度 である。
誰が IP 番号を管理しているかを見つけるのに Whois が使えないのなら、 残された選択肢は traceroute ユーティリティとなる。traceroute は、本 来は 2 つのインターネットマシン間でやりとりされるパケットのパスを探 し出すためのものだ。このパスが、スパムが送り出された IP 番号にどの サイトが“最も近い”かを知らせてくれるはずだ。スパムメッセージの送 信元 IP 番号に“最も近い”と示されたドメインに対してスパム報告を送 ることができるだろう。ただし、インターネットのルーティングは動的で あることに注意して欲しい。つまり、2 マシン間の特定のパスは時々刻々 と変わることは通常ないにせよ、いつ何時でも 変わり得る のだ。目標 とする IP 番号に近いマシンであっても、スパマーやその IP 番号に責任 を持つ組織とは無関係であるかも知れないのだ。traceroute から得たデー タを使ってスパム事件を報告する場合には、礼儀正しくやろう。
スパム報告のやり方 -- スパム事件を報告するときには、受信したメッ セージの本文とヘッダを漏らさず含める。なぜなら、管理者にとって事件 の検証にこの情報が必要だからだ。丁寧でプロフェッショナルなメッセー ジは常に、辛辣な暴言よりはるかに効果的なのだ。私は報告の書き出しを 次のようなお決まりの文章にしている。
私は、次のような押し売りメール（“スパム”）を受け取りましたが、こ れは、貴殿のところのユーザーの誰かから直接送られたか、貴殿のサイト やネットワークのメールサーバを通して中継されたか、または貴殿の組織 が運営するダイヤルアッププールもしくは下流ネットワークから送られた ものです。以下にメッセージ全文を全てのヘッダととともに掲げます。こ のようなことが二度と起こらないよう願います。
ワシントン州に住んでいることから、私のメッセージはまたワシントン州 反スパム法に関する情報を指摘し、ワシントン州居住者への一事件当たり の損害試算について言及することとなる。
スパム報告は“postmaster”というユーザー名あてに送ろう。また、めぼ しをつけたドメインに“abuse”があればこのユーザー名がスパムに対して 責任を持つこともある。postmaster アドレスはほぼどんなドメインにも有 効である。一方、abuse アドレスはそれほど一般的ではないものの、しば しばスパム事件に対する報告先アドレスとして設定されているものだ。
最良の結果を得るため、スパム報告は、特定のマシンあてではなくドメイ ンあてに送ろう。上記の例でいうと、<postmaster@pointless.quibble.com> ではなく、<postmaster@quibble.com> を使うことになる。もし、スパム が、3 文字のトップレベルドメイン（例えば .com や .edu）ではなく 2 文字の国別コード（例えば .us）を用いたサイトから送られて来たのなら、 ドメインは 2 つ（quibble.com）ではなく少なくとも 3 つのパート （reno.nv.us）を含むこととなる。
抹消サービス -- スパムメッセージに列記される抹消サービスや、ある いは“一括抹消”リストと称するサイトについてはどうなのだろう? 2 年 前、私はこれらの抹消サービスを推薦し、（数は少ないが）ちゃんとした バルクメール業者ならリストから名前を削除するだろうし、いい加減な業 者であってもあなたのアドレスを保持するだけだから、試しても害はない とした。
今日、私はいかなる抹消サービスをもお薦めしない。もちろんごく僅かに ちゃんとしたところもあるのだが、ほとんど全部は実際には存在しないか、 あるいは単なるアドレス収集の隠れ家なのだ。私が追跡した一例によると、 いくつかのスパマーによって巧妙な操作が行われていて、抹消リクエスト を集めては他のスパマーにその送信者のアドレスを“捕れたてのアドレス” として売却していることが判明したのだ。
単に鵜呑みにはするな -- スパムにまつわる問題についてはよく論争の 的となる。この記事には技術的な情報やチップスを載せているが、最終的 には単なる私の意見に過ぎない。スパム対処に関する他の意見、現在の立 法上や技術上における発議など、さらにもっと学びたければ、Adam が TidBITS の反スパム訴訟のために集めたリンクのいくつかを手始めとすれ ばよいだろう。
<http://www.tidbits.com/anti-spam/spam-info.html>
ここで概括したテクニックがメールボックスへのスパム流入を防げるだろ うか? 答えはノーだ。スパム報告は簡単だろうか? これもノーだ。けれど も、少なくともスパムを適切に報告しない限り、そこには自分がよければ よしとする自己満足しかない。スパマーを締め出したプロバイダーからあ なたの報告に対し謝辞が送られたなら、きっと満足感が得られることだろ う。プロバイダーのみならず、たくさんの人々からも感謝されることにな るのだから。
by Adam C. Engst <ace@tidbits.com>
（翻訳：尾高 修一 <shu@pobox.com>）
（ ：尾高 里華子 <rikako@pobox.com>）
私が最近バックアップやセキュリティなど TidBITS で力説していたことの 重要性を示す事件についてお伝えしよう。
週末のお出かけ -- 2 週間前の土曜日の朝、Tonya と私は週末を友達た ちと過ごすため支度をしていた。私は夕食用のインド料理の仕上げをしな がら“キッチン Mac”、つまり Ethernet でネットワークとインターネッ トに接続された PowerBook 5300 で天気予報をチェックしていた。突然、 PowerBook がビープ音を発し、Retrospect Client のダイアログを表示し た。ここしばらくバックアップをしていないというのだ。バックアップ用 Mac の Centris 660AV に Timbuktu 経由で接続しようとしたところ、マシ ンがクラッシュしていることがわかったので、下の階に降りてリスタート をかけた。しばらくしてもう一度様子をチェックしてみた。悪しくもクラッ シュのせいで Retrospect のカタログファイルが壊れていたため、 Retrospect は作業に入る前にファイルの検証をしたいと申し出た。そこで 私は Retrospect にファイルの検証をさせたが、Retrospect のログによる とテープドライブのヘッドクリーニングが必要だという。ぶつぶつと宇宙 の法則を呪いながら、私はクリーニングテープをドライブに入れ、バック アップテープを入れ直し、再び検証作業を開始した。このころには Tonya は「もうとっくに出発してなければいけないのにまだコンピュータなんか いじって ... 」という顔をしていたので、検証作業をそのまま続行させ、 PowerBook を閉じ、戸締まりをし、家を出た。
週末そのものは各種ウォータースポーツと効かない日焼け止めのために負っ た過度の日焼けに満ちていた。Macintosh とは比較的縁が無く、友達の息 子が使っている PowerBook 165 のトラブルシューティングを少々した程度 だった。その子は音声合成と頭にセットしたスイッチを使って痛々しいほ どゆっくりとタイプし、外界と交信するのだ（彼は脳性麻痺を病んでいて 話すこともできず、車椅子生活を強いられている）。日曜日の夜には帰宅 の途中に Geoff Duncan と食事をしたが、その時彼から我が家の 56K フ レームリレー接続がダウンしていることを聞いた。これはあまりないこと なので、彼の家からチェックしたところ、ルータは ping に応答したが、 ネットワーク上にある他のマシンからの応答はなかった。これは変だ。
帰宅 -- 謎は帰宅と同時に氷解した。ドアの鍵が開いていて、キッチン の床には PowerBook 5300 が置いてあった箱が散乱しており、10-Base2 Ethernet ケーブルが壁から抜かれていた。PowerBook の姿はなかった。調 べたところ他のコンピュータはすべて無事で、家の裏手の窓ガラスが一枚 割れていた以外、荒らされた形跡はなかった。
何が起きたかを少しずつ再構成してみると、多分犯人はドアベルを鳴らし て明かりがつかないことを確認し（もう一台の車は置いてあったので、私 たちが在宅していたこともありえる）、犯行に及んだのだろう。キッチン の窓から覗き、PowerBook と窓に貼られた警備会社のステッカーを見て、 手早くことを済ませようと思ったのだろう。犯人は裏手に回り、警備会社 のステッカーのない窓を選び、ガラスを割り、キッチンへと直行した（途 中 Tonya の Mac は素通りして）。犯人は PowerBook とケーブル類をつか み、PowerBook の下の引き出しから何年も前に Tonya が私にくれた木製の 切手入れ持ち去った（だが、中の切手は取っていかなかった）。用事が済 んだ犯人はドアの鍵を開けて逃走した。
犯行が行われたのは日曜日の午前 1 時 45 分だった。犯人が PowerBook を Ethernet ネットワークから外そうとし、ネットワークがダウンしたの がちょうど 1 時 48 分だったのだ。これでルータが ping に反応したの に、他のマシンが外部から見えなかった訳がわかった。その後、警察が来 て、調書を取り、質屋に PowerBook が現れないか目を配っておくと言っ た。翌日、保険金の支払い手続きを開始し、今のところ順調に進んでいる。 1,000 ドルは免責となるが、5300 のかわりに PowerBook G3 が買えること にはなるだろう。
バックアップの教訓 -- 気を取り直してネットワークのセットアップを 行い、再度バックアップの様子を見た。Retrospect の検証作業は終了して いたが、そのかわり土曜日の夜のバックアップは行われていなかった。検 証完了のダイアログを閉じてバックアップサーバを起動したところ、 Retrospect がテープの異常を訴えた。つまるところ、このテープからある 程度はデータを回復することはできるかもしれないが、どの程度かはやっ てみないとわからない。
ここで私が数回にわたって書いてきたバックアップの記事を思い出してい ただこう。この事件は現実にどんなことが起きえるか、そして起きたかを 物語っている。
<http://db.tidbits.com/getbits.acgi?tbser=1041>
セキュリティを考える -- 今回のような状況に出会うと、心はとたんに セキュリティのことやその対策への後悔で占められてしまう。私の現実的 な考えを少々述べよう（従って屋根に銃の自動発射装置を設けるなどの話 はしない）。
<http://db.tidbits.com/getbits.acgi?tbart=05020>
<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/>
この話題について今まであまり考えたことがなかったので、TidBITS Talk で議論したいと思う。（Connectix QuickCam と DigitalRadar を使ったも のなど）Mac を利用したセキュリティシステムを採用している方は、その 話を < tidbits-talk@tidbits.com> 宛に送っていただきたい。その中から 優れたものをポストしようと思う。TidBITS Talk への登録は、下の 2 番 目の URL から行うことができる。
<http://www.connectix.com/html/digitalradar.html>
<http://www.tidbits.com/about/tidbits-talk.html>
PowerBook 盗難登録 -- O'Grady の PowerPage で行っている新しいサー ビスを発見した。O'Grady の Stolen PowerBook Registry は盗難にあった PowerBook のシリアル番号を登録しておくデーターベースで、これを使っ て購入しようと思っている PowerBook が盗品であるかどうかをチェックで きるようになっている。私は盗まれた PowerBook の登録を済ませた。ま た、PowerBook の盗難にあった方にはぜひ登録していただきたいと思う。
<http://celebs.ogrady.com/larceny/>
ラップトップマシンは高価で小さいという理由からますます標的にされや すくなっている。ラップトップの 14 台に 1 台は盗品であるという数字を 見たことがあるし、Safeware Insurance 社は最近 1997 年中に盗まれたと 申告のあったラップトップは約 31 万台で金額にして 10 億ドル分の補償 額になり、この数字は 1996 年の 28 % 増だとの報告を行った。我が家に 入った泥棒が他のものをほとんど盗んでいないことからしても、泥棒にとっ てラップトップがどれだけ魅力のあるものかは明白である。保険会社の人 の話によると皮肉なことに Mac は PC よりもはるかによく盗まれるそうで ある。泥棒は我々が思っている以上に目が利くのであろう。終わりに、今 回の話の教訓はできる限りの対策は講じるべきであるということだが、あ くまでも自分の持ち物から一瞬たりとも離れることができないような妄想 に取りつかれない程度に。
非営利、非商用の出版物およびウェブサイトは、フルクレジットを明記すれば記事を転載またはウェブページにリンクすることが できます。それ以外の場合はお問い合わせ下さい。記事が正確であることの保証はありませ ん。書名、製品名および会社名は、それぞれ該当する権利者の登録商標または権利です。TidBITS ISSN 1090-7017
｜ 
｜ 