ネットワークアーキテクチャ 第06回(2003/11/17) 「メールのアーキテクチャ」

Presentation on theme: "ネットワークアーキテクチャ 第06回(2003/11/17) 「メールのアーキテクチャ」"— Presentation transcript:

1 ネットワークアーキテクチャ 第06回(2003/11/17) 「メールのアーキテクチャ」
ネットワークアーキテクチャ 第06回(2003/11/17) 「メールのアーキテクチャ」 村井 純 2003/10/20 Network Architecture 2003f

2 Network Architecture 2003f
2003年度秋学期授業日程 （最新情報はSoI*で確認してください） 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) これからのネットワークアーキテクチャ（１） ～ 冬休み 01/08 (12) これからのネットワークアーキテクチャ（２） 　 <-(木曜日) 01/12 成人の日 01/19 (13) 最終試験 今日はここ 2003/10/20 Network Architecture 2003f

3 Network Architecture 2003f
突然ですが心理テスト 「大事な用件を伝える手紙に、不注意で切手を貼らないでそのままポストに投函してしまいました。 あなたはどうする？」 Ａ　ポストの投函口からなんとか自分で取り出そうとする。 Ｂ　集配の人を待って取り出してもらう。 Ｃ　仕方がないとあきらめる。 Ｄ　家に帰ってお詫びの手紙をかく。 フジテレビ「めざましテレビ」より 2003/10/20 Network Architecture 2003f

4 Network Architecture 2003f
答えは、後で。 というわけで、今日のテーマは 電子メールのアーキテクチャ 2003/10/20 Network Architecture 2003f

5 Network Architecture 2003f
今日のお品書き 電子メールのアーキテクチャ 電子メールのプロトコル（SMTPとPOP） メールの拡張 メールのセキュリティー 2003/10/20 Network Architecture 2003f

6 Network Architecture 2003f
手紙の出し方を考えてみよう！ どうやって運ぶ？ A：伝書鳩を常時飼っている B：風に任せる C：自らダッシュ！ 差出人 受取人 一番、確実でシンプル 2003/10/20 Network Architecture 2003f

7 Network Architecture 2003f
手紙の出し方を考えてみよう！ 差出人 配達員 受取人 でも、 自分で渡すのは大変！ →配達員にお願いしよう 配達員に手渡すのも面倒 →ポストを使おう 遠い場合はどうするの？ →郵便局間のリレー 配達した時に相手がいなかったら →私書箱を使おう 2003/10/20 Network Architecture 2003f

8 Network Architecture 2003f
で、今の仕組みが成り立っている 中央郵便局 中央郵便局 管轄郵便局 管轄郵便局 差出人 受取人 or 私書箱 2003/10/20 Network Architecture 2003f

9 Network Architecture 2003f
もほぼ同じ ただし、インターネットに「中央」はいない SMTPサーバ (配送担当) POPサーバ (保管、分配) メールソフト (差出担当) メールサーバ同士でリレー サーバに保管されたメールを自分で取りに行く 2003/10/20 Network Architecture 2003f

10 Network Architecture 2003f
電子メールシステムの概要 Mail User Agent (差出担当) メールソフト 編集 → 宛名記入 → 投函 使用するプロトコル MUA SMTP Simple Mail Transport Protocol メールソフト　→ SMTPサーバ (MUA → MTA) SMTPサーバ → SMTPサーバ (MTA → MTA) MTA Mail Transport Agent (配送担当) SMTPサーバ 投函の受付 →　 宛先付近のサーバへ配送 MTA MDA Mail Delivery Agent (分配担当) サーバ内でユーザごとの メールスプールへ配送 サーバ内メールスプール POP3 Post Office Protocol IMAP4 Internet Message Access Protocol POP/IMAPサーバ → メールソフト (MDA → MUA) または、 IMAPサーバ サーバ上のメールスプールから、 ユーザマシンへコピー POPサーバ Mail User Agent (受取担当) メールソフト 受け取る →表示 MUA 2003/10/20 Network Architecture 2003f

