実践!SMTP

  1. 実習の前準備
  2. telnet を使用した SMTP 体験
  3. (続) telnet を使用した SMTP 体験
  4. GPG を使用した暗号化, 復号化体験
  5. [付録] どこまでが信用できる情報か?

3 (続) telnet を使用した SMTP 体験

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

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


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

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


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

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

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


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

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

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

先ほどのメールはもう数カ所, 不思議な点が有りました. そう, 差出人や題名, 宛先が書かれていないことです. 通常メールで記入されているこれらの情報は, 人間がメールを管理しやすいよう に後から付加されたものであり, 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

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

それでは, RFC2822 に沿ってメールにヘッダー情報を付加したメールを送信 してみましょう.
$ 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 lemon.ep.sci.hokudai.ac.jp
250 grey.ep.sci.hokudai.ac.jp
mail from:hoge@ep.sci.hokudai.ac.jp
250 ok
rcpt to:xxxxxxxxx@ec.hokudai.ac.jp
250 ok
data
354 go ahead
To: xxxxxxxx@ec.hokudai.ac.jp
From: hoge@ep.sci.hokudai.ac.jp
Subject: Test2Hello!
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 lemon.ep.sci.hokudai.ac.jp
250 grey.ep.sci.hokudai.ac.jp
mail from:hoge@ep.sci.hokudai.ac.jp
250 ok
rcpt to:xxxxxxxxx@ec.hokudai.ac.jp
250 ok
data
354 go ahead
To: nisemono@ec.hokudai.ac.jp
From: waruiko@ep.sci.hokudai.ac.jp
Subject: Test3Hello!
Do you understand who I am ?
gufufufufufu.....:-] 
.
250 ok 1106822056 qp 28696
quit

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


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

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

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

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

> 次のページへ


最終更新日: 2011/07/26 荻原 弘尭 Copyright © 2006 inex