情報実習 = 情報実験 2024-07-05

時間	内容	裏方覚書
12:30	スタッフ (教官, TA, VTA) 集合	T.A. の作業プロジェクタ, マイクの準備プロジェクタには inex ホームページ名札をつける. V.T.A. の作業 3N 機でブラウザを起動し INEX ホームページを閲覧している状態にしておく. V.T.A. の心得確認, 本日のスケジュール確認担当テーブルの学生の良きお兄さん,お姉さんになってあげる. と, 同時に自分もお勉強すること. 質問を積極的に行う. 第 2 の学生さんの雰囲気で. 担当テーブルの学生の振舞い評価を任せる.
13:00	学生集合, 各グループ毎にテーブルにつく.
13:05	レクチャー(中野) [レクチャー資料] クライアント・サーバシステム WWW の仕組み著作権
14:10	休憩
14:20	実技(髙橋) Apache 最低限 HTML Web ページの公開本日の課題	Apache を使用.
15:00	本日の一冊, 質問等の後, 学生解散各マシンの電源を落とす. 名札を前のレターケースの中にしまう.
16:00	スタッフ(教官, TA, 3N マシン管理者) 打合せ	教官, TA, 各テーブルの VTA は基本的には必ず出席お願いします.
■ レポート課題 ■ 本日の課題 (〆切2024/07/17(水) 正午)

2024 年度 (ロガー : 髙橋)
- 時間配分
- 質問など
- その他
  - とくになし
- 次回への申し送り事項
  - [3.3.2]，[3.4]におけるコメントアウトは灰色網掛けの外に出すべき．
  - [2.3]情報演習=>情報実習．
  - [3.3.2]sercret=>secret
  - 実技編のスクショを変えよう！
2023 年度 (ロガー : 角川)
- 時間配分
- 質問
- その他
  - joho19: OS が起動しなくなった.
  - htaccess の hoge をそのままタイプする例がいくつかあった.
- 次回への申し送り事項
  - (実技資料)アクセス制限をかけた後には apache の再起動を推奨する.
  - アクセス制限をかけた際ブラウザのキャッシュが残っていて意図しない表示になる場合がある.
2022 年度 (ロガー : 茂木)
- 時間配分
- - 13:00-13:33: レクチャー(洞口)
  - 13:33-13:45: 休憩
  - 13:45-15:15: 実習
  - 15:15-15:20: 課題説明
  - 15:20-15:25: 実習続き
- 質問
- その他
- 次回への申し送り事項
  - apach2の設定ファイルを書き換えた後にapache2のリスタートをすることを資料に書き加えること.
2020 年度 (ロガー：杉山)
- 時間配分
- 講義編（数値計算入門回）質疑応答
  - なぜモデルは多数のファイルから成ることが多いのか？ --> メンテナンスや改良を容易にするため
  - 巨大なモデル、とは定量的にはどれくらいか？ --> 近年ではコードにして1万行を超えるものも多い
- 実技編質疑応答
- その他

2019 年度 (ロガー: 哲)

時間配分

13:00 -- 13:46 レクチャー
13:46 -- 13:56 休憩
13:56 -- 15:04 実技
15:04 -- 15:15 課題説明
15:15 -- 15:22 本日の一冊, 等
15:22 -- 15:30 実技続き
15:45 -- スタッフ - TA ミーティング

講義編

欧州原子核研究機構 (CERN) を知ってる人 -> ほぼいない?
ブラウザのシェアはスマホは入っているのか -> 入っていないと思う
Google Chrome -> 半分, Safari -> 5 人, IE -> 10 人, FireFox -> 1 人
サーバのシェアの図は信頼できるのか? -> わからない
URL は大体みんな聞いたことがある
URN はちらほら知っている
IE が使われなくなったのはなぜ? -> windows 10 の普及に伴ってEdge が使われるようになったから?
html 文書の著作権はどうなっているのか? -> 固有の「表現」の引用は引っかかるだろう
著作権クイズ 1. ほぼ全員が正解 2. 半々程度
ライセンスについて, ライセンスの数はとても多い. creative commons くらいは知ってていいのでは?
イラスト屋を商用で使う際には 20 個まで個数制限がある
URN の例を出すべき?