11 Network Architecture 2003f
けっこう工程が多い。。。 すべてのメーラがＳＭＴＰのサーバとクライアントを兼ねてれば、もっとシンプルじゃない？ …でもこれだとうまく行かなかった。なぜ？ MTA MTA MDA SMTP Taro用 メールスプール sirokuma用 メールスプール masa用 Ishi用 POP サーバ IMAP サーバ POP サーバ IMAP サーバ IMAP POP MUA MUA 読み書き 読み書き 個人マシン 個人マシン 2003/10/20 Network Architecture 2003f

12 Network Architecture 2003f
理由その１ もともとは、UNIXワークステーション環境をベースに構築されていた。 ワークステーション上に多数のユーザ ユーザは、ワークステーションにloginしてメールを読む ローカルへの配送は、宛先のメールスプールにデータを書き込むだけ UNIXワークステーション 送る 送る 送る Taro用 メールスプール Hanako用 メールスプール sirokuma用 メールスプール 読む 読む 読む 2003/10/20 Network Architecture 2003f

13 別のワークステーションのユーザにもメールを送りたい
ローカルへの配送と、リモートへの配送を区別 リモートへの配送は、別のエージェントにしよう MUA(Mail User Agent)、MTA(Mail Transfer Agent)の起源 ローカル配送 リモート配送 MTA MTA sirokuma用 メールスプール Taro用 メールスプール Hanako用 メールスプール 読む 読む 読む MUA MUA MUA 2003/10/20 Network Architecture 2003f

14 Network Architecture 2003f
手元のマシンにメールをもってきたい 別のワークステーションからメールを読みたい ワークステーション以外のマシンでメールを読みたい POPの登場 → 個人マシン(PCなど)の利用が高まり、一般的に！ ローカル配送 リモート配送 MTA MTA Taro用 メールスプール sirokuma用 メールスプール Hanako用 メールスプール POPサーバ POPサーバ 読む POP POP MUA MUA MUA 読み書き 読み書き 読み書き 個人マシン 他のワークステーション 2003/10/20 Network Architecture 2003f

15 Network Architecture 2003f
理由その２ ダイアルアップが主だった時代だと・・・ モデム モデム ダイアルアップ インターネット MTA MDA MTA SMTP Taro用 メールスプール sirokuma用 メールスプール 相手が 繋がっていないので送れない →メールサーバが必要 Ishi用 POP サーバ IMAP サーバ POP サーバ IMAP サーバ IMAP POP MUA MUA 読み書き 読み書き 繋がっていればいらない？ 個人マシン 個人マシン 2003/10/20 Network Architecture 2003f

16 Network Architecture 2003f
MDAやIMAPの登場 MDA リモートから配送されたメールを、ローカルのメールスプールに分配する機能を別エージェントとして分離することもある(qmailなど) Sendmailでは、MTAであるsendmailがローカル配送まで受け持つ IMAP サーバ上に保管したメールを複数のマシンから読むことを想定 メールサーバ MTA MTA MDA SMTP Taro用 メールスプール sirokuma用 メールスプール masa用 Ishi用 POP サーバ IMAP サーバ POP サーバ IMAP サーバ IMAP POP MUA MUA 読み書き 読み書き 個人マシン 個人マシン 2003/10/20 Network Architecture 2003f

17 Network Architecture 2003f
ところで、さっきの心理テストの答え 「大事な用件を伝える手紙に、不注意で切手を貼らないでそのままポストに投函してしまいました。あなたはどうする？」 →これで「あなたの秘密のバレ方 」が分かるらしい Ａ　ポストの投函口からなんとか自分で取り出そうとする。 →「態度でバレる人」 秘密を抱えると、落ち着かなくてソワソワ。なんだか怪しい人に変身してしまう。 Ｂ　集配の人を待って取り出してもらう。 →「友達からバレる人」 自分一人では抱えきれなくて、すぐに人に依存してしまう。 すぐ信用して、友達に話してしまう。 Ｃ　仕方がないとあきらめる。 →「自分の口からバレる人」 もともと秘密にしておくつもりがない。「ここだけの話なんだけど」と結局みんなにしゃべっている。 Ｄ　家に帰ってお詫びの手紙をかく。 →「秘密は守る人」 秘密は守ってこそ秘密というもの。口がかたい。 2003/10/20 Network Architecture 2003f

