ネットワークアーキテクチャ 第 06 回 (2003/11/17)...
DESCRIPTION
ネットワークアーキテクチャ 第 06 回 (2003/11/17) 「メールのアーキテクチャ」. 村井 純. 09/29(1) 講義概要 / インターネットのアーキテクチャ 10/06(2) もうインターネットを分かっちゃおう 10/13 体育の日 10/20(3)DNS のアーキテクチャ 10/27(4) インターネット自動車のアーキテクチャ 11/03 文化の日 11/10(5)SOI のアーキテクチャ 11/17(6) メールのアーキテクチャ 11/24 勤労感謝の日の振替休日 - PowerPoint PPT PresentationTRANSCRIPT
2003/10/20 Network Architecture 2003f
2003 年度秋学期授業日程09/29 (1) 講義概要 / インターネットのアーキテクチャ10/06 (2) もうインターネットを分かっちゃおう10/13 体育の日10/20 (3) DNS のアーキテクチャ10/27 (4) インターネット自動車のアーキテクチャ11/03 文化の日11/10 (5) SOI のアーキテクチャ11/17 (6) メールのアーキテクチャ11/24 勤労感謝の日の振替休日11/26 (7) WWW のアーキテクチャ <-( 水
曜日 )12/01 (8) セキュリティーのアーキテクチャ12/08 (9) インターネット上の様々なサービスを見てみよう12/15 (10) P2P とオーバレイネットワーク12/22 (11) これからのネットワークアーキテクチャ(1)~ 冬休み01/08 (12) これからのネットワークアーキテクチャ(2)
<-( 木曜日 )01/12 成人の日01/19 (13) 最終試験
(最新情報は SoI* で確認してください)
今日はここ今日はここ
2003/10/20 Network Architecture 2003f
突然ですが心理テスト「大事な用件を伝える手紙に、不注意で切手を貼
らないでそのままポストに投函してしまいました。あなたはどうする?」
• A ポストの投函口からなんとか自分で取り出そうとする。
• B 集配の人を待って取り出してもらう。 • C 仕方がないとあきらめる。 • D 家に帰ってお詫びの手紙をかく。
» フジテレビ「めざましテレビ」より
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
E-mail もほぼ同じ
メールソフト
( 差出担当 )
ただし、インターネットに「中央」はいない
メールサーバ同士でリレー
SMTP サーバ
( 配送担当 )
サーバに保管されたメールを自分で取りに行く
POP サーバ
( 保管、分配 )
2003/10/20 Network Architecture 2003f
電子メールシステムの概要
MUA
MTA
MDA
使用するプロトコル
MUA
MTA
サーバ内メールスプール
Mail User Agent ( 差出担当 )メールソフト編集 → 宛名記入 → 投函
Mail Transport Agent ( 配送担当 )SMTP サーバ投函の受付 → 宛先付近のサーバへ配送
Mail Delivery Agent ( 分配担当 )サーバ内でユーザごとのメールスプールへ配送
Mail User Agent ( 受取担当 )メールソフト受け取る →表示
POP3 Post Office Protocol IMAP4 Internet Message Access Protocol
POP/IMAP サーバ → メールソフト(MDA → MUA)
SMTPSimple Mail Transport Protocol
メールソフト → SMTP サーバ(MUA → MTA)
SMTP サーバ → SMTP サーバ(MTA → MTA)
POP サーバまたは、 IMAP サーバサーバ上のメールスプールから、ユーザマシンへコピー
2003/10/20 Network Architecture 2003f
けっこう工程が多い。。。
• すべてのメーラがSMTPのサーバとクライアントを兼ねてれば、もっとシンプルじゃない?
» … でもこれだとうまく行かなかった。なぜ?
Taro 用メールスプール
読み書き
MTA
sirokuma 用メールスプール
MTA
MUA
SMTP
読み書きMUA
IMAP POP
個人マシン
POPサーバ
IMAPサーバ
個人マシン
POPサーバ
IMAPサーバ
masa 用 Ishi 用
MDA
2003/10/20 Network Architecture 2003f
理由その1• もともとは、 UNIX ワークステーション環境をベー
スに構築されていた。– ワークステーション上に多数のユーザ– ユーザは、ワークステーションに login してメールを読む
• ローカルへの配送は、宛先のメールスプールにデータを書き込むだけ
Hanako 用メールスプール
sirokuma 用メールスプール
Taro 用メールスプール
送る
読む 読む 読む
送る送る
UNIX ワークステーション
2003/10/20 Network Architecture 2003f
別のワークステーションのユーザにもメールを送りたい• ローカルへの配送と、リモートへの配送を区別
– リモートへの配送は、別のエージェントにしよう• MUA(Mail User Agent) 、 MTA(Mail Transfer Agent) の起
源
Hanako 用メールスプール
Taro 用メールスプール
読む 読む
MTA
sirokuma 用メールスプール
MTA
MUA MUA
ローカル配送 リモート配送
読むMUA
2003/10/20 Network Architecture 2003f
手元のマシンにメールをもってきたい
• 別のワークステーションからメールを読みたい• ワークステーション以外のマシンでメールを読みたい• POP の登場 → 個人マシン (PC など ) の利用が高まり、一般
的に!
Hanako 用メールスプール
Taro 用メールスプール
読み書き
MTA
sirokuma 用メールスプール
MTA
MUA
ローカル配送 リモート配送
MUA
読み書きMUA
POP POP
個人マシン 他のワークステーション
読むPOP サーバ POP サーバ
読み書き
2003/10/20 Network Architecture 2003f
理由その2• ダイアルアップが主だった時代だと・・・
Taro 用メールスプール
読み書き
MTA
sirokuma 用メールスプール
MTA
MUA
SMTP
読み書きMUA
IMAP POP
個人マシン
POPサーバ
IMAPサーバ
個人マシン
POPサーバ
IMAPサーバ
Ishi 用
MDA
インターネットモデム モデム
ダイアルアップ
相手が繋がっていないの
で送れない→ メールサーバが
必要
繋がっていればいらない?
2003/10/20 Network Architecture 2003f
MDA や IMAP の登場• MDA
– リモートから配送されたメールを、ローカルのメールスプールに分配する機能を別エージェントとして分離することもある (qmail など )
• Sendmail では、 MTA である sendmail がローカル配送まで受け持つ
• IMAP– サーバ上に保管したメールを複数のマシンから読むことを想定
Taro 用メールスプール
読み書き
MTA
sirokuma 用メールスプール
MTA
MUA
SMTP
読み書きMUA
IMAP POP
個人マシン
POPサーバ
メールサーバ
IMAPサーバ
個人マシン
POPサーバ
IMAPサーバ
masa 用 Ishi 用
MDA
2003/10/20 Network Architecture 2003f
ところで、さっきの心理テストの答え「大事な用件を伝える手紙に、不注意で切手を貼らないでそのままポストに
投函してしまいました。あなたはどうする?」→ これで「あなたの秘密のバレ方 」が分かるらしい
• A ポストの投函口からなんとか自分で取り出そうとする。→ 「態度でバレる人」
秘密を抱えると、落ち着かなくてソワソワ。なんだか怪しい人に変身してしまう。
• B 集配の人を待って取り出してもらう。 → 「友達からバレる人」
自分一人では抱えきれなくて、すぐに人に依存してしまう。すぐ信用して、友達に話してしまう。
• C 仕方がないとあきらめる。 → 「自分の口からバレる人」もともと秘密にしておくつもりがない。「ここだけの話なんだけど」と結局みんなにしゃべっている。
• D 家に帰ってお詫びの手紙をかく。 → 「秘密は守る人」秘密は守ってこそ秘密というもの。口がかたい。
2003/10/20 Network Architecture 2003f
メールアドレス
taro• メールサーバ上の
ユーザ名• メールサーバがユ
ーザを識別
sfc.keio.ac.jp• 個人のインターネット上の場所• ユーザが所属するメールサーバ
@
• メールのあて先• @を区切りとして、• 前半がユーザ名• 後半がドメイン名
2003/10/20 Network Architecture 2003f
配送先のメールサーバをどうやって知る?• DNS を使って、宛先ドメイン名の「 MX レコー
ド」を検索– [email protected]– 第三回 DNS のアーキテクチャ参照
自組織のSMTP サーバ
宛先ドメインのSMTP サーバ
MUAMUA
自組織のDNS サーバ
Q. sfc.wide.ad.jp のMX はどこ?
A. shonan.sfc. wide.ad.jp だ
よ
DNSツリー
sfc.wide ドメインを管理するDNS サーバ
Shonan.sfc.wide.ad.jp
実際に通信を開始する前にshonan の A レコードも検索
2003/10/20 Network Architecture 2003f
MX レコードの優先度• 複数のメールサーバを指定可能• 優先度の高いメールサーバに障害がある場合、次の優先
度のメールサーバに対してメールを配送
自組織のSMTP サーバ
shonan.sfc.wide.ad.jp
MUA MUA
自組織のDNS サーバ
Q. sfc.wide.ad.jp のMX はどこ?
A. shonan.sfc.wide.ad.jp が ( 優先度 5) backup.sfc.wide.ad.jp が ( 優先度 10) だよ
DNSツリー
sfc.wide ドメインを管理するDNS サーバ
backup.sfc.wide.ad.jp②じゃあ、こっちに
送ろ
①反応ないなぁ
2003/10/20 Network Architecture 2003f
SMTP; Simple Mail Transfer Protocol
メールソフト・送信 SMTP サーバ 受信 SMTP サーバ
Hello メッセージ応答
送信者通知許可
メール受信者通知許可
DATA通信開始要求許可
DATA 送信
メール受信確認終了通知
2003/10/20 Network Architecture 2003f
実際の流れー SMTP
% telnet mail.sfc.keio.ac.jp smtpConnected 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 youMAIL FROM: [email protected] ←送信元メールアドレス250 [email protected] … Sender okRCPT TO: [email protected] ←送信先メールアドレス250 [email protected]… Recipient okDATAHello This is test mail. ←メール本文.250 PAA29357 Message accepted for deliveryQUIT ←通信の終了
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 NAA022
68; Mon, 27 May 2001 13:29:51 +0900 (JST)Date: Mon, 27 May 2001 13:30:44 +0900From: “Hoge Hohe" <[email protected]>To: [email protected],Cc: [email protected]: インターネット概論 [ メールヘッダ ]X-Mailer: Becky! ver. 2.00.03
利用した →メールサーバとその時刻
利用した →メールサーバとその時刻
← 使ったメールソフト
SMTP サーバ SMTP サーバPOP サーバ
MUA MUA
mail.sfc.keio shonan.sfc.widejasmine
2003/10/20 Network Architecture 2003f
POP3; Post Office Protocol 3
POP3 クライアント POP3 サーバーPOP開始要求
POP開始応答ユーザ通知
ユーザ確認、パスワード要求パスワード通知
ユーザ許可DATA 受信開始要求
メール数リスト通知DATA 送信要求
メール送信メール受信終了通知
POP サービス終了
2003/10/20 Network Architecture 2003f
alias
• alias– あるメールアドレスに対して別名をつけること
• 要望– システム内の特別なユーザ (root など ) に対するメールを誰かが受け取
りたい!– 名前や役職などでも受け取れるようにしたい!
• 例えば– taro という alias に [email protected] というメールアドレス
を設定すると
To: [email protected]__________ sfc.keio.ac.jp
のメールサーバ
送信 t02XXXaa のメールボックス
taro → t02XXXaa
2003/10/20 Network Architecture 2003f
forward
• forward– あるメールアドレスに届いたメールを別のメールアドレスに転送すること
• 要望– メールアドレスが変わったので古い宛先に届くメールも新しい方で受信し
たい!– 複数のメールボックスを管理するのが面倒!
• 例えば– [email protected] を [email protected] に転送するように設定すると
To: [email protected]__________ sfc.keio.ac.jp
のメールサーバ
送信
To: [email protected]__________ 転送
hotmail.comのメールサーバ
2003/10/20 Network Architecture 2003f
メーリングリスト• mailing list
– 一つのメールアドレスを使って複数の人にメールを送る仕組み
• 要望– たくさんの人にメールを送る時 To にいっぱい書くのは面倒!– グループ全員のメールアドレスを知らなくてもメールを送りたい!
• 例えば– [email protected] に [email protected] と [email protected]
om が登録されている場合
To: [email protected]__________ 送信 sfc.keio.ac.jp の
メールサーバ
To: [email protected]__________
s02XXXaa のメールボックス
taro のメールボックス
hotmail.com のメールサーバ
To: [email protected]__________
2003/10/20 Network Architecture 2003f
POP(Post Office Protocol)• サーバにあるメールボックスからメールを取り出すためのプ
ロトコル• SMTP→ メールボックスまでメールを届けてくれる→常時ネ
ットワークに繋がっていないとメールが受け取れない• POP→ サーバに接続した時だけメールボックスにあるメール
をローカルにコピーする
メールサーバ メールサーバSMTP
SMTP
メールサーバ
SMTP
メールボックス ユーザ PCPOP
•認証•メールの取り込み•メールの削除など
ローカルメールボックス
2003/10/20 Network Architecture 2003f
POP の特徴• 現在使われているのは POP3(POP version3)• テキストベースのプロトコル
– シンプルでわかりやすい、実装しやすい– 処理負荷が低い
• ストア&フォワード型– サーバに接続されていない時はメールボックスに蓄積される– 接続した時だけ溜まっているメールを取り込む
• 現在使われているメーラはほぼ全て POP3 に対応している– Becky とか OutlookExpress とか
• ポート番号は一般的に TCP110番を使用している
2003/10/20 Network Architecture 2003f
IMAP ; RFC2060Internet Message Access Protocol
• サーバ上にユーザフォルダを持つことが可能• メールの部分的な取りだし ( 添付ファイルなど )• グループでの共有メールフォルダを定義可能• メールサーバ上でのメールの検索が可能
アクセスするホストが変わるような環境メールをグループで共有したい場合
2003/10/20 Network Architecture 2003f
IMAP の仕様
• 複数、多階層のメールボックス構造• IMAP サーバへのアクセス認証
– SASL により提供される数々の認証メソッド
• パブリックなメールボックス• 各メールボックス内のメールの状態管理
– メッセージフラグ• ネットワーク負荷の低減
– メールサマリしかダウンロードしない。欲しいメールだけローカルにダウンロードする。(→モバイル環境に適応)
• サーバサイドの検索機能• 命令の並列処理
– 非同期なコマンド送信と結果受信が可能
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 SMTPid 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 199812:59:37 +0900 X-Lotus-FromDomain: WEBSERVEFrom: [email protected] To: [email protected] Message-ID: <[email protected]> Date: Sun, 10 May 1998 12:59:33 +0900 Subject: テストのメール Mime-Version: 1.0Content-Type: text/plain; charset=iso-2022-jp Content-Discription: inline
2003/10/20 Network Architecture 2003f
2003年度秋学期授業日程09/29 (1) 講義概要/インターネットのアーキテクチャ10/06 (2) もうインターネットを分かっちゃおう10/13 体育の日10/20 (3) DNSのアーキテクチャ10/27 (4) インターネット自動車のアーキテクチャ11/03 文化の日11/10 (5) SOIのアーキテクチャ11/17 (6) メールのアーキテクチャ11/24 勤労感謝の日の振替休日11/26 (7) WWWのアーキテクチャ <-(水曜日)12/01 (8) セキュリティーのアーキテクチャ12/08 (9) インターネット上の様々なサービスを見てみよう12/15 (10) P2Pとオーバレイネットワーク12/22 (11) これからのネットワークアーキテクチャ(1)~ 冬休み01/08 (12) これからのネットワークアーキテクチャ(2) <-(木曜日)01/12 成人の日01/19 (13) 最終試験
(最新情報はSoI*で確認してください)
今日はここ今日はここ
種類: application/vnd.ms-powerpoint元のファイル名: hoge.ppt
種類: text/html元のファイル名: index.html
すべてテキスト( ASCII)で
書かれたメール
2003/10/20 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 SMTPid 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 199812: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.0Content-Type: text/plain; charset=iso-2022-jp Content-Discription: inline
MIME による符号化 (BASE64)• 3 つの手順でバイナリデータを ASCII 文字にする。
1. 6 bits 分割2. 10進表記3. 文字化
(2進表記 ) 01010011 00011001 01111111 ↓ (6ビット分割 ) 010100 110001 110001 111111 ↓ (10進表示 ) 20 49 49 63 ; 0-63 ↓ ( 文字化 ) U x x / ; 4 B
ytes
2003/10/20 Network Architecture 2003f
ヘッダの多言語化
Subject: テストのメール
Subject: =?ISO-2022-JP?B?GyRCJUY1OSVIJE41YSE8JWsbKEI=?=
“=?” ; begin “=?” ; end
文字コード“ISO-2202-JP”;
“B”; 符号化方法 →
文字本体
Type 意味
7bit 7ビットデータ
8bit 8ビットデータ
binary バイナリデータ
BASE64 BASE64 でエンコード
2003/10/20 Network Architecture 2003f
本文の多言語化の一例(日本語)
•原則では 7bit で表せる文字 (ASCII) しか送れない。–そのままだと漢字とか送れないよ!?– バイナリデータとして符号化して送る?
• ASCII 文字と「切り替えて」漢字を送る文字体系– ISO-2022-JP (JIS コード )– 「ここから漢字」と「ここまで漢字」で切り替える。– 7bit×2 文字で一つの漢字をあらわす。
• 本文は ISO-2022-JP だとヘッダに書いておく:Content‐Type:text/plain;charset=ISO-2022-JP
日本語の文字コード ; 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 をいくつかシフトしたコード体系
2003/10/20 Network Architecture 2003f
MIME によるカプセリング
メールにテキスト以外のデータを添付できる。
From: いしだTo: しろくまSubject: スライド
今週のスライドの資料です。
いしだ
2003/10/20 Network Architecture 2003f
2003年度秋学期授業日程09/29 (1) 講義概要/インターネットのアーキテクチャ10/06 (2) もうインターネットを分かっちゃおう10/13 体育の日10/20 (3) DNSのアーキテクチャ10/27 (4) インターネット自動車のアーキテクチャ11/03 文化の日11/10 (5) SOIのアーキテクチャ11/17 (6) メールのアーキテクチャ11/24 勤労感謝の日の振替休日11/26 (7) WWWのアーキテクチャ <-(水曜日)12/01 (8) セキュリティーのアーキテクチャ12/08 (9) インターネット上の様々なサービスを見てみよう12/15 (10) P2Pとオーバレイネットワーク12/22 (11) これからのネットワークアーキテクチャ(1)~ 冬休み01/08 (12) これからのネットワークアーキテクチャ(2) <-(木曜日)01/12 成人の日01/19 (13) 最終試験
(最新情報はSoI*で確認してください)
今日はここ今日はここ
2003/10/20 Network Architecture 2003f
電子メールシステムの概要
MUA
MTA
MDA
使用するプロトコル
MUA
MTA
サーバ内メールスプール
Mail User Agent(差出担当)メールソフト編集→宛名記入→投函
Mail Transport Agent (配送担当)SMTPサーバ投函の受付→ 宛先付近のサーバへ配送
Mail Delivery Agent (分配担当)サーバ内でユーザごとのメールスプールへ配送
Mail User Agent(受取担当)メールソフト受け取る→表示
POP3Post Office Protocol
IMAP4Internet Message Access Protocol
POP/IMAPサーバ→メールソフト(MDA →MUA)
SMTPSimple Mail Transport Protocol
→メールソフト SMTPサーバ(MUA →MTA)
SMTPサーバ→SMTPサーバ(MTA →MTA)
POPサーバまたは、IMAPサーバサーバ上のメールスプールから、ユーザマシンへコピー
← ヘッダ
← 本文(テキスト)
←添付(画像)
2003/10/20 Network Architecture 2003f
メールアドレスという識別子
• メールアドレスは何を指すもの?– IP アドレスとドメインネームはコンピュータの識
別子– メールアドレスは人を指す識別子だと言える。
•そのアドレスにメールを送れば、– その人がメールを受け取れる状態ならばすぐに、– 受け取れないならば受け取れるようになったとき
に
(だいたい)確実に連絡できる。→ 本人確認とかに使えるんじゃないの?
2003/10/20 Network Architecture 2003f
これで色々できるようになったよね
• なんでも送れるようになった!– 日本語、英語、様々な言語– 画像、動画、音声– プログラムのデータファイル– プログラム本体!
2003/10/20 Network Architecture 2003f
メールを取り巻くアーキテクチャ
メール
個人の確認ができるオークションサイト
コミュニケーションツールとしてポストペット
どこでも使えるWeb メール携帯メール
多数に告知メーリングリスト
メールマガジン
分かり易いメッセージフォーマットビデオの予約
ML などの入会・脱会
Push 型の通知機能としてオークションの落札通知WWW サイトの更新通知
シンプルなアーキテクチャの上に、次々と新しいアーキテクチャが付加されて行く構図
→ アーキテクチャとしての成功
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
通信の中ではどこが危険 ?
メールソフト
SMTP サーバ SMTP サーバ
POP サーバ
メールソフト
SMTP サーバ→ SMTP サーバ•不正なメールサーバから relay として使われる。•内容の盗聴•内容の改竄
client→SMTP サーバ
• 不正なクライアントから relay として使われる•内容の盗聴•内容の改竄
POP サーバ→ client
•POP のパスワードを盗まれる•内容の盗聴•内容の改竄
特
特特
SMTP
SMTP
POP
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 taroAPOP 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
公開鍵暗号による暗号化メール
•公開鍵暗号を使ったメールの暗号化方式– PGP と S/MIME– 公開鍵 / 個人鍵の対を使う
•基本機能はこの 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
PGP と S/MIME
1. MIME フォーマット に整形
2. 作成したセッション 鍵で暗号化
暗号エンジン 4. 暗号化されたセッション鍵と 暗号化されたメールをエンコード
3. セッション鍵を 秘密鍵で暗号化
送信者
受信者
送信者の公開鍵で復号化
送信者の鍵ペア
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
電子メールシステム
MUA
MTA
MTA
Output MailSpool
Input MailSpool
UserMailSend
UserMailRead
OutputMail TCPConnection
InputMail TCPConnection
MUA; Mail User AgentMTA; Mail Transport AgentMDA; Mail Delivery Agent
MDA
SMTP
POP3IMAP
SMTP
SMTP
2003/10/20 Network Architecture 2003f
E-mail もほぼ同じ
メーラーソフト
→MUA
ただし、インターネットに「中央」はいない
SMTP サーバ同士でリレーする。
Sendmailqmail
→MTA
DNS
サーバに保管されたメールを自分で取りに行く
POP サーバ
2003/10/20 Network Architecture 2003f
e-mail を送る
自分のSMTP サーバ
自分
①① メールを出すメールを出す
相手のメールサーバ②② メールが届くメールが届く
相手
③③ メールを受信メールを受信
SMTP
SMTP
SMTP
POP(APOP)
ネットワーク A ネットワーク B
インターネット
2003/10/20 Network Architecture 2003f
ドメインネームの仕組み• 国や組織名をつけてどこの誰だか分かるようにした• www.sfc.keio.ac.jp で考えてみよう!
www . sfc . keio . ac . jp 日
本学術機関
慶應義塾大学
湘南藤沢キャンパ
ス
WW
W
サーバ
2003/10/20 Network Architecture 2003f
sfc.keio.ac.jpゾーン
委任
管理
ゾーンの管理と委任jpドメイン
管理委任
ac.jpドメイン
keio.ac.jpドメイン
keio.ac.jpゾーン
管理
委任
ac.jpゾーン
管理sfc.keio.ac.jpドメイン
jpゾーン
2003/10/20 Network Architecture 2003f
DNS による名前の解決
Web サーバ
Web ブラウザ
人間
www.sfc.keio.ac.jpwww.sfc.keio.ac.jp
133.27.4.212 133.27.4.212
名前から値への対応情報を提供
ネームサーバ