実技編

vi を使うと作業が遅くなった
hoge と打ってしまう人が多いため要アナウンス?
apache の起動確認のコマンドにもっと適切なものがある

その他

サーバー・クライアントシステム以外の関係も示すべき?(P2P など?)

2018 年度 (ロガー: 村橋)
- 時間配分
  - 13:00 -- 14:04 レクチャー
  - 14:04 -- 14:15 休憩
  - 14:22 -- 15:40 実技
  - 15:40 -- 15:55 課題説明
  - 15:55 -- 16:00 本日の一冊, 等
  - 16:00 -- 16:30 実技続き
  - 16: -- スタッフ - TA ミーティング
- 講義編
  - 欧州原子核研究機構 (CERN) を知ってる人 -> 1-2 人
  - 閲覧する計算機に寄らない文書閲覧方式とは -> どんなブラウザでも見られる. 特定のソフトウェア, 環境でなくても見られる
  - WWW はなんて読むのか -> 「ウェブ」「ダブリューダブリューダブリュー」「ダブリュースリー」など好きに呼べばよいのでは
  - ブラウザのシェアはスマホは入っているのか -> 入っていないと思う
  - Google Chrome -> 半分, Safari -> 5 人, IE -> 10 人, FireFox -> 1 人
  - スマホのブラウザ : Safari -> 7 割ぐらい, Chrome -> 3 割ぐらい, フューチャーフォン -> 1 人, Sleipnir -> 1 人
  - サーバソフトウェアを運用したことがある人 -> 1 人いた.
  - サーバがたくさんあるのはなぜか -> いっぱい開発されているから
  - HTTP を聞いたことがあるか -> 6 割ぐらい
  - TELEPHONE と書いてあるイラストの意味は? -> 特に意味はない. 電波出しているイメージが欲しかった
  - ハイパーリンクの考え方はどこで生まれたのか -> Memex による概念が根源の一つであると考えられる. CERN で論文をたどるシステムが元になっているかもしれない.
  - URL を知っている人 -> 7 割ぐらい.
  - Apache ハイドブック -> ハンドブック
  - URI : Unified Resource Identifer -> Identifier
  - HTML タグを触ったことがある人 -> 5 割ぐらい
  - ウェブブラウザにおける文字化けを見た経験がある人 -> 10 人ぐらい
  - 文字コードの問題は作る側ではなく, 見る側の問題なのではないだろうか. -> 作る環境によっては文字コードの指定が思った通りにならない場合も少なくないので, 必ずしも見る側だけの問題ではない
  - 文字化けしてしまったテキストを戻すことはできないのか -> ソフトウェアなどを駆使すればできる場合がある
- 実技編
- その他

2017 年度 (ロガー: 渡辺)

時間配分

13:01 -- 14:07 レクチャー
14:07 -- 14:15 休憩
14:15 -- 15:40 実技
15:40 -- 15:50 本日の一冊, 課題説明, 重要連絡等
15:50 -- 16:10 実技続き
16:10 -- スタッフ-TA ミーティング

講義編

