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

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

09/29 (1) 講義概要/インターネットのアーキテクチャ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年度秋学期授業日程（最新情報はSoI*で確認してください）今日はここ Network Architecture 2003f

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

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

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

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

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

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

E-mailもほぼ同じ ただし、インターネットに「中央」はいない SMTPサーバ (配送担当) POPサーバ (保管、分配) メールソフト (差出担当) メールサーバ同士でリレーサーバに保管されたメールを自分で取りに行く 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 Mail Delivery Agent (分配担当) サーバ内でユーザごとのメールスプールへ配送 MDA サーバ内メールスプール POP3 Post Office Protocol IMAP4 Internet Message Access Protocol POP/IMAPサーバ → メールソフト (MDA → MUA) または、 IMAPサーバサーバ上のメールスプールから、ユーザマシンへコピー POPサーバ Mail User Agent (受取担当) メールソフト受け取る →表示 MUA Network Architecture 2003f

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

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

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

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

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

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

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

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

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

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

MXレコードの優先度 • 複数のメールサーバを指定可能 • 優先度の高いメールサーバに障害がある場合、次の優先度のメールサーバに対してメールを配送 DNSツリー sfc.wideドメインを管理する DNSサーバ自組織の 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 ②じゃあ、こっちに送ろ Network Architecture 2003f

SMTP; Simple Mail Transfer Protocol メールソフト・送信SMTPサーバ受信SMTPサーバ Helloメッセージ応答送信者通知許可メール受信者通知許可 DATA通信開始要求許可 DATA送信終了通知メール受信確認 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: t03xxxxx@sfc.keio.ac.jp　　 ←送信元メールアドレス 250 t00xxxxx@sfc.keio.ac.jp … Sender ok RCPT TO: hoge@sfc.wide.ad.jp　　 ←送信先メールアドレス 250 hoge@sfc.wide.ad.jp… Recipient ok DATA Hello This is test mail.　　　 ←メール本文 . 250 PAA29357 Message accepted for delivery QUIT　　　 ←通信の終了 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" <hoge@sfc.keio.ac.jp> To: dareka@sfc.wide.ad.jp, Cc: betujin@sfc.keio.ac.jp Subject: インターネット概論[メールヘッダ] X-Mailer: Becky! ver. 2.00.03 利用した　→ メールサーバとその時刻利用した　→ メールサーバとその時刻 ←　使ったメールソフト jasmine shonan.sfc.wide mail.sfc.keio SMTPサーバ SMTPサーバ POPサーバ MUA MUA Network Architecture 2003f

POP3; Post Office Protocol 3 POP3サーバー POP3クライアント POP開始要求 POP開始応答ユーザ通知ユーザ確認、パスワード要求パスワード通知ユーザ許可 DATA受信開始要求メール数リスト通知 DATA送信要求メール送信メール受信終了通知 POPサービス終了 Network Architecture 2003f

その他の配送方法 Network Architecture 2003f

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

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

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

alias Network Architecture 2003f

forward Network Architecture 2003f

メーリングリスト Network Architecture 2003f

POPとIMAP Network Architecture 2003f

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

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

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

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

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

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

MIME (多目的なメールの拡張) • Multipurpose Internet Mail Extensions(RFC2045-2049) 主な役目は2つ： • バイナリデータをテキスト(ASCII形式)に変換し、その種類(Media Type)やファイル名を付けて送る。 • 1つのメールに複数のデータを含める（カプセリング）種類：application/vnd.ms-powerpoint 元のファイル名：hoge.ppt 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: tsuzuki@webserve.ne.jp To: webtest@webserve.ne.jp Message-ID: <49256600.0015C880.00@mars.webserve.ne.jp> 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 種類：text/html 元のファイル名：index.html すべてテキスト（ASCII）で書かれたメール 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: tsuzuki@webserve.ne.jp To: webtest@webserve.ne.jp Message-ID: <49256600.0015C880.00@mars.webserve.ne.jp> 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 Network Architecture 2003f

MIMEによる符号化(BASE64) • 3つの手順でバイナリデータをASCII文字にする。 • 6 bits 分割 • 10進表記 • 文字化 • (2進表記) 01010011 00011001 01111111 • ↓ • (6ビット分割) 010100 110001 110001 111111 • ↓ • (10進表示) 20 49 49 63 ; 0-63 • ↓ • (文字化) U x x / ; 4 Bytes

ヘッダの多言語化 Subject: テストのメール Subject: =?ISO-2022-JP?B?GyRCJUY1OSVIJE41YSE8JWsbKEI=?= 文字本体 “=?” ; begin “=?” ; end 文字コード “ISO-2202-JP”; “B”; 符号化方法　→ Network Architecture 2003f

本文の多言語化の一例（日本語） • 原則では7bitで表せる文字(ASCII)しか送れない。 • そのままだと漢字とか送れないよ！？ • バイナリデータとして符号化して送る？ • ASCII文字と「切り替えて」漢字を送る文字体系 • ISO-2022-JP (JISコード) • 「ここから漢字」と「ここまで漢字」で切り替える。 • 7bit×2文字で一つの漢字をあらわす。 • 本文はISO-2022-JPだとヘッダに書いておく： Content‐Type:text/plain;charset=ISO-2022-JP 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: スライド ←ヘッダ今週のスライドの資料です。いしだ ←本文（テキスト） ←添付（画像） Network Architecture 2003f

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

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

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

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

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