Transcript MUA

ネットワークアーキテクチャ
第06回(2003/11/17)
「メールのアーキテクチャ」
村井 純
2003/10/20
Network Architecture 2003f
2003年度秋学期授業日程
09/29
10/06
10/13
10/20
10/27
11/03
11/10
11/17
11/24
11/26
12/01
12/08
12/15
12/22
～
01/08
01/12
01/19
2003/10/20
（最新情報はSoI*で確認してください）
(1)
講義概要/インターネットのアーキテクチャ
(2)
もうインターネットを分かっちゃおう
体育の日
(3)
DNSのアーキテクチャ
(4)
インターネット自動車のアーキテクチャ
文化の日
(5)
SOIのアーキテクチャ
(6)
メールのアーキテクチャ
今日はここ
勤労感謝の日の振替休日
(7)
WWWのアーキテクチャ
<-(水曜日)
(8)
セキュリティーのアーキテクチャ
(9)
インターネット上の様々なサービスを見てみよう
(10)
P2Pとオーバレイネットワーク
(11)
これからのネットワークアーキテクチャ（１）
冬休み
(12)
これからのネットワークアーキテクチャ（２）
<-(木曜日)
成人の日
(13)
最終試験
Network Architecture 2003f
突然ですが心理テスト
「大事な用件を伝える手紙に、不注意で切手を貼ら
ないでそのままポストに投函してしまいました。
あなたはどうする？」
• Ａ ポストの投函口からなんとか自分で取り出そ
うとする。
• Ｂ 集配の人を待って取り出してもらう。
• Ｃ 仕方がないとあきらめる。
• Ｄ 家に帰ってお詫びの手紙をかく。
» フジテレビ「めざましテレビ」より
2003/10/20
Network Architecture 2003f
答えは、後で。
というわけで、今日のテーマは
電子メールのアーキテクチャ
2003/10/20
Network Architecture 2003f
今日のお品書き
電子メールのアーキテクチャ
電子メールのプロトコル（SMTPとPOP）
メールの拡張
メールのセキュリティー