18 Network Architecture 2003f
電子メールの配送プロトコル 2003/10/20 Network Architecture 2003f

19 Network Architecture 2003f
メールアドレス メールのあて先 @を区切りとして、 前半がユーザ名 後半がドメイン名 @ taro メールサーバ上のユーザ名 メールサーバがユーザを識別 sfc.keio.ac.jp 個人のインターネット上の場所 ユーザが所属するメールサーバ 2003/10/20 Network Architecture 2003f

20 Network Architecture 2003f
配送先のメールサーバをどうやって知る？ DNSを使って、宛先ドメイン名の「MXレコード」を検索 第三回DNSのアーキテクチャ参照 DNSツリー 自組織の DNSサーバ sfc.wideドメインを管理する DNSサーバ Q. sfc.wide.ad.jpの MXはどこ？ shonan.sfc. wide.ad.jpだよ Shonan.sfc.wide.ad.jp 自組織の SMTPサーバ 宛先ドメインの SMTPサーバ MUA 実際に通信を開始する前に shonanのAレコードも検索 MUA 2003/10/20 Network Architecture 2003f

21 Network Architecture 2003f
MXレコードの優先度 複数のメールサーバを指定可能 優先度の高いメールサーバに障害がある場合、次の優先度のメールサーバに対してメールを配送 DNSツリー 自組織の DNSサーバ sfc.wideドメインを管理する DNSサーバ Q. sfc.wide.ad.jpの MXはどこ？ A. shonan.sfc.wide.ad.jpが(優先度 5) backup.sfc.wide.ad.jpが(優先度10)だよ shonan.sfc. wide.ad.jp ①反応ないなぁ 自組織の SMTPサーバ backup.sfc. wide.ad.jp MUA MUA ②じゃあ、こっちに送ろ 2003/10/20 Network Architecture 2003f

22 SMTP; Simple Mail Transfer Protocol
メールソフト・ 送信SMTPサーバ 受信SMTPサーバ Helloメッセージ 応答 送信者通知 許可 メール受信者通知 許可 DATA通信開始要求 許可 DATA送信 終了通知 メール受信確認 2003/10/20 Network Architecture 2003f

23 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: ←送信元メールアドレス 250 … Sender ok RCPT TO: ←送信先メールアドレス 250 Recipient ok DATA Hello This is test mail.　　　 ←メール本文 . 250 PAA29357 Message accepted for delivery QUIT　　　 ←通信の終了 2003/10/20 Network Architecture 2003f

