メールヘッダにないアドレスになぜ届く？

　相手かまわずばらまく悪質なスパムメールを受信すると、そのメールヘッダに受取人の正しいアドレスが指定されていないものです。それにもかかわらずなぜ自分に届いたのかと不思議に思う人がおられるでしょう。それについてここでご説明しましょう。

　まず、メールヘッダとはどういうものかの実例を示します。これはスパムメールではありませんが、アメリカのオハイオ州立大学のネットワークにつながるコンピュータに感染したHybrisというコンピュータウィルスが、そのコンピュータのインターネット一時ファイルから「webmaster@gabacho-net.jp」というアドレス（私に届くアドレス）を取り出して自分の分身を送りつけたと考えられるものです。

Date: Mon, 25 Jun 2001 21:06:34 -0400 (EDT)
Message-Id: <200106260106.VAA22170@mail1.uts.ohio-state.edu>
From: Hahaha <hahaha@sexyfun.net>
Subject: Snowhite and the Seven Dwarfs - The REAL story!
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--VE1IR45QZCHEJSTAJ4PU3SPEJWDEZ85"
To: undisclosed-recipients:;

　このようなごちゃごちゃしたメールヘッダは、メーラーで普通にメールを読む時には表示されません。通常表示されるのは、Date（日付）、From（差出人アドレス）、Subject（件名）、To（受取人アドレス）、CC（カーボンコピーの受取人アドレス）くらいです。しかし、メールヘッダを表示する操作（方法はメーラーによって違います）をすれば、見ることができます。

　このメールのFromアドレスは、おそらくでたらめです。「To: undisclosed-recipients:;」（開示されていない受取人）とあるのは、発信元のコンピュータから出たメールのヘッダにToヘッダがなかったため、メールサーバが補ったものです。
　Receivedヘッダは、メールを中継または最終的に受信したメールサーバが記録するものです。Receivedヘッダはメールヘッダの先頭部分に追加されていくので、その並び順はメールサーバの通過順の逆順になります。すなわち、最も下にあるReceivedヘッダが、最初に中継したメールサーバが書き込んだものです。ここから、mail1.uts.ohio-state.eduというサーバが最初に中継したことがわかります。

　さて、このメールのToヘッダには私のアドレスが指定されていないのにどうやって私に配送されたのでしょうか。Receivedヘッダに「for <webmaster@gabacho-net.jp>」と真の受取人アドレスが記述されていますが、メールサーバはここから配送先を知ったのではなく、逆に、メールサーバがすでに知っている真の受取人アドレスを記録として書き込んだものです。実は、メールサーバはメールヘッダを頼りとして配送先を知るのではないのです。
　ではどうやって配送先を知るのかというと、SMTP（Simple Mail Transfer Protocol：簡易メール転送プロトコル）という通信規約に基づくやり取りによって受け渡されます。その例を示します。これは、Gabacho-Netのメインサーバへ、もう一台のサーバから手動でテストメールを送信したものです。赤地の行はメールの送り側からの送信メッセージ、青地の行は受け側のメールサーバからの返りメッセージです。

`telnet a.gabacho-unet.ocn.ne.jp smtp`	通信コマンドを起動
`220 a.gabacho-unet.ocn.ne.jp ESMTP Postfix`	受け側からの通信準備完了メッセージ
`HELO c.gabacho-unet.ocn.ne.jp`	送り側のホスト・ドメイン名を名乗る
`250 a.gabacho-unet.ocn.ne.jp`	受け側のホスト・ドメイン名が返る
`MAIL FROM:<deo@c.gabacho-unet.ocn.ne.jp>`	差出人エンベロープアドレスを伝える
`250 Ok`	受諾メッセージ
`RCPT TO:<webmaster@gabacho-net.jp>`	受取人エンベロープアドレスを伝える
`250 Ok`	受諾メッセージ
`DATA`	メッセージデータの開始を通告
`354 End data with <CR><LF>.<CR><LF>`	受諾メッセージ
`From: deo@c.gabacho-unet.ocn.ne.jp`	メールヘッダ
`To: webmaster@gabacho-net.jp`	〃
`Subject: test`	〃
	空白行
`This is a test message.`	本文
`.`	メッセージデータの終了を通告
`250 Ok: queued as D295322642`	受諾メッセージ
`QUIT`	通信終了を通告
`221 Bye`	終了受諾メッセージ

　配送は、エンベロープ（封筒）アドレスに基づいて行われます（「エンベロープアドレス」とは、世界で最も広く使われているメール転送サービスプログラムであるsendmailの用語です）。受取人エンベロープアドレスが真の配送先です。差出人エンベロープアドレスは、メールサーバが配送エラーを検出した場合の差し戻し先アドレスになります。メールヘッダは、メッセージデータの一部にすぎず、配送制御には使われません。
　上記のように、SMTP通信を手動で行うことによってメールを送ることもできますが、もちろん、メーラーはこれを自動で行ってくれます。メーラーは、ユーザーが指定したアドレスを次のようにSMTP通信に反映します。

メーラーに設定した差出人アドレス：差出人エンベロープアドレスとFromヘッダの両方に反映します。
Toに指定した宛先アドレス：受取人エンベロープアドレスとToヘッダの両方に反映します。
CC（カーボンコピー）に指定したアドレス：受取人エンベロープアドレスとCCヘッダの両方に反映します。
BCC（ブラインドカーボンコピー）に指定したアドレス：受取人エンベロープアドレスに反映しますが、メールヘッダには反映しません。

　エンベロープアドレスは、メールサーバの中で、メッセージデータとは別の配送制御用データとして管理されます。そして、最終的に受取人のメールボックスにメッセージデータ（メールヘッダと本文）を格納した時、配送制御用データは消滅します。ただし、差出人エンベロープアドレスが何だったかはReturn-Pathヘッダに残ります。また、受取人エンベロープアドレスはReceivedヘッダに記録されていることがあります。
　なお、冒頭で例示したウィルスメールでは、Return-Pathヘッダから、差出人エンベロープアドレスが空アドレス（<>）に偽造されていたことがわかります。空の差出人エンベロープアドレスは、本来、エラー差し戻しの投げ合いが起こらないようにするためのものですが、ここでは、発信元がエラー差し戻しの受け取りを拒否するために悪用されています。
　これで、ToヘッダやCCヘッダに現れていない宛先アドレスへなぜメールが配送されるのか、また、メールヘッダに現れないBCCに指定した宛先にもなぜメールが配送されるのかがおわかりいただけたと思います。ついでに言えば、メーリングリストで配信されるメールのToヘッダがメーリングリストアドレスのまま変更されていないのに各メンバーに届くのも、Toヘッダを頼りに配送しているのではないからとおわかりいただけるでしょう。

　さて、ここまでご説明すれば、「Toなどのヘッダを偽造しても、意図した相手にメールを届かせることはできる」ということもおわかりいただけると思います。
　しかし、メールヘッダ全体を調べれば、真の発信元ネットワークはどこか、また、発信者が指定した真の受取人アドレス（たとえば私の場合について言えば、「webmaster@gabacho-net.jp」なのか「deo@gabacho-net.jp」なのか）がわかります。こうして得た情報は、不正なメールの発信元ネットワークの管理者に対処を要請したり、実際に狙われている自分のアドレスを無効にするなどの対策に利用することができます。
　不正なメールでお困りの方には、このようにメールヘッダ全体から情報を探る方法に慣れるようお奨めします。