偽装メールを見破れ！（後編）：Security&Trust ウォッチ（39）

　前回「偽装メールを見破れ！（前編）」では、偽装メールを見破るポイントがヘッダにあることと、簡単に偽装メールを送信できることについて解説した。

　今回は偽装メールを見破るポイントを知り、メールの「Received」ヘッダから信用できる情報とそうでないものを見分ける方法について触れる。また、偽装メールと間違われないために「差出人」を保証するための技術を紹介する。

見破る基本は「Received」ヘッダを正しく読むこと

　配送経路の情報をヘッダから正しく読み解くためには、まず「Received」ヘッダの読み方を知る必要がある。次の図は、差出人「tip＠nifty.com」からあて先「ueno＠usagidesign.jp」に送られたメールヘッダのサンプルから、「Received」ヘッダ部分のみを抜き出したものである。果たして差出人のメールアドレス「tip＠nifty.com」の真偽は確認できるだろうか。

図1　「Received」ヘッダに注目

　「Received」ヘッダは配送経路を1つ通過するたびに、「どこから」「どこあて」のメールを「いつ」扱ったという情報を加えていく。つまり、配送経路は下のものほど古く、図中の（1）（2）（3）のように順を追っていくことで確認することができる。

　「Received」ヘッダは次のような構造をしている。

　それぞれの意味は「fromのMTAから、byのMTAがviaの接続方式を使ってwithの転送方法で受け取りました。メッセージを特定する識別子はidで、forあてのメールです。これはdate-timeの日時に処理しました」ということだ。図1では一部省略されている項目もある。

「Received」ヘッダの前後関係をつなげ

　まず注目すべきなのは図1で黄色く強調している部分、すなわち（1）と（2）の「from」と「by」が指しているMTAのドメイン名の関係だ。

　（1）の「by」が指すMTAのドメイン名「userg500.nifty.com」は、送信者側に当たる（1）のサーバが勝手に名乗っているだけのものだ。それ故、（1）の情報だけで信用できるとはいえない。

　では（2）を見てみよう。「from」には「userg500.nifty.com (202.248.238.80)」と記載されており、これは（1）の「by」に書かれているものと同じである。（2）のMTA（192.168.1.7）は受信者側のものなので、この情報は一応信用してもよいといえる。

　「Received」ヘッダには前後関係があり、基本的に先に付けられた「Received」ヘッダの「by」と後から付けられた「Received」ヘッダの「from」が同じものを指している。つまり、（1）の「by」と（2）の「from」が同じであるならば、（1）の「by」も（2）の「from」と同程度信用してもよいということになる。ただし、送信者側のMTAのドメイン名やIPアドレスは分かったが、（1）のほかの情報（fromやidやforなど）が信用できるかどうかは分からない。

図2　信用できるのは受信者側サーバが付けた情報

「Received」ヘッダから正しく読み取れること

　送信元のMTA「userg500.nifty.com」は、差出人のメールアドレス「tip＠nifty.com」のドメインと一致する。差出人が「tip」というユーザー本人であるかどうかは分からないが、少なくとも「＠nifty.com」のユーザーであることはほぼ間違いがないはずである。

　もし、差出人のメールアドレスのドメイン部が「＠nifty.com」ではないならば、何らかの詐称が行われている。MTA「userg500.nifty.com」の管理者ならばログからメールの真の差出人が割り出せる可能性が高い。ただし、最近は裁判所などからの命令でもない限りMTAの管理者が第三者に情報を開示することはないだろう。

　また、前編で紹介したように「Received」ヘッダの偽装によって配送経路をごまかしているならば、（1）の「by」と（2）の「from」の前後関係に矛盾が生じる。そこに注目すれば、偽装を見破ることが可能である。

　結局のところ、「Received」ヘッダの中で信用できる情報というのは、受信者側のMTAが付けたものだけである。信用できる情報が少ないように思えるが、昨今のインターネット上のメールは、複雑な経路を通らずに、送信者側のMTAから受信者側のMTAに直接配送されることが多い。そのため受信者側のMTAが付けた情報によって1つ手前のMTAが分かるだけで、差出人のメールアドレスが正しいと確認できる場合も多い。

「Received」ヘッダによる見分けでは見切れないもの

　「Received」ヘッダを読み解くことでメールの真偽を確かめる方法では、真偽の確認が困難な場合もある。例えば、送信者が転送メールアドレスを使用している場合や、メーリングリストに投稿されたメールなどである。あるいは、詐称目的でなく差出人が意図的にメールアドレスを書き換えたメールもあるかもしれない。

　また、MTAが不正中継を許しているなどのセキュリティ上の不備がある場合もあり得る。ほかにも、実際には偽装メールではなくても、配送経路によっては「Received」ヘッダに必要な情報がすべて記載されていないこともある。

　なお、「Received」ヘッダの解析を行う「hdpar」といったツールがある。慣れないうちはこれを活用すると理解しやすいだろう。

メールサーバが身元を保証する送信ドメイン認証

　「Received」ヘッダの情報は意外と頼りにならない。しかし、このままではメールが信用できないコミュニケーション手段としての地位しか得られない。そこで信用度を高めるために、2年ぐらい前から導入されはじ始めているのが送信ドメイン認証という技術である。

　これは、「送信に使われたメールサーバが、差出人の正規のメールサーバかどうかを確認する」ことが目的の技術である。主な方式には、IPベース認証方式のSPF（Sender Policy Framework）とSender ID、電子署名ベース認証方式のDomainKeysの3種類がある。

　メールメッセージに次のようなヘッダが付いていれば、何らかの形で送信ドメイン認証が活用されている。

　送信ドメイン認証の詳細については、＠ITのSecurity&Trustフォーラムの特集などで取り上げられているのでそちらを参考にして頂いただきたい。

第三者が個人の身元を保証する電子署名と暗号化

　送信ドメイン認証では、ユーザーが本人かどうかを確認することはできない。例えば、差出人のメールアドレスが「tip＠nifty.com」ならば、「nifty.com」の真偽は確認できるが、「tip」の真偽は確認できない。送信者側のメールサーバ上ではユーザー認証が行われて送信されていたとしても、それは受信者側には伝わらない。

　受信者側が差出人の身元を確認するには、電子署名を活用する方法が有効だ。一般的にPGPとS/MIMEの2種類が使われる。電子署名とそれによる暗号化を使うことで、以下のようなメールメッセージ自体のセキュリティが付加される。

• 署名（本人であることの保証）
• メッセージの完全性の保証
• メッセージの暗号化（秘匿性）

　電子署名の有効性の確認や、暗号化されたメールメッセージの解読は、それに対応したメールクライアントソフトを使っている必要がある。相手がWebメールを使用している場合などでは読めない可能性が高い。

　普段、送受信しているメールの中から、「ズバリ、このメールは信用できます」といい切れるものを見つけるのは難しい。しかし、重要なメールをやりとりする企業であれば、電子署名や送信ドメイン認証を活用すべきである。現状のメールシステムでは、自衛しないと偽装メールと疑われる余地が大きい。残念なことである。