実践!SMTP

  1. 実習の前準備
  2. telnet を使用した SMTP 体験
  3. メール構造の確認作業
  4. GPG を使用した暗号化, 復号体験
  5. [付録] どこまでが信用できる情報か?

3 メール構造の確認作業

[3.0] 作業前の注意

今回はELMS メール(Gmail)を使って, 先ほど送ったメールのソースを確認します. その時に, 複数のユーザが一つのブラウザでELMS メールのログインを試みると, 複数のアカウントがログイン状態になる可能性があります. その場合, 一旦ログアウトしても, その後のログイン画面に複数のアカウント情報が 閲覧できる状態となる可能性があり, セキュリティの観点から非常に危険です. そのような状態を避けるために, もし同じ情報実験機内で複数のユーザが以下の作業を 行う際には, 必ずもう一つ違う種類のブラウザを立ち上げてください. 以下のように, Chromium をインストールして, もう一人が[3.1] 以降の作業を行う際には firefox ではなく, Chromium を使うようにしてください.

# apt-get install Chromium

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

先ほど送ったメールを MUA(Gmail) で見てみると, 以下のような, 前ページの"mail from:XXXX~" からのメールが届いています. ただ普通ならTo には送り先のアドレスが書かれているはずですが, どうやら情報が欠損したメールが送られているようです

03_smtp_01
Gmail で見た先ほど送ったメール.

このような一見怪しいメールを見たときには, メールのソースをのぞいてみるとよいでしょう(メールのソースを見る方法はMUA によって異なるので 気になる人は調べてみましょう).

03_smtp_02
メールのソースを見る方法."1" をクリックすると,メニューが出てくるので "2" の「メッセージのソースを表示」を選択.

そうすると, 先ほどのSMTP 通信で記入したいくつかの事柄が反映されているのがわかります. 例えば, 最初の行の"Deliverd-To" には先ほどのSMTP 通信の "rcpt to: " で入力したメールアドレスが記述されており, 後半の"From:" 行には"mail from: " で入力したメールアドレスが記述されているはずです. また, 先ほどの"To" の部分に何もかかれていなかったのは, ソースの"To" 行が"undisclosed-recipients:;" となっているためです ("undisclosed-recipients" は受取人不明の意). さらに最後には, "To" 行に空行を一行挟んで本文が記述されています.
レクチャーでも話が有りました通り, メールのソースは "ヘッダ", "空行", "本文" で構成されており, MUA はそのソースを見て最初の空行以下を本文と見なします.

03_smtp_03
メールのソース.

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

先ほども記述しましたが, 画像のメールには不思議な点が有りました. そう, 件名がなかったり, 宛先が書かれていないことです (ただし, 他のMUA では見た目が変わる可能性があります). 通常メールで記入されているこれらの情報は, 人間がメールを管理しやすいように後から付加されたものであり, SMTP 通信自体には何も影響を及ぼしません.

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

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

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

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

Delivered-To:エンベロープのrcpt to:の内容
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: Test2Hello!
Do you understand who I am?
.
250 ok 1106822056 qp 28696
quit

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

03_smtp_04
メールのソース.
03_smtp_05
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: Test3Hello!
Do you understand who I am ?
gufufufufufu.....:-] 
.
250 ok 1106822056 qp 28696
quit

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

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

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

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

> 次のページへ


最終更新日: 2016/07/06 三上 峻 2016年度版に改訂 Copyright © 2000-2016 inex