24 Network Architecture 2003f
メールヘッダでここまでわかる 利用した　→ メールサーバ とその時刻 Received: from mail.sfc.keio.ac.jp(mail.sfc.keio.ac.jp[ ] by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id D38; Mon, 27 May :29: (JST) Received: from jasmine (host123.sfc.wide.ad.jp [ ]) by mail.sfc.keio.ac.jp (8.9.3/3.7W-SFC) with ESMTP id NAA02268; Mon, 27 May :29: (JST) Date: Mon, 27 May :30: From: “Hoge Hohe" To: Cc: Subject: インターネット概論[メールヘッダ] X-Mailer: Becky! ver 利用した　→ メールサーバ とその時刻 ←　使ったメールソフト jasmine mail.sfc.keio shonan.sfc.wide SMTPサーバ SMTPサーバ POPサーバ MUA MUA 2003/10/20 Network Architecture 2003f

25 POP3; Post Office Protocol 3
ユーザ通知 ユーザ確認、パスワード要求 パスワード通知 ユーザ許可 DATA受信開始要求 メール数リスト通知 DATA送信要求 メール送信 メール受信終了通知 POPサービス終了 2003/10/20 Network Architecture 2003f

26 Network Architecture 2003f
その他の配送方法 2003/10/20 Network Architecture 2003f

27 Network Architecture 2003f
alias alias あるメールアドレスに対して別名をつけること 要望 システム内の特別なユーザ(rootなど)に対するメールを誰かが受け取りたい！ 名前や役職などでも受け取れるようにしたい！ 例えば taro → t02XXXaa To: _____ t02XXXaaの メールボックス 送信 sfc.keio.ac.jp のメールサーバ 2003/10/20 Network Architecture 2003f

28 forward forward 要望 例えば あるメールアドレスに届いたメールを別のメールアドレスに転送すること
メールアドレスが変わったので古い宛先に届くメールも新しい方で受信したい！ 複数のメールボックスを管理するのが面倒！ 例えば To: _____ To: _____ sfc.keio.ac.jp のメールサーバ hotmail.com のメールサーバ 送信 転送 2003/10/20 Network Architecture 2003f

29 メーリングリスト mailing list 要望 例えば 一つのメールアドレスを使って複数の人にメールを送る仕組み
たくさんの人にメールを送る時Toにいっぱい書くのは面倒！ グループ全員のメールアドレスを知らなくてもメールを送りたい！ 例えば hotmail.comの メールサーバ To: _____ To: _____ taroの メールボックス sfc.keio.ac.jpの メールサーバ 送信 To: _____ s02XXXaaの メールボックス 2003/10/20 Network Architecture 2003f

30 Network Architecture 2003f
alias 2003/10/20 Network Architecture 2003f

31 Network Architecture 2003f
forward 2003/10/20 Network Architecture 2003f

32 Network Architecture 2003f
メーリングリスト 2003/10/20 Network Architecture 2003f

33 Network Architecture 2003f
POPとIMAP 2003/10/20 Network Architecture 2003f

34 POP(Post Office Protocol)
サーバにあるメールボックスからメールを取り出すためのプロトコル SMTP→メールボックスまでメールを届けてくれる→常時ネットワークに繋がっていないとメールが受け取れない POP→サーバに接続した時だけメールボックスにあるメールをローカルにコピーする ユーザPC メールボックス ローカル メールボックス メールサーバ メールサーバ POP SMTP 認証 メールの取り込み メールの削除 など SMTP SMTP メールサーバ 2003/10/20 Network Architecture 2003f

35 Network Architecture 2003f
POPの特徴 現在使われているのはPOP3(POP version3) テキストベースのプロトコル シンプルでわかりやすい、実装しやすい 処理負荷が低い ストア＆フォワード型 サーバに接続されていない時はメールボックスに蓄積される 接続した時だけ溜まっているメールを取り込む 現在使われているメーラはほぼ全てPOP3に対応している BeckyとかOutlookExpressとか ポート番号は一般的にTCP110番を使用している 2003/10/20 Network Architecture 2003f

36 IMAP ; RFC2060 Internet Message Access Protocol
サーバ上にユーザフォルダを持つことが可能 メールの部分的な取りだし(添付ファイルなど) グループでの共有メールフォルダを定義可能 メールサーバ上でのメールの検索が可能 アクセスするホストが変わるような環境 メールをグループで共有したい場合 2003/10/20 Network Architecture 2003f

37 Network Architecture 2003f
IMAPの仕様 複数、多階層のメールボックス構造 IMAPサーバへのアクセス認証 SASLにより提供される数々の認証メソッド パブリックなメールボックス 各メールボックス内のメールの状態管理 メッセージフラグ ネットワーク負荷の低減 メールサマリしかダウンロードしない。欲しいメールだけローカルにダウンロードする。（→モバイル環境に適応） サーバサイドの検索機能 命令の並列処理 非同期なコマンド送信と結果受信が可能 2003/10/20 Network Architecture 2003f

38 Network Architecture 2003f
メールを利用したアプリケーション 2003/10/20 Network Architecture 2003f

39 Network Architecture 2003f
メールを利用したアプリケーション メッセージを相手に送れるようになった！ テキストのメッセージを、 指定したメールアドレスに送る。 メールを利用してもっと色々なアプリケーションを作れるんじゃないか！？ テキスト以外の画像とかも送りたいよね！ メールアドレスって人に対する確実な識別子だよね！ 2003/10/20 Network Architecture 2003f

40 Network Architecture 2003f
MIME (多目的なメールの拡張) Multipurpose Internet Mail Extensions(RFC ) 主な役目は2つ： バイナリデータをテキスト(ASCII形式)に変換し、 その種類(Media Type)やファイル名を付けて送る。 1つのメールに複数のデータを含める（カプセリング） 種類：application/vnd.ms-powerpoint 元のファイル名：hoge.ppt Received: from mars.webserve.ne.jp (mars.webserve.ne.jp [ ]) 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: Received: by mars.webserve.ne.jp（Lotus SMTP MTA v.4.6.1 ( )) id F05B ; Sun, 10 May 1998 12:59: X-Lotus-FromDomain: WEBSERVE From: To: Message-ID: Date: Sun, 10 May :59: Subject: テストのメール Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Discription: inline 種類：text/html 元のファイル名：index.html すべてテキスト（ASCII）で 書かれたメール 2003/10/20 Network Architecture 2003f

