ANALOG DAEMON

いよいよ

むやみに怖がるな。正しく怖がれ。命まで取られるわけじゃない。検証は十分、自信を持って！

　サーバは23日に受領できたので、運用環境が27日にはととのっていた。あとはNIC登録変更。28日朝、確認するも、まだ変更になっていない。うーん。外川が受話器をあげる。

「呉か？外川だ、どうなってるんだ？え？、、、ごちゃごちゃいうな、コーポレートディシジョンだといってるだろう。わかったな！」

　USの担当者、呉の答えを待たずに切る。そのまま引き続き別番号ダイヤルする。

「もしもし、ご無沙汰しています。社長はYICのロードマップはお聞きになってますよね？はい、はいそうです。つきましては、今日、貴地担当に、登録変更をお願いしてますので、くれぐれもよろしくお願いします」

　うわー、現法の社長に直電かぁ、すごいな、、、まぁ、これでうごきだすだろう。。

　昼頃に、US担当からメールが入る。

「しってるだろ、USはもう、安定に動いているんだ。業務命令ということで、DNSの登録変更はすすめるけどな、もしメールが届かないようなことが起こったら、ただじゃおかないから覚えておけよ」

　・・・ふぅ。まぁ、あれだけ反発してたんだから、しょうがないかな。

　まずはとにかく、いつ変更されても良いように、、、プライマリとセカンダリを立ち上げておく。レコードは、まず、現在のUSの設定をそのままコピーしたもの。

　メール（MXレコード）と、Web（こちらは普通にAレコード）は、いじらずそのまま。

　ただし、現在のキャッシュが１週間なのを、３時間に変更しておく。

　本当は、ちょっとずつ落としてく方が良いのだろうけど、まあいいや。もともとそんなにトラフィックが多いわけではない。

　で、それ以外に、本番環境検証用に、yasuiwa.example.netを用意した。

　当面はそちらで、ドットコム本運用までのメールリレーとかの検証を行うことにしている。

　翌々日29日、digしてみる[注9]。うん、、、正しく日本のサイトを向いていた！いよいよ動き出したな。。牛尾は実感を噛み締めた。同時に、一抹の不安も感じながら。

　まずは、DNSレコードは維持なので、サーバが落ちなければ１週間は何も起こるはずがない。

　それでも、各環境、自分のネット、ダイアルアップでのプロバイダ環境、様々な環境で digして、名前が解決されていること、DNSがどちらのレコードがキャッシュされているかを確認した。29日は、ほぼ1日、こればかりやっていた。そこまでやらなくても良さそうなものであるが。。。気になってしょうがない。

　さて、10月に向けてまだ１ヶ月ある。かなり余裕を持って動かせそうで、ちょっと安堵を感じ始めていた。当初は、最悪、DNS移行の１週間で決着を、も覚悟していただけに。

　さて、メールの環境は、一部はInfochangeというグループウェア。それ以外は、sendmail。

　まず、Infochangeの設定を行う。

　今回、専用のサーバは別予算で本当に良かった、と思いながら、メールサーバは、サーバ専用で購入。一方で、、sendmailも、多くの人のメールボックスに加え、他拠点へのメールの転送を担うため、きちんとした冗長性を確保したサーバ仕様のPCが確保できた。

　これらの設定をまず行う。

　Infochangeは特に問題なく、イントラネットという感じで、普通にインストールするだけですぐに使える状況になる。イントラ仕様なので、インターネットからリーチャブルな場合に考慮すべきセキュリティは、今回は目を瞑る。

　それよりも、

　インターネットとの出入りを管理するサーバと

　入りのメールを各拠点にさばくサーバ

　の設定が心配である。

　まず、前者、出入り管理のサーバの設定。これは、受けても良いかの確認だけで、内側のサーバに渡すだけなので、それほど面倒ではない。

　不正リレーが出来ない設定を確認、さらに、ブラックリストからのメールは受け取らない設定の確認も行う。順調順調。いいぞ。

　次に、内部での転送動作。

　Infochangeと、USのBooks環境での連携は、経験もないし、ライセンスも持っていないので検証環境も持てない。ある意味ぶっつけ本番だが、幸い、外川のBooksのアカウントがいきている。Infochangeは10月までは試験運用ができる。

