ユーザーからみれば、うごいてあたりまえ

　DNSの移行も順調に進み、メールの転送も検証結果は上々。菅井も追加でテストプロトコルを検証。満を持していよいよ10月1日を迎えた。

　実際には説明会以降、なし崩し的にスタートが切られていたみたいなもので、今朝から何かが始まる、という感じではない。が、そう思っているのも束の間、すぐに電話がなった。

「国際部の荒川だけど、メールが届かないんだけど」

　来たか、と牛尾は「ちょっと行って来ます、国際部です」と言い残し、荒川の元に向かう。

　国際部では荒川がイライラしながら待っている。

「よぉ、今日からこっちになるんだろ？メール届かないと困るじゃないか、業務に支障が出てるんだよ。早くなんとかしろよ」

　みな、二言目には『業務に支障』という。これを言えば全てが正当化されるみたいに。

　荒川の端末は、事前設定が済んでいて、事前の動作確認もされている。

「メールが届かない、というのはどういう状況でしょうか？」

「お客様から、今日の資料を送ったけど、届いたか、という確認の電話があったんだよ。でも、そんなメールは届いてない。どうなってるんだ？」

「すみません、ちょっと確認させていただきます」

　牛尾は、その場でサーバのログを確認する。残念ながら、該当するメールは届いていない。

「差し支えなければ、そのお客様に、確認をさせていただけますと、助かるのですが。。」

「そんなこと出来るわけないだろうが。失礼だろうが！」

　うーん、困った。状況を確認しなければ、解法もわからない。が、しかし、少なくとも、こちらの設定ではない。

「今までは藤留のメールで問題なんかおこってなかったんだぞ」

　と荒川は後ろから怒鳴る。

「まだ藤留メールは移行期間で使えますので、そちらに送ってもらうようにお願いしていただけませんでしょうか？その時にできれば、新しいアドレスもCCしてもらって、、、」

「もう頼んでいるよ、そうじゃなきゃ仕事になんねぇだろが。もう頼んじゃったからよ、いまから、新しいアドレスとかどうとか、頼めねぇよ」

　残念、チャンスが一つ減ったけど、牛尾はそれでも

「そのメール、拝見させていただけませんか？」

　とお願いした。

　運良く、エラーメールを転送してくれていたので、ヘッダーはわからないが、エラーの状況を知ることができた。荒川のメールアドレスが間違えている。

　　　taiga_arakawa@yasuiwa.example.com

　であるべきところを、

　　　taiga-arakawa@yasuiwa.example.com

　と、アンダースコアがハイフンになっていた。

　うーん、こういうトラブルは、これからも山ほど続くんだろうなぁ、、、とため息をつきながら、全体アナウンスを電子掲示板に掲載することにした。

　説明会での話題、「アカウント間違いでのセキュリティー」の話が思い出された。実際には今回はエラーで済んだが、アカウントが氏名ベースで決められているので、同姓同名の社員が何人かいるアカウントの場合は、誤配のリスクは常に考えなければならないので、正しくメールアドレスを伝える重要性を、特に間違えやすいのが、ハイフンとアンダースコア、ここをどのように伝えるのかが鍵となる。

　ただ、もう一つ。免罪符のように使われる「業務に支障が出る」。これは今一度理解してもらわないとならないかもしれない。これもアナウンスには反映させよう。

　大小のトラブルでの電話は、１週間はなり続く。派遣も頼み、５人体制でサポートにあたるが、ほとんどずっと皆が出ずっぱりが続いた。ほとんどが、利用方法の間違いが原因。なので、時間が解決してくれる。

　半年後、珍しいケースが発生した。

「携帯のアドレスに届かないんだけど」

　この携帯サイトは、サイズが256kB制限があり、まずこれが原因だろうと思うが、そうではなかった。

「これみてみ、テストメール、アドレスも間違ってないだろ？」

　と、Infochangeクライアントからの送信画面と、携帯のプロファイルを表示してある。しかし確かにエラーが出ている。

　エラーは「不正なアドレス」。

　よく見る、と、、、携帯アドレスのアカウントがピリオドで終わっている。

　izumi.@mkk.example.com

「ちょ、、、なんでアットマークの前にピリオド入れたんですか？」

「携帯メールアドレスって、迷惑メールが多くなるので、ピリオドを入れる、とかが推奨されたりしてたんで、それに従っただけなんですけど。。」

　うーん、これは困りました。

「厳密に申し上げると、このアカウント名は不正です。ピリオドは使用可なのですが、後ろにつけてはいけません。なので、正しくRFCを実装したメールサーバでは、このアドレス向けのメールは、間違いと判断して受け付けないようになっているんです。申し訳ないですが、届かないのが正しいんです。

　今回に限らず、これは今後のこともあるので、きちんとしたアカウント名に変更した方が良いですよ」一事が万事。あれだけの大手キャリアでも、RFC通りに実装しないということがあり得る、ということが、かなりショックであった。

「インターネットは相互信頼で成り立っていること」「RFCで決められたルールは必ずしも守られているわけではない」「それが元で通信が失敗することもある」という説明をした説明会を思い出していた。どれだけこれが浸透したかはわからない。おそらくはほとんどのユーザの頭には残っていないだろう。しかし、本当にこういうことが、、、おこるんだと、、、

　同じ頃、謎に包まれたトラブル報告があった。

　メールが返信できない、というもの。

　普通に「全員返信」を選んでいるのだが、なぜかエラーが出る。

　実際に、その現象を見せてもらいに行く。

　確かに、全員送信で送ろうとすると、エラーが出る。

　まず、差出人だけに返信すると、OK。全員返信だとエラー。その宛先の数が多い。減らして見ると、、、送信できた。

　となると、、、やはり宛先数か。それにしても、宛先数制限はあまり聞いたことがない、と思いながらも、メール送信の実際のセッションをインターセプトして、中身を見てみて驚いた。

　なんと、全員返信で発生するSMTPヘッダ、ひたすら宛先を改行せず繋いで、1500文字に達していることがわかった。まさか、、、Infochangeが、RFCの決め事（1000文字）をスルーしているとは、、、思わなかった。とはいえ、InfochangeはIPアドレス配信での実装もちょっと、、、というところがあったりとかあるんで、あまり特殊な使い方を避けるしかない、ということだろう。この状況も、全体に掲示板アナウンスを行った。

　それにしても、状況としては、ヘッダ行のバッファ1000文字に対するオーバーフローだなぁ、バッファオーバーフローというと、ちょっと穏やかではないけど、まぁ、それほど大きな問題ではないだろう、と言える。それよりも、そういう上限をきちんと意識し、それを踏まえて実装することで、ウイルスの入り込む余地を一つ潰すことができる、つまり、「制限事項があるのは安全を確保するため」ということをユーザにもっと理解してほしい。

　実際に、その頃、本当のバッファオーバーフローを使うウイルスが、とうとうやってきたのだった。