Scribble at 2020-09-30 07:56:58 Last modified: 2020-09-30 08:04:17

或るサイトで、ここ最近になってメールが二重に送信されているといいう問題が起きていたらしく、何度かサイトの運用をしているディレクターから相談を受けていたのだが、まずメールのヘッダー情報もメール・サーバのログも見せてくれないため、はっきり言って具体的で有効な返事はしていなかった。記録が何もない状態で、あり得る原因を僕の経験からあれこれと推定して見せたところで、そんなものは当てずっぽうにすぎない。

ようやく半年以上は経過してから、メールのヘッダー情報をもらったというので、ディレクターに見せてもらった。すると、SPF として設定されている Google のメール・サーバとか From 行に記載する某社の FQDN とかではない、全く別のドメインがヘッダー情報に記載されている。それは、Message-ID だ。もちろん、RFC をご存じの方は別にそんなことで驚いたりしないだろう。なぜなら、規格上では Message-ID に何をどう記載しても構わないからである。つまり、最低限の要求事項としては、文字列が送信メールごとにユニークであればいい。すると Message-ID の一意性(もちろん世界中のメール・サーバで配信される別のメールに対しても Message-ID が重複してはいけない)を保証する最も簡単な方法は、インターネット通信経路上で一意性をもつ文字列、つまりサーバの FQDN を Message-ID に含めて、そのうえで追加する文字列を自前でユニークとなるように管理すればいいということになる。Message-ID の多くがメールアドレスのような書式になっているのは、これが理由だ。「a2payvsyf6czaklw@philsci.info」といった Message-ID で、@ マークよりも前の "a2payvsyf6czaklw" という文字列の一意性だけ自力で管理して出力できれば、@philsci.info という文字列は自分のメール・サーバだけが使えるので、この文字列の組み合わせはネット上でユニークだと《言い張れる》(もちろん、他人が philsci.info という文字列を勝手に使う可能性があるので、厳密には一意性が保証されたことにはならない。みんなが同じルールに従えば一意性が establish されると言い張っているにすぎない)。

ということで、Message-ID には知らないホスト名が記載されていた。@hal456.net となっているため、これは何だろうとブラウザでアクセスしてみたら、驚いたことに PHP でメール送信のライブラリを公開しているサイトだった。しかも、12年前に開発が止まっている。開発元というか開発した人も素性がよくわからないし、個人のブログも同じ頃に更新が止まっているので、既にプログラミングそのものも止めてしまっている可能性がある。学生、あるいは《そこそこ年季の入った》エンジニアなどが勢いで作ったり運営していたサイトというのは、得てして就職とか転職とか、あるいは結婚したとか子供が生まれたといった色々な機会に更新が止まったり、公開しているプログラムの開発が止まったりする。もちろん、人はたかだか一個のソフトウェアのために人生を歩んでいるわけではない(という人が大半だ)から、それはそれで自然なことだし仕方のないことではある。しかし、そういうものを放置して使える状態にされては困るので、この開発者がサイト上でコードを既に非公開としていたのは見識として正しいと思う。敢えて言うが、これは些細なことだがエンジニアとして称賛するべきだ。

問題は、12年前に開発が止まっているライブラリを現在も使い続けていることにあるのだろう。対応しているのは PHP 5.2.x だから既にレンタル・サーバですらサポートしていないような古いバージョンの PHP である。逆に言うと、これを動かせていたウェブ・サーバの仕様だって相当に古いままの可能性がある(CentOS 4、あるいは CentOS 5 の出始めとか)。よって、僕の見立てとしてはメールの送信だけの小さな問題ではなく、これはサーバなり OS のライフサイクルから見直した方がいいと思う。アマチュアの書いた PHP のコードを書き直すていどの対処療法では済まない巨大な脆弱性が放置されている恐れが高い。

さて、こういう場合に困るのが、いわゆるウェブ制作会社だとサーバの構築からプログラミングやコーディング、そして情報セキュリティ監査まで対応できるところがなかなかないということだ。もちろん「できます」とコーポレート・サイトに記載している制作会社はたくさんあるし、それどころフリーランサーですら「ワンストップ」などと平気で書くわけだが、実際にはプロの仕事として任せられる会社なんて大阪でも 100 社に1社あるかどうかだ。フリーランサーで(その人物が単独で作業するわけではないとしても)任せられる人などは、1,000人に1人くらいいたら良いし、これは海外で仕事をしようと思っている人にも言っておきたいが、アメリカでも事情は殆ど同じである(StackOverflow や Reddit などの投稿を見ている限り、アメリカにも有能な人材に劣らずクズみたいなエンジニアが山のようにいる)。僕がすべてにおいて一級の仕事ができるなどとは思っていないが、少なくとも大手広告代理店の大小様々な受託開発案件で管理画面のビジュアル・デザインから Movable Type や WordPress のテンプレート作成からサーバ構築(それこそデータセンターに搬入された 1U のマシンを徹夜でケーブリングしてセットアップしたり、事業所の移転において LAN ケーブルをオフィス・フロアでケーブリングするような作業も含めて)あるいは UML のドキュメント作成やキャパシティ・プランニングや個人情報保護方針の文面作成といった法務のようなことまでを《お金が取れるレベル》で全てこなせる人材は、IT ゼネコンにすらそうそういないと自負している。そういう人間から見て、こういう場合の作業全体を管理したり作業を任せられるとすれば、恐らくウェブ制作会社では、まずコンテンツを全てレンタル・サーバへ移し替えない限りは、現行のシステムを整備しなおすのは難しいと言わざるをえない。少なくともインフラと OS やミドルウェア、バックエンドについては、運用専門の会社に任せたうえで作業するようにしないと、負荷も予算も高くなる。

それはそうと、一つ不思議なのは、このメール送信ライブラリを採用した元社員が在籍した時期を考えると、入社してすぐにライブラリを使ったと考えても、その時点で既にライブラリの開発が止まってから3年は経過していたということである。ありがちなことではあるが、お気に入りのライブラリが一つ決まると、それをアップデート情報を大してフォロー・アップすることなく何年でも使い続けてしまう人がいて、これもソフトウェア工学の「ライフサイクル」といった概念なりトピックを学んでいれば、ちゃんと変更管理という仕組みを実務に取り入れている筈である。このあたりは、僕は IT ゼネコンのエンジニアなんてたいていは新卒研修で覚えた Java や VB をガラパゴス手法で十年一日のことくこねくり回しているだけの無能コーダ集団だと思っているが、マニュアル的に教え込まれている変更管理のような手順は身についているという理由で、プロジェクト・マネジメントの歯車としては大多数のウェブ制作会社にいる出鱈目でイージーなエンジニアよりも評価している。

  1. もっと新しいノート <<
  2. >> もっと古いノート

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Twitter Facebook