　で、動作自体は、InfochangeにBooksエミュレーションモジュールをいれて、Booksアカウントを統合し、そちらのメールボックスに転送できる設定にした。ドットコムは、まだUS向けで検証にならないが、ドットネットでうけとって、ドットコムに書き換えてInfochangeに渡して動作検証をかけることにした。

　慎重に慎重に。。。

　ドットネットがドットコムへの書き換えは、sendmailの設定で動作が確認できた。

　あとは、Booksとの連携だけ。

　9月1日。外川の机のところで、

「では試験してみます。よろしくお願いします」

　と断り、ドットネットあて、togawa@yasuiwa.example.netにインターネットの牛尾プライベートアカウントから送ってみる。

　祈るような気持ちでメールを送る。

　5秒後。外川がこちらを見て、ニヤリと笑う。

「届いたぞ」

　・・・ふぅ、よかった。だがまだ、安心はできない。

「ありがとうございます。動作確認が必要なので、すみません、生データをいただきたいので、作業をさせてください」

　外川のPCから、送信の生データログを取るため、コマンドプロンプトから、telnetでポート110に接続し、メールボックスの検証メールをインターネットメールフォーマットで落とす。ヘッダの状況をみる。転送状況。すばらしい。きちんと動作がされていることが確認できた[注10]。

　よし、と、ここで初めて胸をなでおろした。

　あとは、10月1日を待つばかりか。

　でも、あまりにうまく行き過ぎている。本当にテストのプロトコルに穴は無いのか。

　牛尾は菅井に、もう一回プロトコルに穴が無いか、ダブルチェックをお願いした。牛尾は、テストでは、1発で成功した経験がない。検証では、うまく行くべきものだけでなく、エラーハンドリングが適正か、の確認が必須、むしろそちらの方が厚く用意しなければ。ソフト開発で言うアルファテスト。意外と多くの目で見ると粗が見つかるものだ。1発成功は、その検証に穴がある可能性が高いと牛尾は考えたのだ。

　さて、正式な稼働前に、クライアントの設定と、説明会が必要だ、、、

　すでにInfochangeのクライアントを、POPクライアントとして使っている人が多くいるので、その意味では、それほど障壁はなかろう、と予想していた。

　まずは、Infochangeのアカウントを供与するユーザに、クライアントソフトのインストールをして周り、説明会の予定を立てた。インストールは9月中に終われば良い。まずは説明会の予定を立ててアナウンスした。

　説明会1回目。

　人間のサガというものは、面白い。プライドというものが強く影響していると思われるが、コンピュータについていえば、「教えて君」と「教える君」に見事に分かれる。それでも、まだ教えて君の方はかわいいものだ。「自分で調べろよ」ということまで聞かれて辟易とはするけど、自分はわからないんだ、と自覚してるだけよい。一番困るのは「教える君」。自分は一番よくわかってるんだ、という根拠のない自信で、あちこちを荒らしまくっているのはこういう人たち。

　大抵、仕様も知らずに、試行錯誤して、うまく行くとそれが全てになってしまう。理論的な考察なんてどこにも無いので、そう言う人を納得させるのは容易では無い。

　第一回説明会で、「自称パワーユーザ」斎藤が早速噛み付く。

「インターネットに常時接続なんですよね？セキュリティーは大丈夫なんでしょうね？万が一にも、私のPCのデータがぬかれる、なんてことがないようにしてくださいね。しっかり常時監視するんでしょうね。そうでなければ常時接続なんてやるべきじゃないですよ」

　はぁ〜。のっけからきたか、、外川がいなくて良かった、と変なところで胸をなでおろしながら

「斎藤さん、ご意見ありがとうございます。セキュリティーには十分注意します。どのような点がご不安なんでしょうか？」

　斎藤が、我が意を得たり、という顔で

「そんなこともわかんないの？いい？インターネットって世界中どこからでも接続できるんだよ。常時接続ってことは、世界中から、私のPCが見えるってことなんだよ。もちろん自分でも気をつけるけどさ、それってあんたらが常時接続にしなければ心配いらないところなんだよなぁ」

「斎藤さん、普段Webブラウザ、使われてますか？」

「当たり前だろう、一番使いこなしている方だと思うぞ」

「どのように接続していますか？」