41 Network Architecture 2003f
MIMEを利用したメールのヘッダ Received: from mars.webserve.ne.jp (mars.webserve.ne.jp [ ]) 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: Received: by mars.webserve.ne.jp（Lotus SMTP MTA v.4.6.1 ( )) id F05B ; Sun, 10 May 1998 12:59: From: To: Message-ID: Date: Sun, 10 May :59: 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

42 MIMEによる符号化(BASE64) 3つの手順でバイナリデータをASCII文字にする。 6 bits 分割 10進表記 文字化
(2進表記) ↓ (6ビット分割) (10進表示) ; (文字化) U x x / ; 4 Bytes

43 Network Architecture 2003f
ヘッダの多言語化 Subject: テストのメール Subject: =?ISO-2022-JP?B?GyRCJUY1OSVIJE41YSE8JWsbKEI=?= “=?” ; begin 文字本体 “=?” ; end 文字コード “ISO-2202-JP”; Type 意味 7bit 7ビットデータ 8bit 8ビットデータ binary バイナリデータ BASE64 BASE64でエンコード “B”; 符号化方法　→ 2003/10/20 Network Architecture 2003f

44 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

45 日本語の文字コード; 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 をいくつかシフトしたコード体系

46 Network Architecture 2003f
MIMEによるカプセリング メールにテキスト以外のデータを添付できる。 From:　いしだ To:　しろくま Subject: スライド ←ヘッダ 今週のスライドの資料です。 いしだ ←本文（テキスト） ←添付（画像） 2003/10/20 Network Architecture 2003f

47 Network Architecture 2003f
メールアドレスという識別子 メールアドレスは何を指すもの？ IPアドレスとドメインネームはコンピュータの識別子 メールアドレスは人を指す識別子だと言える。 そのアドレスにメールを送れば、 その人がメールを受け取れる状態ならばすぐに、 受け取れないならば受け取れるようになったときに 　（だいたい）確実に連絡できる。 →　本人確認とかに使えるんじゃないの？ 2003/10/20 Network Architecture 2003f

48 Network Architecture 2003f
これで色々できるようになったよね なんでも送れるようになった！ 日本語、英語、様々な言語 画像、動画、音声 プログラムのデータファイル プログラム本体！ 2003/10/20 Network Architecture 2003f

49 Network Architecture 2003f
メールを取り巻くアーキテクチャ どこでも使える Webメール 携帯メール 多数に告知 メーリングリスト メールマガジン メール 分かり易いメッセージフォーマット ビデオの予約 MLなどの入会・脱会 Push型の通知機能として オークションの落札通知 WWWサイトの更新通知 個人の確認ができる オークションサイト コミュニケーションツールとして ポストペット シンプルなアーキテクチャの上に、 次々と新しいアーキテクチャが付加されて行く構図 →アーキテクチャとしての成功 2003/10/20 Network Architecture 2003f

50 Network Architecture 2003f
メールを使ったアプリケーション ポストペット メールソフトとしてはごく普通の機能 ペットを育てるという遊びとしての機能 ユーモアやゲーム的要素を取り入れた ユーザフレンドリーなインターフェース 2003/10/20 Network Architecture 2003f