2003/10/20
Network Architecture 2003f
手紙の出し方を考えてみよう！
どうやって運ぶ？
差出人
受取人
A：伝書鳩を常時
飼っている
B：風に任せる
C：自らダッシュ！
2003/10/20
Network Architecture 2003f
一番、確実
でシンプル
手紙の出し方を考えてみよう！
差出人
配達員
受取人
でも、
•自分で渡すのは大変！
→配達員にお願いしよう
•配達員に手渡すのも面倒
→ポストを使おう
•遠い場合はどうするの？
→郵便局間のリレー
•配達した時に相手がいなかったら →私書箱を使おう
2003/10/20
Network Architecture 2003f
で、今の仕組みが成り立っている
中央郵便局
中央郵便局
管轄郵便局
管轄郵便局
差出人
受取人
or
私書箱
2003/10/20
Network Architecture 2003f
E-mailもほぼ同じ
ただし、インターネット
に「中央」はいない
SMTPサーバ
(配送担当)
POPサーバ
(保管、分配)
メールソフト
(差出担当)
メールサーバ同士でリレー
サーバに保管された
メールを自分で取りに
行く
2003/10/20
Network Architecture 2003f
電子メールシステムの概要
使用するプロトコル
MUA
SMTP
Simple Mail Transport Protocol
MTA
メールソフト → SMTPサーバ
(MUA → MTA)
MTA
SMTPサーバ → SMTPサーバ
(MTA → MTA)
POP3
MDA
Mail Transport Agent (配送担当)
SMTPサーバ
投函の受付 →
宛先付近のサーバへ配送
Mail Delivery Agent (分配担当)
サーバ内でユーザごとの
メールスプールへ配送
サーバ内メールスプール
Post Office Protocol
または、 IMAPサーバ
POPサーバ サーバ上のメールスプールから、
ユーザマシンへコピー
IMAP4
Internet Message Access Protocol
POP/IMAPサーバ → メールソフト
(MDA → MUA)
2003/10/20
Mail User Agent (差出担当)
メールソフト
編集 → 宛名記入 → 投函
Mail User Agent (受取担当)
メールソフト
MUA
受け取る →表示
Network Architecture 2003f
けっこう工程が多い。。。
• すべてのメーラがＳＭＴＰのサーバとクライアント
を兼ねてれば、もっとシンプルじゃない？
» …でもこれだとうまく行かなかった。なぜ？
MTA
SMTP
Taro用
メールスプール
POP
サーバ
sirokuma用
メールスプール
POP
サーバ
IMAP
サーバ
IMAP
MUA
読み書き
個人マシン
2003/10/20
MDA
MTA
POP
MUA
読み書き
個人マシン
Network Architecture 2003f
masa用
IMAP
サーバ
Ishi用
理由その１
• もともとは、UNIXワークステーション環境をベースに構築
されていた。
– ワークステーション上に多数のユーザ
– ユーザは、ワークステーションにloginしてメールを読む
• ローカルへの配送は、宛先のメールスプールにデータを書き込むだけ
UNIXワークステーション
送る
Taro用
メールスプール
読む
2003/10/20
送る
送る
Hanako用
メールスプール
読む
Network Architecture 2003f
sirokuma用
メールスプール
読む
別のワークステーションのユーザにもメールを送りたい
• ローカルへの配送と、リモートへの配送を区別
– リモートへの配送は、別のエージェントにしよう
• MUA(Mail User Agent)、MTA(Mail Transfer Agent)の起源
ローカル配送
リモート配送
MTA
Taro用
メールスプール
読む
2003/10/20
Hanako用
メールスプール
MTA
sirokuma用
メールスプール
読む
読む
MUA
MUA
Network Architecture 2003f
MUA
手元のマシンにメールをもってきたい
• 別のワークステーションからメールを読みたい
• ワークステーション以外のマシンでメールを読みたい
• POPの登場 → 個人マシン(PCなど)の利用が高まり、一般的に！
ローカル配送
リモート配送
MTA
Taro用
メールスプール
POPサーバ
POP
MUA
読み書き
個人マシン
2003/10/20
Hanako用
メールスプール
読む
MUA
読み書き
Network Architecture 2003f
MTA
sirokuma用
メールスプール
POPサーバ
POP
MUA
読み書き
他のワークステーション
理由その２
• ダイアルアップが主だった時代だと・・・
モデム
ダイアルアップ
MTA
Taro用
メールスプール
POP
サーバ
IMAP
サーバ
IMAP
MUA
読み書き
個人マシン
2003/10/20
モデム
インターネット
SMTP
相手が
繋がっていないので
送れない
→メールサーバが
必要
MDA
MTA
sirokuma用
メールスプール
POP
サーバ
POP
MUA
読み書き
繋がっていればいらない？
Network Architecture 2003f
個人マシン
Ishi用
IMAP
サーバ
MDAやIMAPの登場
•
MDA
– リモートから配送されたメールを、ローカルのメールスプールに分配する機能を
別エージェントとして分離することもある(qmailなど)
•
•
Sendmailでは、MTAであるsendmailがローカル配送まで受け持つ
IMAP
– サーバ上に保管したメールを複数のマシンから読むことを想定
メールサーバ
MTA
SMTP
Taro用
メールスプール
POP
サーバ
sirokuma用
メールスプール
POP
サーバ
IMAP
サーバ
IMAP
MUA
読み書き
個人マシン
2003/10/20
MDA
MTA
POP
MUA
読み書き
個人マシン
Network Architecture 2003f
masa用
IMAP
サーバ
Ishi用
ところで、さっきの心理テストの答え
「大事な用件を伝える手紙に、不注意で切手を貼らないでそのままポストに投函し
てしまいました。あなたはどうする？」
→これで「あなたの秘密のバレ方 」が分かるらしい
•
Ａ ポストの投函口からなんとか自分で取り出そうとする。
→「態度でバレる人」
秘密を抱えると、落ち着かなくてソワソワ。なんだか怪しい人に変身してしまう。
•
Ｂ 集配の人を待って取り出してもらう。
→「友達からバレる人」
自分一人では抱えきれなくて、すぐに人に依存してしまう。
すぐ信用して、友達に話してしまう。
•
Ｃ 仕方がないとあきらめる。
→「自分の口からバレる人」
もともと秘密にしておくつもりがない。「ここだけの話なんだけど」と結局みんなにしゃべっている。
•
Ｄ 家に帰ってお詫びの手紙をかく。
→「秘密は守る人」
秘密は守ってこそ秘密というもの。口がかたい。
2003/10/20
Network Architecture 2003f
電子メールの配送プロトコル
2003/10/20
Network Architecture 2003f
メールアドレス
• メールのあて先
• @を区切りとして、
• 前半がユーザ名
• 後半がドメイン名
taro
• メールサーバ上の
ユーザ名
• メールサーバが
ユーザを識別
2003/10/20
@ sfc.keio.ac.jp
• 個人のインターネット上の場所
• ユーザが所属するメールサーバ
Network Architecture 2003f
配送先のメールサーバをどうやって知る？
• DNSを使って、宛先ドメイン名の「MXレコード」を検索
– [email protected]
– 第三回DNSのアーキテクチャ参照
DNSツリー
自組織の
DNSサーバ
Q. sfc.wide.ad.jpの
MXはどこ？
A.
sfc.wideドメインを管理する
DNSサーバ
shonan.sfc.
wide.ad.jpだよ
Shonan.sfc.wide.ad.jp
自組織の
SMTPサーバ
MUA
2003/10/20
宛先ドメインの
SMTPサーバ
実際に通信を開始する前に
shonanのAレコードも検索
Network Architecture 2003f
MUA
MXレコードの優先度
• 複数のメールサーバを指定可能
• 優先度の高いメールサーバに障害がある場合、次の優先度
のメールサーバに対してメールを配送
DNSツリー
自組織の
DNSサーバ
Q. sfc.wide.ad.jpの
MXはどこ？
sfc.wideドメインを管理する
DNSサーバ
A. shonan.sfc.wide.ad.jpが(優先度 5)
backup.sfc.wide.ad.jpが(優先度10)だよ
①反応ないなぁ
自組織の
SMTPサーバ
MUA
2003/10/20
②じゃあ、こっちに送ろ
Network Architecture 2003f
shonan.sfc.
wide.ad.jp
backup.sfc.
wide.ad.jp
MUA
SMTP; Simple Mail Transfer Protocol
メールソフト・
送信SMTPサーバ
受信SMTPサーバ
Helloメッセージ
応答
送信者通知
許可
メール受信者通知
許可
DATA通信開始要求
許可
DATA送信
終了通知
メール受信確認
2003/10/20
Network Architecture 2003f
実際の流れーSMTP
% telnet mail.sfc.keio.ac.jp smtp
Connected to mail.
220 mail.sfc.keio.ac.jp ESMTP Sendmail ～
HELO mail.sfc.keio.ac.jp
←通信の開始
250 mail.sfc.keio.ac.jp Hello ccz00, pleased to meet you
MAIL FROM: [email protected]
←送信元メールアドレス
250 [email protected] … Sender ok
RCPT TO: [email protected]
←送信先メールアドレス
250 [email protected]… Recipient ok
DATA
Hello This is test mail.
.
←メール本文
250 PAA29357 Message accepted for delivery
QUIT
2003/10/20
←通信の終了
Network Architecture 2003f
メールヘッダでここまでわかる
利用した → Received: from mail.sfc.keio.ac.jp(mail.sfc.keio.ac.jp[133.27.4.120]
メールサーバ by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 7454162D38;
とその時刻
Mon, 27 May 2003 13:29:25 +0900 (JST)
利用した → Received: from jasmine (host123.sfc.wide.ad.jp [203.176.123.123])
メールサーバ by mail.sfc.keio.ac.jp (8.9.3/3.7W-SFC) with ESMTP id NAA02268;
とその時刻
Mon, 27 May 2001 13:29:51 +0900 (JST)
Date: Mon, 27 May 2001 13:30:44 +0900
From: “Hoge Hohe" <[email protected]>
To: [email protected],
Cc: [email protected]
Subject: インターネット概論[メールヘッダ]
← 使ったメールソフト
X-Mailer: Becky! ver. 2.00.03
jasmine
2003/10/20
MUA
mail.sfc.keio
shonan.sfc.wide
SMTPサーバ
SMTPサーバ
POPサーバ
Network Architecture 2003f
MUA
POP3; Post Office Protocol 3
POP3サーバー
POP3クライアント
POP開始要求
POP開始応答
ユーザ通知
ユーザ確認、パスワード要求
パスワード通知
ユーザ許可
DATA受信開始要求
メール数リスト通知
DATA送信要求
メール送信
メール受信終了通知
POPサービス終了
2003/10/20
Network Architecture 2003f
その他の配送方法
2003/10/20
Network Architecture 2003f
alias
• alias
– あるメールアドレスに対して別名をつけること
• 要望
– システム内の特別なユーザ(rootなど)に対するメールを誰かが受け取りた
い！
– 名前や役職などでも受け取れるようにしたい！
• 例えば
– taroというaliasに[email protected]というメールアドレスを設定すると
To: [email protected]
_____
送信
_____
2003/10/20
taro → t02XXXaa
sfc.keio.ac.jp
のメールサーバ
Network Architecture 2003f
t02XXXaaの
メールボックス
forward
• forward
– あるメールアドレスに届いたメールを別のメールアドレスに転送すること
• 要望
– メールアドレスが変わったので古い宛先に届くメールも新しい方で受信した
い！
– 複数のメールボックスを管理するのが面倒！
• 例えば
– [email protected]を[email protected]に転送するように設定すると
To: [email protected]
_____
送信
_____
To: [email protected]
_____
転送
_____
sfc.keio.ac.jp
のメールサーバ
2003/10/20
Network Architecture 2003f
hotmail.com
のメールサーバ
メーリングリスト
• mailing list
– 一つのメールアドレスを使って複数の人にメールを送る仕組み
• 要望
– たくさんの人にメールを送る時Toにいっぱい書くのは面倒！
– グループ全員のメールアドレスを知らなくてもメールを送りたい！
• 例えば
– [email protected]に[email protected]と[email protected]が登
録されている場合
To: [email protected]
To: [email protected]
_____
送信
_____
hotmail.comの
メールサーバ
sfc.keio.ac.jpの
メールサーバ
To: [email protected]
_____
_____ s02XXXaaの
メールボックス
2003/10/20
Network Architecture 2003f
_____
_____
taroの
メールボックス
POPとIMAP
2003/10/20
Network Architecture 2003f
POP(Post Office Protocol)
• サーバにあるメールボックスからメールを取り出すためのプロトコ
ル
• SMTP→メールボックスまでメールを届けてくれる→常時ネット
ワークに繋がっていないとメールが受け取れない
• POP→サーバに接続した時だけメールボックスにあるメールを
ローカルにコピーする
メールボックス
メールサーバ
SMTP
メールサーバ
POP
ユーザPC
•認証
•メールの取り込み
•メールの削除
など
メールサーバ
2003/10/20
Network Architecture 2003f
ローカル
メールボックス
POPの特徴
• 現在使われているのはPOP3(POP version3)
• テキストベースのプロトコル
– シンプルでわかりやすい、実装しやすい
– 処理負荷が低い
• ストア＆フォワード型
– サーバに接続されていない時はメールボックスに蓄積される
– 接続した時だけ溜まっているメールを取り込む
• 現在使われているメーラはほぼ全てPOP3に対応している
– BeckyとかOutlookExpressとか
• ポート番号は一般的にTCP110番を使用している
2003/10/20
Network Architecture 2003f
IMAP ; RFC2060
Internet Message Access Protocol
•
•
•
•
サーバ上にユーザフォルダを持つことが可能
メールの部分的な取りだし(添付ファイルなど)
グループでの共有メールフォルダを定義可能
メールサーバ上でのメールの検索が可能
アクセスするホストが変わるような環境
メールをグループで共有したい場合
2003/10/20
Network Architecture 2003f
IMAPの仕様
•
•
•
•
•
•
•
2003/10/20
複数、多階層のメールボックス構造
IMAPサーバへのアクセス認証
– SASLにより提供される数々の認証メソッド
パブリックなメールボックス
各メールボックス内のメールの状態管理
– メッセージフラグ
ネットワーク負荷の低減
– メールサマリしかダウンロードしない。欲しい
メールだけローカルにダウンロードする。（→モ
バイル環境に適応）
サーバサイドの検索機能
命令の並列処理
– 非同期なコマンド送信と結果受信が可能
Network Architecture 2003f
メールを利用したアプリケーション
2003/10/20
Network Architecture 2003f
メールを利用したアプリケーション
• メッセージを相手に送れるようになった！
– テキストのメッセージを、
– 指定したメールアドレスに送る。
• メールを利用してもっと色々なアプリケーションを
作れるんじゃないか！？
– テキスト以外の画像とかも送りたいよね！
– メールアドレスって人に対する確実な識別子だよね！
2003/10/20
Network Architecture 2003f
MIME (多目的なメールの拡張)
•
Multipurpose Internet Mail Extensions(RFC2045-2049)
主な役目は2つ：
1. バイナリデータをテキスト(ASCII形式)に変換し、
その種類(Media Type)やファイル名を付けて送る。
2. 1つのメールに複数のデータを含める（カプセリング）
Received: from mars.webserve.ne.jp (mars.webserve.ne.jp
[210.145.214.20])
by mercury.webserve.ne.jp (2.5 Build 2640 （Berkeley 8.8.6)
/8.8.4) with SMTP
id NAA0055 for <wenserve.ne.jp>; Sun, 10 May 1998
13:00:00 +0900
Received: by mars.webserve.ne.jp（Lotus SMTP MTA v.4.6.1
(569.2 2-6-1998)) id 49256600.0015F05B ; Sun, 10 May 1998
12:59:37 +0900
X-Lotus-FromDomain: WEBSERVE
From: [email protected]
To: [email protected]
Message-ID: <[email protected]>
Date: Sun, 10 May 1998 12:59:33 +0900
Subject: テストのメール
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Discription: inline
すべてテキスト（ASCII）で
書かれたメール
2003/10/20
種類：application/vnd.ms-powerpoint
元のファイル名：netarch.ppt
種類：text/html
元のファイル名：soi.html
Network Architecture 2003f
MIMEを利用したメールのヘッダ
Received: from mars.webserve.ne.jp (mars.webserve.ne.jp
[210.145.214.20])
by mercury.webserve.ne.jp (2.5 Build 2640 （Berkeley 8.8.6)
/8.8.4) with SMTP
id NAA0055 for <wenserve.ne.jp>; Sun, 10 May 1998
13:00:00 +0900
Received: by mars.webserve.ne.jp（Lotus SMTP MTA v.4.6.1
(569.2 2-6-1998)) id 49256600.0015F05B ; Sun, 10 May 1998
12:59:37 +0900
From: [email protected]
To: [email protected]
Message-ID: <[email protected]>
Date: Sun, 10 May 1998 12:59:33 +0900
Subject: =?ISO-2022-JP?B?GyRCJUY1OSVIJE41YSE8JWsbKEI=?=
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Discription: inline
2003/10/20
Network Architecture 2003f
MIMEによる符号化(BASE64)
• 3つの手順でバイナリデータをASCII文字にする。
1. 6 bits 分割
2. 10進表記
3. 文字化
(2進表記)
↓
(6ビット分割)
↓
(10進表示)
↓
(文字化)
01010011 00011001 01111111
010100 110001 110001 111111
20
49
49
63 ; 0-63
U
x
x
/
; 4 Bytes
ヘッダの多言語化
Subject: テストのメール
Subject: =?ISO-2022-JP?B?GyRCJUY1OSVIJE41YSE8JWsbKEI=?=
文字本体
“=?” ; begin
文字コード
“ISO-2202-JP”;
Type
意味
7bit
7ビットデータ
8bit
8ビットデータ
binary
バイナリデータ
BASE64
BASE64でエンコード
“B”; 符号化方法 →
2003/10/20
“=?” ; end
Network Architecture 2003f
本文の多言語化の一例（日本語）
• 原則では7bitで表せる文字(ASCII)しか送れない。
– そのままだと漢字とか送れないよ！？
– バイナリデータとして符号化して送る？
• ASCII文字と「切り替えて」漢字を送る文字体系
– ISO-2022-JP (JISコード)
– 「ここから漢字」と「ここまで漢字」で切り替える。
– 7bit×2文字で一つの漢字をあらわす。
• 本文はISO-2022-JPだとヘッダに書いておく：
Content‐Type:text/plain;charset=ISO-2022-JP
2003/10/20
Network Architecture 2003f
日本語の文字コード; RFC1468
・ ISO-2022-JP (JISコード)
RFC1468で定義されたコード；
電子メール/インターネットでの標準コード
(*) JUNETコード、7 bits JISコード
Content‐Type:text/plain;charset=ISO-2022-JP
・ EUCコード
Extended UNIX Code (UNIX系システム)
・ Shift-JISコード
JIS X 0208-1990 をいくつかシフトしたコード体系
MIMEによるカプセリング
メールにテキスト以外のデータを添付できる。
From: いしだ
To: しろくま
Subject: スライド
←ヘッダ
今週のスライドの資料です。
←本文（テキスト）
いしだ
←添付（画像）
2003/10/20
Network Architecture 2003f
メールアドレスという識別子
• メールアドレスは何を指すもの？
– IPアドレスとドメインネームはコンピュータの識別子
– メールアドレスは人を指す識別子だと言える。
• そのアドレスにメールを送れば、
– その人がメールを受け取れる状態ならばすぐに、
– 受け取れないならば受け取れるようになったときに
（だいたい）確実に連絡できる。
→ 本人確認とかに使えるんじゃないの？
2003/10/20
Network Architecture 2003f
これで色々できるようになったよね
• なんでも送れるようになった！
–
–
–
–
日本語、英語、様々な言語
画像、動画、音声
プログラムのデータファイル
プログラム本体！
2003/10/20
Network Architecture 2003f
メールを取り巻くアーキテクチャ
どこでも使える
Webメール
携帯メール
多数に告知
メーリングリスト
メールマガジン
Push型の通知機能として
オークションの落札通知
WWWサイトの更新通知
メール
個人の確認ができる
オークションサイト
分かり易いメッセージフォーマット
ビデオの予約
MLなどの入会・脱会
コミュニケーションツールとして
ポストペット
シンプルなアーキテクチャの上に、
次々と新しいアーキテクチャが付加されて行く構図
→アーキテクチャとしての成功
2003/10/20
Network Architecture 2003f
メールを使ったアプリケーション
• ポストペット
–
–
–
–
メールソフトとしてはごく普通の機能
ペットを育てるという遊びとしての機能
ユーモアやゲーム的要素を取り入れた
ユーザフレンドリーなインターフェース
2003/10/20
Network Architecture 2003f
メールを使ったアプリケーション
• Webメール
– 専用のソフトウェアがなくても利用できるシステム
– 自分のPCを持っていなくても使える
– PCが変わっても同じ環境が使える
2003/10/20
Network Architecture 2003f
メールを使ったアプリケーション
• 電子署名
– メールで商品売買やパスワードのやりとりをする場合
– 個人情報やなりすましなどセキュリティの問題
– メールの暗号化、本人であることの証明
2003/10/20
Network Architecture 2003f
メールを使ったアプリケーション
• 家電の制御
– メールを送るとテレビの予約録画ができる
– あらかじめメッセージフォーマットを決めておく
– テレビ以外にも自動運転などの制御が可能
2003/10/20
Network Architecture 2003f
メールを使ったアプリケーション
• 通知系
–
–
–
–
オークションで落札できたら通知
お気に入りのWebサイトが更新されたら通知
サーバが落ちたら通知
毎日温度計から今日の気温を通知
2003/10/20
Network Architecture 2003f
メールを使ったアプリケーション
• メールマガジン
–
–
–
–
既存の定期的な情報配信をより簡単に(DM→メール)
興味のあるものだけを選べる
個人でも作れる
技術的にも簡単(大量の同報通知)
2003/10/20
Network Architecture 2003f
電子メールのセキュリティ
2003/10/20
Network Architecture 2003f
通信の中ではどこが危険?
SMTPサーバ→SMTPサーバ
•不正なメールサーバからrelayとして使わ
れるの危険性
不正中継の防止
SMTPサーバ
SMTPサーバ
POPサーバ
SMTP
SMTP
メールソフト
POPサーバ→client
POP
•POPのパスワードを盗まれ
る危険性 パスワード盗聴の防止
メールソフト
client → client
はたして送り主や内容はホンモノか？
•内容の盗聴、改竄、なりすましの危険性
2003/10/20
Network Architecture 2003f
暗号化と認証
通信の中ではどこが危険?
• パスワードの盗聴
– メールボックスに接続するパスワードを盗まれる
• 不正中継
– spamの大量送信の踏み台に使われる
• メールの内容に対する攻撃
– 内容の盗聴
– 内容の改竄
2003/10/20
Network Architecture 2003f
パスワードの暗号化
• POP
– パスワードを暗号化せずそのまま送信
→ パスワードが盗聴される危険性
• APOP
– Challenge-Responseという暗号の一種を使う
– サーバ側から送ってきた「Challenge」とパスワードか
ら「Reponse」を生成する。
→ 盗み見てもパスワードそのものは分からない！
+OK QPOP (version 2.53-APOP-SFC) at mail starting. <13860.1010186867@mail>
USER taro
チャレンジ文字列
+OK Password required for taro
APOP taro 577b4d0f677850ef61fdcd981779294f
+OK taro has XXX messages (YYY octets)
レスポンス文字列
2003/10/20
Network Architecture 2003f
不正中継の防止
• 元々はどんな相手から来たメールだろうと中継する。
→ spamメールの中継に使われてしまう。
• 原則：「第三者のメールは中継しない」
– 自分が出したメールのみ外部に中継する。
• 送信者を認証する必要性
– 自分のドメイン宛てのメールのみ中継する。
– SMTP AUTH
• SMTPの接続時に、送信者を認証する。
– POP before SMTP
• 直前にPOPで接続することで、送信者のホストを認証
– RBL（Realtime Blackhole List）
• 「第三者中継を許すサーバー」のリストをデータベース化
• リストに載っている悪い子からのメールは受け取らない。
2003/10/20
Network Architecture 2003f
メールの内容を守る
• メールの内容の暗号化
– 秘匿性の保証
• 送信相手以外には内容を見られない
• メールの内容に対する署名
– 完全性の保証
• 配送途中で改竄・変化していない
– 差出人の保証
• 誰が送信したかを保証
– 事後否認の防止
• 確かにその人からメールを受け取ったという証拠
2003/10/20
Network Architecture 2003f
公開鍵暗号による暗号化メール
• 公開鍵暗号を使ったメールの暗号化
– 公開鍵/個人鍵の対を使う。
– S/MIMEとPGPの2つがある。
公開鍵
個人鍵
• 基本機能はこの2つ：
– 相手だけが読めるように暗号化したメール
– メールを自分が書いたことを証明する署名
• 不思議な暗号方式：公開鍵暗号
– 個人鍵で暗号化したら、それと対になる公開鍵でしか元に戻せない！
– 公開鍵で暗号化したら、それと対になる個人鍵でしか元に戻せない！
2003/10/20
Network Architecture 2003f
公開鍵の信頼性
• あらかじめ「公開鍵」を配っておく。
– 公開鍵は誰から来たもの？
– 実は別の人がでっち上げたものかも……
• S/MIME
• PGP
– 「証明機関」がみんなの公
開鍵を証明
– 草の根的にお互いの公開
鍵を信頼し合う
証明機関
信頼の輪
2003/10/20
Network Architecture 2003f
メールの暗号化
受信者の公開鍵
送信者
公開鍵で暗号化した
ら、それと対になる個
人鍵でしか元に戻せ
ない！
暗号エンジン
暗号エンジン
受信者
2003/10/20
Network Architecture 2003f
受信者の個人鍵
メールの署名
送信者の個人鍵
送信者
個人鍵で暗号化した
ら、それと対になる公
開鍵でしか元に戻せ
ない！
暗号エンジン
暗号エンジン
受信者
2003/10/20
Network Architecture 2003f
送信者の公開鍵
安全な電子メール環境
不正中継
証明機関
内容の盗聴/改竄
SMTP AUTH
POP before SMTP
パスワード盗聴
公開鍵の証明
SMTP
パスワード暗号化
APOP
暗号化メール
S/MIME, PGP
2003/10/20
Network Architecture 2003f
おしまい
2003/10/20
Network Architecture 2003f
使えそうな素材
2003/10/20
Network Architecture 2003f
誰が、どのアドレスを使うの？
• 世界中の人たちが、勝手にIPアドレスを使ったら
複数の人が同じIPアドレスを使ってしまうかも
このコンピュータは
1.1.1.1にしよう！
1.1.1.1に接続！
衝突
このコンピュータは
1.1.1.1にしよう！
1.1.1.1はどっちだろう…
2003/10/20
Network Architecture 2003f
電子メールシステム
電子メールシステム内のエージェント
(1) MUA; Mail User Agent
(2) MTA; Mail Transport Agent
(3) MDA; Mail Delivery Agent
電子メールシステムで使用するプロトコル
(1) SMTP ; Simple Mail Transport Protocol
(2) POP3 ; Post Office Protocol
(3) IMAP4 ; Internet Message Access Protocol
2003/10/20
Network Architecture 2003f
電子メールシステム
User
Mail
Send
SMTP
User
MUA
Mail
Read
MTA
SMTP
Input
Mail TCP
Connection
MDA
POP3
IMAP
2003/10/20
Output
Mail
Spool
Output
Mail TCP
Connection
Input
Mail
Spool
MTA
SMTP
MUA; Mail User Agent
MTA; Mail Transport Agent
MDA; Mail Delivery Agent
Network Architecture 2003f
E-mailもほぼ同じ
ただし、インターネット
に「中央」はいない
DNS
Sendmail
qmail
→MTA
メーラーソフト
SMTPサーバ同士で
リレーする。
POPサーバ
→MUA
サーバに保管された
メールを自分で取りに
行く
2003/10/20
Network Architecture 2003f
e-mailを送る
自分の
SMTPサーバ
②メールが届く
相手の
メールサーバ
SMTP
インターネット
SMTP
SMTP
①メールを出す
POP(APOP)
③メールを受信
自分
相手
ネットワークA
2003/10/20
ネットワークB
Network Architecture 2003f
ドメインネームの仕組み
• 国や組織名をつけてどこの誰だか分かるようにした
• www.sfc.keio.ac.jpで考えてみよう！
www . sfc . keio . ac . jp
WWW
サ
ー
バ
2003/10/20
湘
南
藤
沢
キ
ャ
ン
パ
ス
慶
應
義
塾
大
学
Network Architecture 2003f
学
術
機
関
日
本
ゾーンの管理と委任
jpドメイン
委任
管理
ac.jpドメイン
keio.ac.jpドメイン
委任
委任
sfc.keio.ac.jp
ドメイン
jpゾーン
管理
管理
管理
keio.ac.jpゾーン
ac.jpゾーン
sfc.keio.ac.jp
ゾーン
2003/10/20
Network Architecture 2003f
DNSによる名前の解決
人間
www.sfc.keio.ac.jp
www.sfc.keio.ac.jp
ネーム
サーバ
Web ブラウザ
133.27.4.212
133.27.4.212
Webサーバ
名前から値への
対応情報を提供
2003/10/20
Network Architecture 2003f
手紙の出し方を考えてみよう！
2003/10/20
Network Architecture 2003f
PGPとS/MIME
1. MIMEフォーマット
に整形
2. 作成したセッション
鍵で暗号化
暗号エンジン
送信者
3. セッション鍵を
秘密鍵で暗号化
4. 暗号化されたセッション鍵と
暗号化されたメールをエンコード
送信者の公開
鍵で復号化
送信者の鍵ペア
2003/10/20
受信者
Network Architecture 2003f