用語の定義
計算機 コンピュータのこと データ 計算機で扱う情報のこと 文字（テキスト），画像，音声など 通信 計算機間でデータをやり取りすること ネットワーク 複数の計算機が接続され，通信を行うことができる仕組み 送信，受信 データを送ること，受け取ること サーバ 他の計算機にサービスを提供する計算機 クライアント サーバからサービスを受ける計算機 ユーザ 計算機を使う人間今回のテーマ
電子メールの仕組みはどうなっているのか？ 電子メールを上手に使う方法は？ 電子メールによってコミュニケーションが変わった 今やプライベートな連絡だけでなく， ビジネスにも不可欠な道具になった 距離の壁を越える： 地球の裏側の人と無料で通信できる 時間の壁を越える： ほとんどの場合数分以内に届く 通信の非同期性： お互いのタイミングを合わせなくて良い今回のテーマ
迷惑メールが未だになくならないのはなぜか？ 1日に何百通という 迷惑メールがやってくる ちなみにビルゲイツの受け取る 迷惑メールは 1日400万通だとかメールアドレス
[email protected] [email protected] [email protected] 所属している組織 入っているプロバイダ 携帯の会社 “ユーザ名@ｘｘｘｘ” という形 @以下はいくつかのパターンがある [email protected] [email protected] [email protected]メールを送るときの問題
メールを相手のパソコンに送るには 相手のパソコンのIPアドレスが分からないといけない 分かっているのはメールアドレスのみ [email protected] 相手のパソコンの電源が切れていると メールは送れないメールサーバ
そこで，メールの配送を受け持つ計算機を用意する →メールサーバという メールアドレスによって，担当のメールサーバが異なる [email protected]担当 [email protected]担当 メールサーバは メールアドレスから， 担当のメールサーバのIPアドレスを調べてメールとDNS
というわけで，
DNS(Domain Name System)を使う
実はDNSでは計算機の名前のほかに メールの配送先についても管理している メールサーバは メールアドレスから，担当のメールサーバの IPアドレスをどうやって調べるか？ [email protected] → 210.150.10.75 メールアドレス 担当メールサーバの IPアドレス こういうのどこかで見たような．．．
メールはどうやって送られる
か？
自分の担当の メールサーバに メールを送る 自分の担当の メールサーバから メールを受け取る star.odn.ne.jp担当の メールサーバに メールがたまる ネームサーバに star.odn.ne.jp担当の メールサーバの IPアドレスを聞く star.odn.ne.jp担当の メールサーバに メールを送る SMTPという プロトコル SMTPという プロトコル POP3という プロトコルメールの中継
メールは通常相手のメールサーバに直接送られるが 他のメールサーバに中継される場合もある メールの中継が行われるとき • メールサーバの分散 • メーリングリストメールサーバの分散
daikigyo.co.jpの 代表メールサーバ 部門ごとにメールサーバを用意する 営業部のメールサーバ 開発部の メールサーバ 人事部の メールサーバ メールアドレスによって 担当のメールサーバに 転送する 代表メールサーバが すべてのメールを 受け取るメーリングリスト
あるメールアドレスにメールを送ると 登録されたすべてのユーザにメールが届く [email protected] [email protected] [email protected] : [email protected] [email protected] にメールを送ると 全員に届くメーリングリストのしくみ
メーリングリスト[email protected]に送った場合 登録された メールアドレスに 転送される [email protected] [email protected] [email protected] : freeml.com担当の メールサーバ naniwa-u.ac.jp miyako-u.ac.jp u-edo.ac.jp いったん メーリングリストを 管理するメールサーバ に送られる classroomメールにくっつける情報
メールを送るには，いくつかの情報が必要 メールのあて先 メールの送り主 など．．． これらの情報をメールにくっつけて送る メールのヘッダ(header)という →メールの頭(head)にくっついているから ヘッダ 本文メールのヘッダ
From: To: Cc: Date: Subject: メールの送り主 メールのあて先 メールのコピーを受け取る人 メールの日付 メールの件名 普段よく見かけるもの ヘッダの情報には他にもいろいろある Message-ID: Status: Content-Type: など 別に知らなくても良いヘッダのFrom: 行
From: 行は本当に差出人とは限らない →簡単に偽造が可能 しかも ウィルスが生成するメールのFrom: はたいてい偽造 [email protected] のやつ！！ [email protected] [email protected] 感染しちゃった 何か変？ 実は無関係ヘッダでわかるメールの来た道
Received: from icsmaster.ics.es.osaka-u.ac.jp (mailserv.ics.es.osaka-u.ac.jp [133.1.240.23]) by k2.ics.es.osaka-u.ac.jp (Postfix) with ESMTP
id BA06F4226E8; Wed, 20 Jul 2005 17:29:56 +0900 (JST)
Received: from jimuserv.ics.es.osaka-u.ac.jp (ocsmail.ics.es.osaka-u.ac.jp [133.1.240.141]) by icsmaster.ics.es.osaka-u.ac.jp (8.13.3/8.13.1) with ESMTP id j6K8RYqv067020 for <[email protected]>; Wed, 20 Jul 2005 17:27:34 +0900 (JST)
(envelope-from [email protected])
Received: from OFFICE-PC1.ist.osaka-u.ac.jp (unknown [192.168.21.138]) by jimuserv.ics.es.osaka-u.ac.jp (Postfix) with SMTP id 71B39105065
for <[email protected]>; Wed, 20 Jul 2005 17:27:34 +0900 (JST)
Received: と書いてある行をみれば
メールがどのメールサーバを通ってきたかわかる
最初にメールを送信した
ウィルスメールのヘッダの例
Received: from mail1.ist.osaka-u.ac.jp (mail1.ist.osaka-u.ac.jp [133.1.173.69]) by k2.ics.es.osaka-u.ac.jp (Postfix) with ESMTP id 1F59E3A62CF
for <[email protected]>; Fri, 3 Dec 2004 14:20:31 +0900 (JST) Received: from mx1.ist.osaka-u.ac.jp (mx1.ist.osaka-u.ac.jp [133.1.173.35])
by mail1.ist.osaka-u.ac.jp (Postfix) with ESMTP id 3458E2B55
for <[email protected]>; Fri, 3 Dec 2004 14:20:23 +0900 (JST)
Received: from ist.osaka-u.ac.jp (219-84-131-223-adsl-tpe.static.so-net.net.tw [219.84.131.223]) by mx1.ist.osaka-u.ac.jp (Postfix) with ESMTP id 0AC9C2780
for <[email protected]>; Fri, 3 Dec 2004 14:20:09 +0900 (JST)
名前が偽造されている
（おそらく）本当の名前
ちなみに台湾から来たらしい
送信元のメールサーバの名前が偽造されている
メールと盗聴
• クレジットカードの番号 • 銀行口座の暗証番号 • 住所，電話番号など 人に知られては困ることはメールでは流さないようにする メールは文章を暗号化せずそのまま送っている →盗聴の危険がある WWWのまともなショッピングサイト（amazonなど）で クレジットカード番号を入力するのは比較的安全 →情報は暗号化して送られるビジネスメールのマナー
人によっては1日に100通以上のメールを受け取る
メールで確実に用件を伝えるには？
ビジネスのメールには守るべきマナーがある
メールは信用できない
そもそもメールというものは • 相手に届かない場合がたまにある • 届いても読んでもらえない場合はもっとある メールを送ったとき 返信のない場合は電話で確認 「メールを送ったから大丈夫」と思うのは間違い メールを受け取ったとき 重要な用件については必ず返信件名の書き方
できるだけ具体的に書く →件名だけをみておよその内容がわかるように 急ぎの用件や，重要なメールの場合には 件名を見ただけでそのことがわかるようにする 悪い例 Subject: 先日の件 Subject: 依頼 良い例 Subject: [至急]サーバ計算機見積もりのお願い本文の書き方
その後自分の名前を書く 誰からのメールかがすぐわかるように 面識が無い場合は最初に相手の所属，名前を書く 間違いメールでないことを示すため 時候の挨拶は書かない 用件を簡潔に書く 重要なこと(依頼，周知事項)を最初に書く 〆切はなるだけ上の方に書く 返答が必要な場合は最初に相手の名前を書く 自分に直接関連するメール(Cc:でない)であることを示すため引用の仕方
返信の際 メール全文を引用するのは避ける 不要な部分を削除しておく xxxxです． サーバの返送についてですが，こちらの事情により本日7/19(火)に発送できませんでした． 申し訳ありません． 明日20日(水)に発送し，22日(金)に着く予定です． 失礼します． システムワークス <[email protected]> wrote: > xxxx様 > こんにちは、技術サポート担当 xx＠システムワークスです。 > ---> > お世話になっております。 > ご連絡、ありがとうございます。 > > お手数かと思いますが、宜しくお願い致します。 > > > > > >返信が遅くなり申し訳ありません. > >少し遅くなりますが，7/19(火)に返送させていただきます． > > > > > >システムワークス <[email protected]> wrote: > > > >> xxxx様 > >> こんにちは、技術サポート担当 xx＠システムワークスです。 > >> ---> --->---> > >> お世話になっております。 > >> ご連絡、ありがとうございます。 > >> > >> 弊社で修理を行います。 > >> サーバーを下記宛までご返送ください。 > >> 全文引用で 返信を繰り返すと添付ファイル
Wordファイル，PDFファイルに連絡事項が書かれている場合 内容を本文にも書いておく 添付ファイルを開かないと内容が分からないメールはだめ Subject: 避難訓練について 添付のとおり通知がありましたので ご連絡します． （添付ファイル：避難訓練.doc） Subject: 避難訓練（7/19 14:00）実施のお知らせ 職員各位： 下記の日程で避難訓練が行われますので よろしくご協力をお願いいたします． 日時： 7月19日 14:00から20分程度 なお，詳細については添付資料をご覧ください． （添付ファイル：避難訓練.doc） 悪い例 良い例スパムとは？
いわゆる迷惑メールのこと スパム（SPAM）とはもともと豚肉の缶詰の商品名 日本で言えば「シーチキン」のようなもの？ ではなぜ迷惑メールをスパムというのか →どうでもいいです 人によっては1日100通を超えるほどなぜこれほど多いのか？
基本的にはダイレクトメールと同じ 数うちゃ当たる ほんの少しでも反応する人がいればいい 電子メールは送信にお金がかからない →ダイレクトメールのような用途にはうってつけなぜスパムは防げないのか？
これだけ問題になっているのに
メールのプロトコル
SMTP(Simple Mail Transfer Protocol) メールを送るときに使われるプロトコル
SMTPによる通信の例
220 mail.sfc.keio.ac.jp ESMTP Sendmail 8.9.3/3.7W-SFC; Sat, 5 Jan 2002 07:56:02 +0900 (JST)
HELO taro
250 mail.sfc.keio.ac.jp Hello ccz02 [133.27.4.214], pleased to meet you
MAIL FROM: [email protected]
250 [email protected]... Sender ok
RCPT TO: [email protected]
250 [email protected]... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
To: [email protected] From: [email protected] Subject: smtp test test // taro .
250 HAA11092 Message accepted for delivery
QUIT
出典：
http://www.soi.wide.ad.jp/class/20010012/ slides/11/30.html
シンプルにも程がある
From：行が偽造されてないか確認しない 本文が偽造されていないか確認しない 本文の暗号化もしない なーんにもしない SMTPは，受け取った文章を，指定されたあて先に 「書かれたとおりに」送るだけ 送信者が誰であるか確認しない 受信者が受け取りたいかどうか確認しないなんでこんなにシンプルなのか
SMTPの原型は インターネットが出来る前からあった SMTPが設計された当時 メールで広告をばら撒くなんてことは思いもよらなかった 電子メールが送れること自体が 珍しい時代 ユーザはほとんどが研究者 インターネットで 金儲け？ メールが届いて 迷惑？ はぁ，何のこと だか．．．だったら変えれば？
プロトコルはみんなが守る約束 いちど広く普及したプロトコルを変えるのは非常に困難 （それが重要であればあるほど） メールは特に難しい→送り手と受け手の関係 新しい形式は 受け取れない かも 古い形式で 送ってくる かも 結局古い形式でやり取りするスパムを予防する
スパムを送ってくる人（スパマー）に
メールアドレスを知られないようにする
当然のことですが