51 Network Architecture 2003f
メールを使ったアプリケーション Webメール 専用のソフトウェアがなくても利用できるシステム 自分のPCを持っていなくても使える PCが変わっても同じ環境が使える 2003/10/20 Network Architecture 2003f

52 Network Architecture 2003f
メールを使ったアプリケーション 電子署名 メールで商品売買やパスワードのやりとりをする場合 個人情報やなりすましなどセキュリティの問題 メールの暗号化、本人であることの証明 2003/10/20 Network Architecture 2003f

53 Network Architecture 2003f
メールを使ったアプリケーション 家電の制御 メールを送るとテレビの予約録画ができる あらかじめメッセージフォーマットを決めておく テレビ以外にも自動運転などの制御が可能 2003/10/20 Network Architecture 2003f

54 Network Architecture 2003f
メールを使ったアプリケーション 通知系 オークションで落札できたら通知 お気に入りのWebサイトが更新されたら通知 サーバが落ちたら通知 毎日温度計から今日の気温を通知 2003/10/20 Network Architecture 2003f

55 Network Architecture 2003f
メールを使ったアプリケーション メールマガジン 既存の定期的な情報配信をより簡単に(DM→メール) 興味のあるものだけを選べる 個人でも作れる 技術的にも簡単(大量の同報通知) 2003/10/20 Network Architecture 2003f

56 Network Architecture 2003f
電子メールのセキュリティ 2003/10/20 Network Architecture 2003f

57 Network Architecture 2003f
通信の中ではどこが危険? SMTPサーバ→SMTPサーバ 不正なメールサーバからrelayとして使われる。 内容の盗聴 内容の改竄 特 SMTPサーバ SMTPサーバ POPサーバ SMTP SMTP POP メールソフト client→SMTPサーバ 不正なクライアントからrelayとして使われる 内容の盗聴 内容の改竄 POPサーバ→client POPのパスワードを盗まれる 内容の盗聴 内容の改竄 メールソフト 特 特 2003/10/20 Network Architecture 2003f

58 Network Architecture 2003f
通信の中ではどこが危険? パスワードの盗聴 メールボックスに接続するパスワードを盗まれる 不正中継 spamの大量送信の踏み台に使われる メールの内容に対する攻撃 内容の盗聴 内容の改竄 2003/10/20 Network Architecture 2003f

59 Network Architecture 2003f
パスワードの暗号化 POP パスワードを暗号化せずそのまま送信 　→　パスワードが盗聴される危険性 APOP Challenge-Responseという暗号の一種を使う サーバ側から送ってきた「Challenge」とパスワードから「Reponse」を生成する。 　→　盗み見てもパスワードそのものは分からない！ +OK QPOP (version 2.53-APOP-SFC) at mail starting. USER　taro +OK Password required for taro APOP taro 577b4d0f677850ef61fdcd f +OK taro has XXX messages (YYY octets) チャレンジ文字列 レスポンス文字列 2003/10/20 Network Architecture 2003f

60 Network Architecture 2003f
不正中継の防止 元々はどんな相手から来たメールだろうと中継する。 　→　spamメールの中継に使われてしまう。 原則：「第三者のメールは中継しない」 自分が出したメールのみ外部に中継する。 送信者を認証する必要性 自分のドメイン宛てのメールのみ中継する。 SMTP　AUTH SMTPの接続時に、送信者を認証する。 POP before SMTP 直前にPOPで接続することで、送信者のホストを認証 RBL（Realtime Blackhole List） 「第三者中継を許すサーバー」のリストをデータベース化 リストに載っている悪い子からのメールは受け取らない。 2003/10/20 Network Architecture 2003f

61 Network Architecture 2003f
メールの内容を守る メールの内容の暗号化 秘匿性の保証 送信相手以外には内容を見られない メールの内容に対する署名 完全性の保証 配送途中で改竄・変化していない 差出人の保証 誰が送信したかを保証 事後否認の防止 確かにその人からメールを受け取ったという証拠 2003/10/20 Network Architecture 2003f

