実践！SMTP

3 メール構造の確認作業

[3.1] メールのヘッダと本文

先ほど送ったメールを MUA で見てみると, 宛先も差出人も本文も何もない一見空メールのようなメールが届いています (注意: Webmail を使うと勝手に空行が入れられることがあります. ELMS ポータルのメールも自動で空行等を入れて本文が読めるようです. 本文が読めてしまった場合でも気にせず作業を続けてください)

本文だけを表示させた MUA(Thunderbird 3.1.11). ...何も表示されていない.

しかし, 実際にメールのソースをのぞいてみると, 先ほど SMTP 通信で記入した いくつかの事柄が反映されているのがわかります.

ソースを表示させる場合の MUA 画面.

レクチャーでも話が有りました通り, メールのソースは "ヘッダ", "空行", "本文" で構成されており, MUA はそのソースを見て最初の空行以下を本文と見なします. 先ほど送ったメールのソースには, "空行"が入っていなかったため すべてのソースを "ヘッダ"と見なしてしまったのです.

なので, Hello!! 以下を本文として認識させたい場合には, data と打ったあとに一行空白行をいれてあげる必要が有ります.

data 以下に空白行をいれた場合.

data 以下に空白行をいれた場合のソース.

[3.2] エンベローブ(封筒) と コンテンツ (便箋)

先ほどの画像のメールはもう数カ所, 不思議な点が有りました. そう, 差出人や件名, 宛先が書かれていないことです (ただし, Webmail の場合自動で書き込まれていることもあります. ELMS ポータルのメールの場合も自動で書き込まれているようです). 通常メールで記入されているこれらの情報は, 人間がメールを管理しやすいように後から付加されたものであり, SMTP 通信自体には何も影響を及ぼしません.

何回か話に上っているように, "メール"というのは"ヘッダ""空行""本文"で構成されます. これらの目に見える (ソースに書かれる) 部分を"コンテンツ"と呼びます. しかしながら, 実は, メールはコンテンツだけではなく"エンベローブ"と呼ばれる SMTP 通信に影響を及ぼす情報も持っています. もし, メールに差出人や件名, 宛先が書かれていなかったとしてもエンベローブがあればメールを送信することはできます. イメージで言えば, エンベローブは封筒に書かれている実際の宛先, コンテンツは封筒の中の便箋に書かれた文章だと思っていただいてもかまいません. エンベローブ (封筒) での情報さえしっかりしていれば, コンテンツ (便箋) の中に宛先が書いてあろうがなかろうが, そしてそれが間違っていようが, メールは送信先ヘ届きます.

エンベローブがあればメールが送信先へ届くといいました. しかしながらヘッダが必要ないかというとそうではありません. 今現在, 電子メールが世界で広く用いられ, 多くの情報が流れるようになっています. こうした世の中では一目見てメール情報を取り出せるということが必要とされます. ヘッダがあると受信時にメール情報が一目でわかるようになります.

コンテンツ内のヘッダは RFC2822 (邦訳) で規約化されております. メールの送信時に MUA がこの規約に則ったヘッダ情報を付加し, 受信時にはそのヘッダを解釈することで重要な情報をわかりやすく表示するようになっています.

コンテンツ内に記されるヘッダの内容

Return-Path:	エンベロープのMAIL FROM:の内容
Received:	サーバの経路情報
From:	書いた人のアドレス
Sender:	送った人のアドレス
To:	送り先のアドレス
Cc:	コピーの送り先のアドレス
Date:	メールを送信するタイミングの日時
Subject:	主題
Comments:	本文に付け加えるコメント
Message-Id:	メールを一通一通区別する為の文字列
References:	どのメールを参照すべきかを示す元メールのMessage-Id
In-Reply-To:	どのメールへの返信かを示す元メールのMessage-Id

ここまでの情報から先ほどの画像の例で何があったかが分かります. 画像のメールでは SMTP 通信で打ち込んだ宛先, 差出人情報がエンベローブ情報として格納されているため, 無事に配送されました. しかし, MUA が解釈するようなコンテンツヘッダ内にそのような情報を陽に付け加えなかったために, MUA で差出人情報等は表示されなかった, というわけです.

それでは, ここからは RFC2822 に沿ってメールにヘッダ情報を付加したメールを送信してみましょう. メールを送信したら ELMS ポータルのメールで確認してみてください.

$ telnet mail.ep.sci.hokudai.ac.jp 25 Trying 133.50.160.50... Connected to grey.ep.sci.hokudai.ac.jp. Escape character is '^]'. 220 grey.ep.sci.hokudai.ac.jp ESMTP helo inex-gw.ep.sci.hokudai.ac.jp 250 grey.ep.sci.hokudai.ac.jp mail from:xxxxxxxxx@eis.hokudai.ac.jp 250 ok rcpt to:--------@eis.hokudai.ac.jp 250 ok data 354 go ahead To: --------@eis.hokudai.ac.jp From: xxxxxxxx@eis.hokudai.ac.jp Subject: Test2 ↵ Hello! Do you understand who I am? . 250 ok 1106822056 qp 28696 quit

無事差出人や件名が入力した内容で表示されましたね?

To, From, Subject フィールドを記入した例.

To, From, Subject フィールドを記入したソースの例.

[3.3] ヘッダ内情報詐称

さてさて, ここからが重要です. 先ほどの繰り返しとなりますが, ヘッダ情報は, メールの情報を取り出しやすくはするけれども, SMTP 通信に影響を及ぼしません. これはヘッダ情報, すなわち MUA で書いてある宛先, 差出人情報はいくらでも詐称できるということを意味します.

. 実際に体験してみましょう.

$ telnet mail.ep.sci.hokudai.ac.jp 25
Trying 133.50.160.50...
Connected to grey.ep.sci.hokudai.ac.jp.
Escape character is '^]'.
220 grey.ep.sci.hokudai.ac.jp ESMTP
helo inex-gw.ep.sci.hokudai.ac.jp
250 grey.ep.sci.hokudai.ac.jp
mail from:xxxxxxxx@eis.hokudai.ac.jp
250 ok
rcpt to:--------@eis.hokudai.ac.jp
250 ok
data
354 go ahead
To: nisemono@eis.hokudai.ac.jp
From: waruiko@eis.hokudai.ac.jp
Subject: Test3
↵
Hello!
Do you understand who I am ?
gufufufufufu.....:-] 
.
250 ok 1106822056 qp 28696
quit

さて, それでは ELMS ポータルのメールで確認してみましょう... 差出人情報が詐称されていますね ?

TO, From フィールドを詐称した例.

TO, From フィールドを詐称したソースの例.

このような手段を用いて, 一般にくるスパムメール, ウィルスメールは To:, From: フィールドを詐称しています. なので, 親しい知人, 銀行, カード会社からのメールを装 うことは非常に簡単です. なので, ウィルスメールの差出人情報を信じない, 怪しいメールを見たらまず疑う, 大切な個人情報は流出させないなど, きちんと自己防衛を身に付ける必要があるでしょう. また, ここまでに学んできたように差出人情報の詐称はヘッダを見ることですぐにわかります. 言わずもがなですが, 決して悪用しないように！

以上、正しい知識を身につけてインターネット社会をうまく渡り歩いて行きたいものですね.