Toヘッダーに記載されてないのに何故メールが届くのだろう！？と言う疑問を前提に解析してみた。
非常に不愉快な、Spamメール。このSpamメールと言う奴は、SMTPプロトコルの習性を巧妙に利用している。
統計によると、ネット上に行き交うメールの80％がSpamメールだと言うからなおさら腹が立つ。人の迷惑を喜んでいる不謹慎な奴らのメールを分析してみる。
これから説明するSMTPプロトコルを含めた偽造メールの仕組みは、私たちの思いこみを逆手に取ってるのである。
（尚、この中で鯖とは、サーバの事である）
結論：
「メール送信の為の配送制御に必要なメールの差出人、受け取り主アドレスはメールヘッダーを参照してる訳ではない。」
以下は、Spamメールの一例だ。さらに、これは典型的な偽装してるヘッダーだ。あるコンピュータにワームが感染して、自分の分身をSMTPエンジンを使って送り出してるメールヘッダもこれによく似ている。
Return-Path: <>
Delivered-To: waru@bbb.xxxxxxxx.ne.jp
※３ → Received: from mail3.xxxxxxxx.edu (mail3.xxxxxxxx.edu [xxx.xxx.xxx.xxx])
by xxxxxxxx.ne.jp (Postfix)
with ESMTP id 06B7522610 for <webmaster@xxxxxxxx.com>;
Tue, 26 Jun 2001 10:06:45 +0900 (JST)
Received: from tomas (nikoniko.spamnet.xxxxxxxx.edu [xxx.xxx.xxx.xxx])
by mail3.xxxxxxxx.edu (8.9.3/8.9.3)
with SMTP id VAA22170 for <webmaster@xxxxxxxx.com>;
Mon, 25 Jun 2001 21:06:34 -0400 (EDT)
Date: Mon, 25 Jun 2001 21:06:34 -0400 (EDT)
Message-Id: <200106260106.VAA22170@mail3.xxxxxxxx.edu>
※１ → From: spamspam <spamspam@xxxxxxxx.net>
Subject: Nominated for MSC
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=”–VE1IR45QZCHEJSTAJ4PU3SPEJWDEZ85″
※２ → To: undisclosed-recipients:;
X-UIDL: ?2:!!S’8e99Uj!!-0O!!
これは、メーラーでのヘッダー表示もしくは、ソース表示を操作を行うと見られる。
このメールで、まず目くらましは、※１印のFromヘッダーだ。このヘッダーアドレスは偽造である。正直、こんなものいくらでもデタラメを書き込むことは可能。
さらに、※２のToヘッダー「undisclosed-recipients:;」は、”開示されていない受け取り主”と言う意味で、自ドメインのメール鯖が自動的に付加するものである。
※３のReceivedヘッダーは、メールを中継した、もしくは最終的にメールを受信した鯖が記録するものだ。つまり、この場合Receivedヘッダーが二つあるのは、メール鯖を通過した逆の順番である。したがって、最後のReceivedヘッダーの鯖（nikoniko.spamnet.xxxxxxxx.edu）は最初にメールを中継してまずはヘッダーを書き込み、その次のReceivedヘッダーの鯖（mail3.xxxxxxxx.edu）が中継した事が解る。
ところで、みなさんも疑問に思うだろうが、※２のToヘッダーの、元々相手先のアドレスの記述が無く、”開示されてない受け取り主”と言うスタンプが押されたのに何故、 私である、 webmaster@xxxxxxxx.com へメールが配送されたのだろうか？
ここがプロトコルを利用した、偽造メールのトリックの部分だと思う。
Receivedヘッダーに webmaster@xxxxxxxx.com と受け取り主のメールアドレスが書いてあるが、メール鯖はこの記述から相手先を知るわけではない。メール鯖が既に解っている受け取り主のアドレスを記録して書き込んでいるものなのだ。
では、解りやすいように、SMTP（Simple Mail Transfer Protocol：簡単メール転送プロトコル）プロトコルの図1を追って説明しよう。
以下、図１のTCPクライアントソフト側からで説明する。
■ TCPコネクション開始
ここでは、コマンド telnet 相手方のホスト名 smtp こんな感じのコマンド発行して相手の鯖に通信準備OKかを問い合わせる。通常、準備OKなら相手から通信準備完了メッセージ、220 ホスト名 ESMTP Postfix が返ってくる。
■ HELOメッセージを送る
HELO 送り側のクライアントのドメイン名 を送って自分を名乗る。
存在しないドメイン名では無い限り、250 OKが返ってくる。
■ MAIL FROM 差出人アドレスを伝える
MAIL FROM：差出人メールアドレスを伝える。250 OKが返ってくる。
ここでは、差出人は、アカウント＠ドメインの形式になってればどんな適当なメールアドレスでも、250 OKが返ってくるはずである。したがって、FROMの偽造は簡単なのである。
■ RCPT TO 受取人アドレスを伝える
RCPT TO：受取人メールアドレスを伝える。250 OKが返ってくる。
ただし、この場合は受取人が、そのメール鯖に存在しなかったり、メールの中継を禁止してる鯖ではエラーを返す。
■ メッセージデータの送信開始を提示
DATAコマンドでメッセージデータの送信を知らせる。この時、図には書いてないが、354 END DATA WITHと言う受諾メッセージが返る。
■ メールの中身（ヘッダと本文）の送信
メールの中身を送信する。中身の送信が全て終わったら、空行とピリオドだけを送る。250 OK Acceptedが返る。
■ 別のメールを送信するか終わりか
別のメールを送信する場合は、MAILコマンドから繰り返すことが出来る。送るメールが無ければ、QUITを送って終了する。
ここで解ったことは、メールヘッダーは、メッセージの中の鯖が捺印したデータに過ぎず、一連の配送の手順の中では何の関係も無いことが解った。メーラは、このようなコマンドを発行する手順を自動化してくれるアイテムなのだ。
さらに、以降、エンベロープアドレス（メーラー（MUA）が作成したメールアドレスで本文とは別物情報）という言葉を使う。
● メーラに設定した差出人アドレスは、差出人エンベロープアドレスとFromヘッダーの両方反映
● Toに設定した宛先アドレスは、受け取り主エンベロープアドレスとToヘッダーの両方反映
● Cc（カーボンコピー）に設定したアドレスは、受け取り主エンベロープアドレスとCcヘッダーの両方反映
● Bcc（ブラインドカーボンコピー）に設定したアドレスは、受け取り主エンベロープアドレスには反映されるが、その他メールヘッダーには反映されない
エンベロープアドレスは、メール鯖の中では、メッセージとは別の配送を制御する為のデータとして使われる。さらに、エンベロープアドレスは、最終的に受け取り主のメールボックスにメッセージを格納したら消滅する。
そのときに、差出人エンベロープアドレスアドレスは、Return-Pathヘッダーに記され残るようになっている。また、受け取り主エンベロープアドレスはReceivedヘッダーに記され残る。但し、この場合のReturn-Pathヘッダーは「＜＞」なので偽造されてる事が解る。
ここまでで、各種ヘッダーに現れない宛先アドレスに何故メールが配送されるのかの仕組みが解っただろう。さらに、メーリングリスト等でToヘッダーがメーリングリストアドレスなのにメンバー個々のアドレスへ配送されるのか。訳が解ったと思う。別に、狐に摘まれてるわけでも何でもない。メールのプロトコル（通信規約）でメールヘッダとは別にエンベロープアドレスというのがあって、そいつが配送制御しているのである。さらに、ヘッダーはメール鯖が打刻したスタンプに過ぎない。と言うことを覚えて欲しい。
Spam等の不正なメールにごまかされない為にも、メールの配送プロセスは理解しておくべきだと考える。
以上
コメント