62 Network Architecture 2003f
公開鍵暗号による暗号化メール 公開鍵暗号を使ったメールの暗号化方式 PGPとS/MIME 公開鍵/個人鍵の対を使う 基本機能はこの2つ： 相手だけが読めるように暗号化したメール メールを自分が書いたことを証明する署名 あらかじめ「公開鍵」を配っておく。 公開鍵は誰から来たもの？ 実は別の人がでっち上げたものかも…… 2003/10/20 Network Architecture 2003f

63 Network Architecture 2003f
公開鍵の信用性 S/MIME 「証明機関」がみんなの公開鍵を証明 PGP 草の根的にお互いの公開鍵を信頼し合う 証明機関 信頼の輪 2003/10/20 Network Architecture 2003f

64 Network Architecture 2003f
メールの暗号化 公開鍵で暗号化したら、それと対になる個人鍵でしか元に戻せない！ 受信者の公開鍵 送信者 暗号エンジン 受信者 受信者の個人鍵 2003/10/20 Network Architecture 2003f

65 Network Architecture 2003f
メールの署名 個人鍵で暗号化したら、それと対になる公開鍵でしか元に戻せない！ 送信者の個人鍵 送信者 暗号エンジン 受信者 送信者の公開鍵 2003/10/20 Network Architecture 2003f

66 Network Architecture 2003f
PGPとS/MIME 1. MIMEフォーマット に整形 2. 作成したセッション 鍵で暗号化 3. セッション鍵を 秘密鍵で暗号化 受信者 暗号エンジン 送信者の公開 鍵で復号化 4. 暗号化されたセッション鍵と 暗号化されたメールをエンコード 送信者 送信者の鍵ペア 2003/10/20 Network Architecture 2003f

67 Network Architecture 2003f
おしまい 2003/10/20 Network Architecture 2003f

68 Network Architecture 2003f
使えそうな素材 2003/10/20 Network Architecture 2003f

69 Network Architecture 2003f
誰が、どのアドレスを使うの？ 世界中の人たちが、勝手にIPアドレスを使ったら複数の人が同じIPアドレスを使ってしまうかも このコンピュータは にしよう！ に接続！ 衝突 このコンピュータは にしよう！ はどっちだろう… 2003/10/20 Network Architecture 2003f

70 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

71 Network Architecture 2003f
電子メールシステム User Mail Send Output Mail TCP Connection MUA SMTP MDA Output Mail Spool MTA SMTP User Mail Read Input Mail TCP Connection Input Mail Spool MTA SMTP POP3 IMAP MUA; Mail User Agent MTA; Mail Transport Agent MDA; Mail Delivery Agent 2003/10/20 Network Architecture 2003f

72 Network Architecture 2003f
もほぼ同じ ただし、インターネットに「中央」はいない DNS Sendmail qmail →MTA SMTPサーバ同士でリレーする。 POPサーバ メーラーソフト →MUA サーバに保管されたメールを自分で取りに行く 2003/10/20 Network Architecture 2003f

73 Network Architecture 2003f
を送る 相手の メールサーバ 自分の SMTPサーバ ②メールが届く SMTP SMTP インターネット SMTP POP(APOP) ①メールを出す ③メールを受信 自分 相手 ネットワークA ネットワークB 2003/10/20 Network Architecture 2003f

74 Network Architecture 2003f
ドメインネームの仕組み 国や組織名をつけてどこの誰だか分かるようにした www　. sfc　.　keio　.　ac　.　jp WWWサーバ 湘南藤沢キャンパス 慶應義塾大学 学術機関 日本 2003/10/20 Network Architecture 2003f

75 Network Architecture 2003f
ゾーンの管理と委任 jpドメイン 委任 ac.jpドメイン 管理 keio.ac.jpドメイン 委任 委任 jpゾーン 管理 sfc.keio.ac.jp ドメイン 管理 管理 keio.ac.jpゾーン ac.jpゾーン sfc.keio.ac.jpゾーン 2003/10/20 Network Architecture 2003f

76 Network Architecture 2003f
DNSによる名前の解決 人間 ネーム サーバ Web ブラウザ Webサーバ 名前から値への 対応情報を提供 2003/10/20 Network Architecture 2003f

77 Network Architecture 2003f
手紙の出し方を考えてみよう！ 2003/10/20 Network Architecture 2003f