CERN の読みはスペイン語系だとセルン，英語系だとサーンらしい．
受講生のブラウザ使用調査：Chrome ほぼ全員，IE 数人，Firefox 1/3 ，Safari 数人．他sleipnir, vivaldi, Microsoft Edge など
Apache を使う理由は? -> フリーであり，無料．さらに様々なOS で動く．(あとぶっちゃけると，自分たちのサーバで動いているサーバソフトウェアがapache ということもあるため，中身をある程度知っているから使っている．)
無保証が利点とは? -> どっちかというとデメリット(石渡) 言いたいことは自分たちで色々できる．つまり改変が自由だから
URL は既に情報学や前回のINEX 講義で出てきていたので，知っているはず... URI, URN は聞いたことがある人はいない
p19. の画像の意味は? -> 左: Youtube, 中: Web メール, 右: SNS
文字化けはほとんどの受講生が経験あり
なんでこんなに文字コードがあるのか？-> OS の開発時にそれぞれのベンダーが勝手に作ったため，乱立した(http://itpro.nikkeibp.co.jp/article/COLUMN/20061122/254616/ )
p25. の画像はどの文字コードを指定して，文字化けしているのか? -> 混ざっているShift-JIS, EUC-JP
マイクロソフトの著作物の使用について
著作権クイズ! Q1: いるが大多数, Q2: だめが多い
ライセンス等を調べても分からない場合は慣習や判例を参考にする
いらすとやの著作権の確認等は実演しながら，やれていたのでよかった
p33 「テレビ番組を録画した...」は本当に許容されるのか? (要調査，参考URL)

実技編
- joho11, 07 : root で html ファイルをroot ディレクトリに作成してしまった/li>
- [3.4] ソフトウェアレベルでのアクセス制限　のsecurity.conf を編集した後，systemctl restart apache2.service をする
- 所々，root で作業する場所があるが，受講生の操作ミスを防ぐため先頭にsudo を付ける
- 今回の実技資料で用いていたcssがhtml5 に準拠した仕様のもの(css/jitsugi_html5.css)を使用していたため，微妙に変になっていた．

2016 年度(ロガー: 渡辺)
- 時間配分
  - 13:00 -- 14:30 レクチャー
  - 14:30 -- 14:40 休憩
  - 14:40 -- 15:50 実技
  - 15:50 -- 16:13 本日の一冊, 課題説明, 重要連絡等
  - 16:15 -- 16:?0 実技続き
  - 16:30 -- スタッフ-TA ミーティング
- 講義編
  - P. 6
  - P. 9
  - P. 10
  - P. 17 (ここまでのまとめ)
  - P. 19
  - P. 22
  - P. 23
  - P. 24 (補足)
  - P. 26
  - P. 29
  - P. 31
  - P. 32
  - (三上コメント)まとめ：著作権の部分がまとめになっていない．著作権の言葉に関しては最低限説明すべき
  - 今回は時間が結構かかってしまった(みんな盛り上げようと沢山突っ込んでいた)．レクチャラーが適宜時間を見て進めてほしい
- 実技編
  - [3.4] ソフトウェアレベルでのアクセス制限:
    アクセス制限を確認後，アクセス制限を解除するような文言を入れる必要がある
  - HTML とHTML 文書という言葉の区別，使い分けをはっきりする
- 課題について

2015 年度(ロガー: 三上)
- 時間配分
  - 13:00 -- 13:53 レクチャー
  - 13:53 -- 14:05 休憩
  - 14:05 -- 15:20 実技
  - 15:20 -- 15:30 本日の一冊, 課題説明, 重要連絡等
  - 15:30 -- 16:15 実技続き
  - 16:15 -- スタッフ-TA ミーティング
- 講義編
  - タイトルの黄色と緑が見づらい
  - 受講生への質問: 先週のINEX では何を学びましたか?
  - 受講生への質問: サーバクライアントシステムにおける通信の概要について説明してください
  - なんでapache を使っているの?(村橋)
  - netcraft ってなに?
  - ブラウザ調査
  - mozira => mozilla
  - URL を知っている人が意外と少ない?(本当は知っているはず, 聞き方が悪い?)
  - URI は識別子だがファイルのパスはURI ではないのか?
  - ソースってなんですか?
  - 受講生への質問: 文字コードという言葉を知っている人
  - 受講生への質問: 文字化けという現象に陥ったことがある人
  - 文字化けが起きたときの対処法
  - なぜEUC-JP だとわかったのか?
  - Q. xml の拡張性とはなにか?
  - Q. Web ページ(ファイル)は一つのWWW サーバに格納されているのか?
  - Web コンテンツを「公開する」は「提供する」のほうが正しい?(文言の統一の観点から)
  - してはいけないことに関して, 重要なポイントは"許可の有無"と"公開の対象(不特定多数かどうか, など)"
  - Q. 明らかに著作物であるのにライセンスが明記されていない場合はどうすればいいのか?
  - p.23 タイトルを「HTML 文書作成の作法」にして, 「基本的にタグは閉じる」にした方がタグの性質に沿う
- 実技編
  - apache の設定ファイルを編集し, 反映したい場合にはapache の再起動が必要, と書いてあるのに再起動しない(joho13,14)
  - hero, hoge 等の打ち間違い(joho01,02)
  - アクセス制限がかかったまま作業に取りかかったので進行に影響が出た(joho10)
  - URL の打ち間違いが多発(joho20)
  - public_html をデフォルトで読みにいくということを2 の方に少し記述する必要がある
- 課題について
  - タグを使用する個数を指定するという課題はHTML5 のポリシーに準拠するものか?
  - スタイルシートの提出を必須にすべき
  - 著作権(今年の受講生のレポートを受けて)

2014 年度
- 時間配分
  - 13:01 -- 13:58 レクチャー
  - 14:00 -- 14:10 休憩
  - 14:12 -- 16:05 実技
  - 16:05 -- 16:09 本日の一冊, 課題説明等
  - 16:15 -- スタッフ-TA ミーティング
- 講義編
  - wwwについて聞いたことある人 -> 1/3 くらいの人が聞いたことある.
  - www できたことはもう既にインターネットはあったのでは？ -> 一般に普及していなかったということ
  - サーバ・クライアントシステム分かる人 -> みんなわかっている様子.
  - メインブラウザは？ -> Chrome: 1/3, IE: 1/3, Firefox and Safari: 1/3 くらいその他:少々
  - なぜ Apache を使うのか？ -> これまでのスタンダードなので使っておこう. nginx -> www, mailプロキシサーバ機能をかねそなえているので広まった？
  - URL 知っている人？ -> アドレス正解かも, URL聞いたことある人は? -> ほとんど知っている様子
  - 例のURLをフルパスを書いていない. -> 同じNetwork内からアクセスしたからといって, 必ずしもドメイン名を省略できるわけじゃない.
  - 文字化けしたことがある人 -> 殆どの人が経験している
  - なぜそんなに文字コードが？ -> 日本語文字コードを作成する歴史的経緯
  - W3C はどういった組織なのか？プロトコルも決めている？ -> プロトコルは決めてない, マークアップ言語の標準化をしている. スキーム仕様推奨の提言等しているのでは？
  - 本部じゃないとあるが？ -> 各国が支部として動いているイメージ
  - おすすめのブラウザは？ ->ペイルムーン
  - ブラウザのタグの解釈は一緒？ -> 微妙に違う
  - Linux が GPL に全て準拠していると考えて良いのか？ -> GPL でないものもあるので, それぞれのライセンス規約に従うこと
  - 改変したときに必ず公開しなきゃいけないか？ -> そのようなことはありません.
  - オススメのライセンスは？ -> BSD ライセンス！縛りが緩い (Berkeley Software Distribution)
- 実技編
  - ht_access がうまくできなかった -> 資料では表示方法が記述されていなかった.
  - 実技編資料中で br, em -> html5 では em:強勢, strong: 強調 (html5 に準拠していく)

2013 年度
- 時間配分
  - 講義 13:05 -- 14:00
  - 実習 14:10 -- 15:50
  - 諸連絡 15:50 -- 15:55
  - 反省会 16:15 --
- 講義編
  - なんで渡辺君がお話？=> WWW サーバ管理者だから
  - だぶだぶ？だぶだぶだぶ？うぇぶ？呼称は統一したい
  - ホスト機関は3 つしかない？ => 18 ある
  - CERN でWWW(1989 年) を作って，MIT でW3C(1994 年) を作った
  - スラッシュはタグの終了を意味する
  - HTML タグの外でもブラウザは賢いので表示してくれるブラウザもある(Chrome はできた)
  - title タグの中に書くと表示されるところはブラウザのタブに表示される
  - 書かないとブラウザのタブにはURL が表示される
  - TLS は第9回で話した？ => してない TLS ってなんですか?
  - INEXの2012 年のページにはどのようにアクセスすれば？ => 2012 年ディレクトリ以下にアクセスすればよし
  - Meta のキーワードとは？ => 検索のときに引っかかるのがキーワード
  - Meta の文章の説明とは？ => HTML の文書の説明
  - フリーは無料という意味ではない自由だ
  - iceweasel はfirefox に入るのか？ => 入っている可能性わからない
  - IE はWindows のデフォルトブラウザであり，Chrome はAndroid のデフォルトのブラウザなのでシェアが高い + 新興国はChrome から導入することが多い
  - ブログは最近流行っていない => INEX でWeb ページを作成することに重要な意義があることが判明
  - ブラウザがタグを解釈するが，ブラウザによって表示の仕方が変わることもあるのか？ => ブラウザによって表示が変わる
  - ブラウザには勝手に変なタグや要素を読み取ってくれる機能がある
  - クライアントの自由度(ブラウザにはいろいろな種類が存在)がある程度保障される代わりにプロトコルには従いましょうというのが，プロトコルとサーバクライアントシステムの重要な関連性
  - 途中までしかURL をいれなくても表示される場合があるのはなぜか？ => サーバソフトウェアには，特定の場所に特定の名前のファイルを置くことでそのページを自動的に読みだす機能がある(たとえば，public_html/index.html 等，実習で詳しく)
  - 受講生はIE とChrome(30 %)，firefox(20 %)くらい，opera はほとんどいない．
  - 来年度はもう少し順番の改善が必要
  - たとえば，URL とかブラウザという言葉が最初に多く出てきたが，説明自体は後になったこと等は要改善
  - HTML 文書の例を変えた方がいい(例画像とかが貼られていないシンプルな構成の文書)
  - HTML 文書のバージョンがバラバラ => 極力合わせる
- 実技編
  - 実習資料の1 ページ目から文字化け(古田君)
  - 実習のトレースを行った実験機では「It works」が表示されなかった
  - hogehoge をhogehoge のまま打つ人がまだいる
  - [3.4] でアクセス制限ができない
  - ソフトウェアレベルでのアクセス制限については要確認
  - joho05 でルートでstartx した
  - startx してるのにstartx する人もいた

2012 年度
- 時間配分
  - レポート講評 13:00 -- 13:05
  - 講義 13:05 -- 14:05
  - 実習 14:15 -- 15:30
  - 諸連絡 15:30 -- 15:35
  - 反省会 15:40 --
- 講義編
  - ネットワークを介してメールを送るとは?メール本体が送られるタイミングは?
    - 相手のアドレスを元に相手の IP を特定
    - 経路に沿ってパケットを送信
    - ゲートウェイ毎に送信している?
  - POP と IMAP の違いは?
    - 今はほとんど変わらない
  - ネットワークを経由するということはログが残るのか?
    - 残ります
  - ウェブメールを手元の MUA で操作することもできます
    - ブラウザでアクセスしているのはクライアントとかをまとめたもの
  - IMAP でメールサーバ上のメールを消せるのか?
    - 消すこともできる
    - 直接サーバにアクセスする分だけ、 POP に比べて IMAP だと負荷が大きい
  - 誰にでも暗号化できるというのはデメリットなのか?
    - そんなことはないはず
  - 公開鍵がよくわからない
    - どっちも鍵と呼んでいるが公開鍵=錠前, 秘密鍵=錠前を開ける鍵と考えればよい
    - 共通鍵という呼び方もある
  - 共通鍵方式の方が一般的
  - なぜ復号の時間差が出てくるのか
  - そもそもメールのセキュリティに限った話ではないのでネットワークセキュリティの回で話す
  - 復号と解読の違いを説明した方がいい
  - 暗号化の仕組みについても触れたい
  - ep のメールの保存形式は?
    - 保存形式はプロトコルではなく MTA 依存
    - ep の場合は imap だと 1 ファイル, pop だと個別ファイルになっている
- 実技編
  - ソースの表示方法について
  - 今年は lemon ではなく inex-gw と名乗るべきだった
  - telnet からの強制ログアウト法を載せておくべきかも
  - 3.1 でウェブメールと言いつつ画像が MUA だった
  - 本日の一冊はちゃんと読んでおく

2010 年度
- 時間配分
  - 講義 13:00 -- 14:05
  - 実習 14:15 -- 15:25
  - 諸連絡 15:25 -- 15:30
  - 反省会 15:40 --
- 講義編
  - [スライド4](補足) メッセージを交換するシステムとだけ言うと，チャットや twitter 等も該当する.
  - [スライド5](補足) メールもネットワークサービスの 1 つ．サーバの方にメールを取り置きしてくれているので, 自分の PC の電源を常に入れておかなくていてもメールを受信できる．携帯メールの場合も同じ.
  - [スライド6](補足) メールは様々なメールサーバを介してバケツリレー方式で届けられる．
  - [スライド9] クライアントのマシンは電源を切っても大丈夫．サーバマシンの電源はつけておきましょう．
  - [スライド12] ネットワーク上でやり取りする際のデータの窓口がポート (ポートの復習)
  - [スライド15]
    - (質問) IMAP だとネットワークにつながっていないとメールは読めないのか？
    - (答え) ネットワークにつながっていないと見れない.
    - (質問) 携帯メールは圏外でも受信したメールは見える.ということは POP ?
    - (答え) POP のような形式ではあるが, プロトコル自体は会社独自のものを使っているらしい
    - (質問) Gmail や yahoo mail のプロトコルは？
    - (答え) web 上で見るのでプロトコル自体は HTTP. ただし, メールのやり取りの上で IMAP や POP のようなプロトコルを使っているかも. Gmail は IMAP に対応している.Gmail では HTTP, HTTPS, IMAP, は使えるらしい.
  - [スライド16] 最近では POP も IMAP も同じような機能を備えるようになってきており, 違いがなくなってきている
  - [スライド23] MIME とは文字をデータとして送るための処理をするソフト
  - [スライド32](補足) 携帯メールも全く同じような形式で送られる. ヘッダの情報はサーバに保管されており,我々の携帯に受信する際には会社独自のプロトコルによってヘッダが取り除かれている.
    - (質問) ヘッダ部分を見ることはできるか？
    - (答え) サーバに接続すれば見ることができる.au は見れる.Docomo, softbank は未確認.
    - (質問) ソフトバンクで電話番号同士でやり取りする場合や AU の C メールではどうなってる？
    - (答え) わからないが, 一般的なメールとは違う方法でやり取りされているのかも？
  - [スライド34]
    - (質問) html 形式で送ることの利点は？
    - (答え) 画像を埋め込めたり, 凝ったメールを送ることができる. 不特定多数の人に送る場合は text 形式で.
    - 相手が見えない分,書き方によっては心証を悪くする. メールを書く際には表現に注意しましょう.
  - [スライド35]
    - (質問) 怪しいメールが来た時の対処法は？
    - (答え) 怪しい添付ファイルやリンク先を開かない. ヘッダ情報から詐称かどうか判断.
    - html 形式のメールが来た時点で疑う(小高・高橋)
  - [スライド38]
    - (補足) メールサーバの管理者はサーバに来たメールを覗くことはないが, サーバが乗っ取られた場合は覗かれたり流出してしまう場合がある.
    - 「鍵」とは「文字列」のこと
  - [スライド36]
    - (質問) 公開鍵はいつ相手にわたるのか?
    - (答え) 適当なタイミングで渡す. ダウンロードしたり USB 経由で渡したり.
    - (質問) 公開鍵と秘密鍵は関係あるの？
    - (答え) セットで作られるので関係はある. 複雑な暗号化形式なため, 公開鍵から秘密鍵を予測するのは難しい.
  - [スライド43]
    - (質問)APOP で使うと暗号化されるようだが, これは公開鍵秘密鍵を用いている？
    - (答え)1 つの鍵で暗号化している. 鍵は各ユーザーが設定する.
- 実習編
  - [補足] From の詐称は簡単だが、決してやってはダメ！
  - サーバへの挨拶は何の意味があるのか? (要調査)
  - 来年度は情報実験機をメールサーバにしてメールを送ってみる, log を見てみる.(要検討)

2009 年度
- mail サービスのレクチャーについて(開始 13:00, 終了 13:42)
  - 字が見えにくかった.
  - 用語の打ち間違いに注意.
  - [補足]MUA, MTA のそれぞれのスライドで絵を貼った方が良かったかもしれない.
  - 世間一般でのメーラのシェアはどんなもんなのだろう?
    - ウェブメールのユーザが増えてきている? その仕組み(プロトコル etc)を調べてみると面白いかも.
  - サーバに直接ログインしてメールを見ることも出来ることを述べておいた方が良い.
  - MTA で現在主流となっているのは postfix? 要調査.
  - [補足]宛先が見つからない場合にエラーメッセージを送信者を返すのも MUA の仕事.
  - メールボックスはメールを置く為のフォルダと考えれば良い.
  - [補足]厳密に言うと, 最近では IMAP も手元にダウンロードすることは可能.
  - [補足]携帯メールの場合, ヘッダを見る為には各企業のサーバにログインしなければいけないらしい.
  - Delivered to は最終的に送られる宛先である.
  - メールの差出人を詐称するのはいけません, と強調すべきである.
  - [補足]MIME は文字エンコード(言語間の変換) を行なう為のソフトウェア.
  - [補足]北大の場合, 10 MB 以上のメールは送れないので注意.
  - [補足]公開鍵・秘密鍵と言っている実態は文字列である.
- mail サービス実技編(開始 13:55, 終了 14:45)
  - 受講者が [2.3] で間違って hoge@... で送ってしまった場合, VTA・TA の人が適宜フォローする.

2008 年度
- mail サービスのレクチャーについて(開始 13:00, 終了 13:55)
  - メールを送信する際, 送信先は厳密に言うと受信側のメールサーバである. クライアントはメールサーバにメールを貰いに(または見に) 行くことになる.
  - メールを送受信する際, ローカルなメールサーバでなく遠隔地のメールサーバを利用することももちろん可能である.
  - ドメイン名はメールサーバを指定するもので, ユーザ名はそのメールサーバの個々人(団体)を指定するもの.
  - メールを受信ボックスに配送するのも SMTP サーバ(サーバソフトという意味では MTA)の仕事.
    - 存在しないユーザにメールが送られてきた際にエラーメッセージを送るのが SMTP サーバであることに着目すると, 受信側の SMTP サーバが送られたメールを受け取っていることが理解される.
  - メール受信(POP の場合)のところの図がやや分かりにくい. 来年作り変えた方が良い.
  - 最近は IMAP と POP について, 機能的に差別化できなくなってきているが, 間違いなく言えるのはプロトコルが異なるということである. どのようなことを念頭に置いたプロトコルなのかを説明すると良いだろう.
  - 壺メールの事例では Message ID が記されていない. 来年以降書いておいた方が良い?
  - 「To :」と「Delivered-to :」に関する指摘があったが, これらについては2007 年度のコメントを参照.
  - 携帯メールでも, メール会社に頼むと経路などの情報も見れるらしい.
  - フィッシング詐欺の手口
    - いかにも本当らしい web サイトの URL を掲載したメールを送信
    - その web サイトに巧みに誘いこんで情報を盗む
  - サーバを構築する際には以下の点に注意.
    - ソフトウェアをインストールすると, サーバ機能が意図せずに入ってしまうことがある. そのような場合, サーバが起動しないように設定するべし (セキュリティの問題から).
- mail サービス実技編(開始 14:05, 終了 15:00)
  - [2.2] サーバへの挨拶 (helo)について
    - blue を lemon に修正.
  - [3.1] メールのヘッダーと本文について
    - 空白行を入れないと見えないはずが見えてしまう...
    - 北大のゲートサーバの仕様か?
    - 注意書きを足しておく.

2007 年度
- mail サービスのレクチャーについて(開始 14:45, 終了 15:38)
  - ISP(プロバイダ)から提供されるメールサービスの例 : 情報基盤センターから提供されるメールサービス, メールソフトを起動して初めて利用できるメールサービス.
  - メールアドレスの @ マークの直後に必ずしもホスト名が来るとは限らない ; [例] : hoge@hokudai.ac.jp
  - 「メール受信(POP の場合)」と「メール受信(IMAP の場合)」の図が分かりにくい.
  - POP について
    - メリット : お手軽に設定できる, 手元にダウンロードできる
    - デメリット : セキュリティが甘い(平文のまま流れる), 複雑な設定が困難
    - 暗号化できる APOP というものも開発されたが, これも完全とは言えないらしい.
  - IMAP について
    - メリット : ネットワークにつながってさえいれば, サーバに見に行くことができる. 家や職場などで PC を使い分けている場合には IMAP が便利.
    - デメリット : 手元に持ってこれない
  - 最近では IMAP でもダウンロードできるようになっている. また POP でも手元に残せるようになってきており, 差異は無くなりつつある.
  - メールヘッダの例で「Delivered to : 」の所と「To : 」の所の宛先が微妙に異なっているのは何故か?
    - 「Delivered to : 」はサーバのホスト名を含み, 「To : 」はサーバのホスト名を含まない. 両者の対応付けをやってくれているのが DNS サーバである. こうすることにより, 普段使用しているメールサーバで障害が起きた時に, セカンダリメールサーバからメールを受け取ることが出来る. どのメールサーバをプライマリにし, セカンダリにするかの設定は DNS サーバの方で行われている.
  - 携帯電話のメールでは電話帳に登録しておくと, 名乗らなくても送信者が分かるが, 通常のメールでは送信者は分からないので, 最初に名乗ることが肝要である.
  - 大きいファイルが添付されたメールを弾くよう設定されているメールサーバが増えてきているので, メールを送る際には注意したい. また, 弾かれてもエラーメッセージが戻ってこないこともしばしばあるらしいので, 要注意.
  - 公開鍵システムのメリット
    - 改竄されたことが分かる. つまり, 悪意のある人が改竄すると, その文書が送信先に届いたときに秘密鍵を使っても開けないと言うことになる. その結果, どこかで改竄が行われたことが分かる.
- mail サービス実技編(開始 15:50, 終了 16:51)
  - web mail の入り口がテキストとは違う (学生用という所から入らないとうまくいかない).
- まとめの話(開始 17:00, 終了 17:16)
  - 特にコメント無し.

2006 年度 (メール配送の回)
- 講義時間: 開始 13:05, 終了 13:35
- 実技時間: 開始 13:45, 終了 14:40
- 実技: [2.1] 空白行をいれなくても, WEB メールの MUA は hello 以下をデータ本文として扱っていた.
- 実技: mail From: 以下に実在しないメールアドレスをを打ち込む学生がいた. joho??@ep.sci.hokudai.ac.jp など.
- 講義, 実技: 送る側が詐称を防ぐ方法 (電子署名) についての内容を加える.

2005 年度(メール配送の回)
- 講義時間: 開始 13:05, 終了 13:50
- 実技時間: 開始 14:00, 終了 14:50
- スパム講義: 開始 14:50, 終了 15:00
- 講義 : 講義編資料の筋の練り直しをした方がよいだろう. 電話を例にしたプロトコルの説明のあとに実際のプロトコル解説がすぐ来なかったことが違和感.
- 実技: [2.1] 空白行をいれなくても, WEB メールの MUA は hello 以下をデータ本文として扱っていた.
- 実技: mail From: 以下に自分の情報基盤センターのメアドを打ち込む学生がいた. joho??@ep.sci.hokudai.ac.jp など. 具体的なメールアドレスを指定した方が良いかもしれない.
- 実技: メールサーバの能力からすればこの程度のメールはあまり付加をかけないよう.
- 実技: メールを詐称したらばれますよっていうことを教えなければいけない.

2004 年度(メール配送の回)
- 講義時間: 開始 13:05, 終了 14:00
- 実技時間: 開始 14:10, 終了 15:00
- 実際にメールを送信する具体例をあげて説明する。
- 説明順を工夫する。内容は十分。
- 項目間の関連を話すとよい。

- 情報実習 -

情報実習第 9 回

2024 年 7 月 5 日

本日テーマ

クライアント・サーバシステム / WWW の仕組み

事前準備内容

本日の予定

昨年度反省事項

反省事項(来年度への覚書)

テキストなど

- 情報実習 -

情報実習 第 9 回

2024 年 7 月 5 日

本日テーマ

クライアント・サーバシステム / WWW の仕組み

事前準備内容

本日の予定

昨年度反省事項

反省事項(来年度への覚書)

テキストなど

情報実習第 9 回