「何言ってんだ、会社の正規のアカウントでダイアルアップで接続してるに決まってるだろ。。」牛尾は、追い込んでしまって良いものか迷ったが、ここは客観性を確保したまま、事実を伝えるべきと判断した。

「ダイアルアップですね、、、そのときって、世界中から見えていないんですか？すごいですね、どういう方法なんですか？是非教えてください」

「・・・」

　斎藤は、意味がわからず無言のままなので、牛尾が続けて

「今の会社のダイアルアップの仕組みは、つどつどグローバルアドレスが割り振られる、という仕様になっています。つまり、ダイアルアップの間はどこからでも見えるはずなんですが、見えなくすることができると素晴らしいと思います、是非教えてください」

　斎藤はちょっと赤みがさした顔で

「ダイアルアップだぞ。インターネットに接続しているサービスプロバイダとの間で電話でやりとりしてるだけなんだから、自分のPCが世界中から見えるわけないだろうが」

「じゃ、ちょっとやって見ていただけますか？」

　斎藤はPCをもってきていた。モデムは内蔵。会議室の電話線を繋いでもらう。

　牛尾は

「コマンドプロンプトから、インターフェースの状況をみてください」

　斎藤はわからないようなので、牛尾は

「ちょっとよろしいですか」

　とキーボードを触る。そして、PPPインターフェースに、グローバルアドレスが割り振られていることを確認して、

「このPPPというのがダイアルアップです。ここにはグローバルアドレスが振られていますね。そして、このアドレスへのトレースしてみると、このPCが世界中から見えていることが確認できますね」

　斎藤は納得いかず

「そんなことはないっ！」

　と言い張るので、牛尾はやむなく、自分のPCをもってきて、斎藤のPPPのアドレスを指し

「私のPCは、インターネットに繋がっています。で、こちらご覧ください。ほら、斎藤さんのHDDのファイルリストが、、、でていますね。インターネット経由ですよ」

　斎藤は、顔を真っ赤にして

「もういいっ、とにかく俺のデータを危険に晒すなよ！」

　と捨て台詞を吐いて部屋を出ていった。

　牛尾は残った参加者に向かって、落ち着いた話し方を意識しながら

「みなさん、インターネット接続が危険だと思われている方はいらっしゃいますか？」

　と聞いてみた。２０人程度のうち、ぱらぱらと３−４人の手が上がる。

「では、手を挙げてらっしゃる方にお伺いします、今回の常時接続で、その危険が顕在化するとお考えでしょうか？」

　なんとなく手が下がってくる。是非よりも、わからない、という事のようだ。

　牛尾はゆっくりと頷いて、続けた。

「みなさんが専門的なことを理解いただく必要はありません。ただ、信頼できる担当者に任せる、でかまわないのです。では、信頼できる担当者はどういう人か？色々な考えがあるでしょうけど、私は次のように考えます。きちんとリスク分析ができること。そのためには、可能性があるリスクを理解し、正しく評価し、対策を立てる事です」

　反応が鈍い、わかりにくいのか、でもこれだけは言っておかないと、と考え続ける。

「インターネットに繋がなければ、インターネットにデータは漏れない、は、正しいかもしれません。しかし、一方で、外部とのデータのやり取りはどうされますか？FAXを使えば安全でしょうか？電話帳機能で、一つずらしてしまうミスって、意外と多いんです。悪意を持って横から覗き見る事だって出来ます。まぁ、それは本気で悪意を持っての事となりますが。インターネットは匿名性高く侵入しやすいかもしれませんが、先ほど申し上げた通り、実は皆さん、知らず知らずのうちにご自身のPCをインターネットにさらしていた、というご認識はなかったのではないでしょうか？一時、猛威をふるったウイルスがあります。ネットワーク経由で感染するのですが、私の検証環境で試したら、ダイアルアップした瞬間に感染しました。誇張もなく本当です。ログを取ろうと思いましたが、そんな必要もない、瞬時の出来事でした」

　やはり反応が鈍いが、もう一息、最後のポイントにはいる。

「専用線接続をする場合、インターネットとの境界にファイアーウォールを置きます。これはアドレス枯渇問題解決という意味もありますが、何よりも、これで外部から皆さんのPCを直接は見えなくしてくれます。さらに、おかしな動作を監視できますので、何かあっても被害を最小限に食い止められます。申し上げたいのは、リスクは何か？を正しく理解し、正しく怖がる事です。正しく怖がる、というのは、むやみに怖がる、ということではありません。怖がる、という感覚はとても大事です。これが、安全を確保するドライビングフォースになります。今日の話題で言えば、インターネットに接続する事で世界中から見えてしまうのはどういう状態か、を理解すれば、ダイアルアップより専用線の方が、安全だとお判り頂けるのではないでしょうか。もちろんそれだけではありませんけども。。。ただ、お願いしたいのは、情報システム部はきちんとリスク分析をし、むやみに怖がるのではなく正しく対応するよう努力している、ということを、ご理解ください。一方で、ではファイアーウォールがあれば安心、ではありません。フィッシングなど、危険なサイトに誘導されれば、どんなにファイアーウォールの後ろだって丸裸です。常に、安全を意識した行動をいただくことを是非、意識してください。『これ、クリックして大丈夫かな』、と、一呼吸おく、などです」

　会場は静まり返っている。やはり反応は鈍い。この辺は辛抱強く行くしかない。

「今日明日で、全て理解する必要はありません。ちょっと横道にそれてしまいました、申し訳ありません。今日の目的は、新しいメール環境のごせつめいですので、、、」

　思わぬ脱線となったが、今後の説明会でも、正しく怖がる事をきちんと伝えるべきと認識した。

「メールがどのように届くのか、という詳細を知る必要はありません。しかし、必ずご理解いただきたいのは、インターネットというのは、確実なツールではない、という点です。RFCという、必要最低限な決め事がありますが、その実装方法は、各プログラマに委ねられている、ということです。なもので、色々な環境が百花繚乱。どれも素晴らしいソフトなんですが、残念ながら相性の問題で不具合が起こったりもしますし、場合によっては届かないこともあります。設定も、各設定サイトの任意ですから、例えば、大きな添付ファイルを送っても受け取れないこともあります。

　今回は、文字コードはJISにしていただくこと、署名はできるだけシンプルに、できるなら２行程度に収めていただく方が良いと思います。これは各自自由に変更できてしまう部分ですし、ルールというよりガイドラインですね。その他、添付ファイルは5MBを超えないように。これはサーバ側で対応しますので、すみませんが、大きな添付ファイルを送られた場合はサーバで弾かれることをご理解ください」

　それまで静かだった会場から、ようやく、質問の手が上がった。

「5Mとは随分小さいように思うんですが、なぜ5Mなのですか？そして、越えるとどうなりますか？」

　牛尾は答える。

「そうですか、5Mは小さいでしょうか。。。意外とそんなに大きなファイルは添付されないと思います。今までダイアルアップでお使いになられてましたよね？それで5M以上のファイルって送られていましたか？もう一度ちょっと考えてみていただければ、と思います。先ほどお話ししたRFCで、1855には、実はネチケットがまとめられています。そこでは1M程度とされていたりして、以上を鑑みますと、5Mあれば当面は十分だろう、との判断をさせていただいたわけです。

　超えた場合は、エラーメールが帰ってきますから、送れなかったことが分かります」

　別の声が上がった。

「どうしても大きなファイルを送らないとならないときは、どうしたらいい？お客様の要請されるファイルで10M超えるときがあるんだけど」

　一瞬考えた後、牛尾は答えた。

「実際にどうしても送らねばならない時は、おっしゃってください。こちらで対応いたします。先方の環境次第ではありますが、分割ファイルにすることで、例えば10Mなら２分割すれば5Mが二つになりますので、各々送ることができます。

　ただし、それを元に戻すには、受け取られる方の環境に依存します。これが先ほど申し上げたとおり、百花繚乱、という部分です。お客様のメールソフトが何か、を調査し、その上でそれに対応した分割方法をとらせていただきます。つまり、臨機応変、発生都度の対応をさせていただきますので、都度ご相談ください」

　まぁ、実際にそこまでのケースはないだろうと思い、まずは、案件ごと相談とした。予想通り、この相談が来ることはなかった。しかし、、、やはり簡単には話はいかないものですね、、

　テストがスムーズに行った代わりに、こちらが一悶着。。。