情報メディアとインターネット 第9回
電子メール
学術情報基盤センター 升 屋 正 人
電子メールを送信する前に
「自分が書いた電子メールに対するチェックリスト」で
チェック
http://www.notredame.ac.jp/~tyoshida/check/mailcheck. html ポイント
目的・内容 常識の範疇であるはずだが時には驚かされるメールも レイアウト 半角７０文字の慣習は携帯メールの普及によりすたれつつある 構成要素 詳細後述 著作権・プライバシー 著作権については以前の授業で解説済み電子メールの構成要素に関する注意点
Subject（件名）
適切なものをつける 古くは日本語を使えなかったが現在は日本語で To, Cc, From
古くは日本語を使えなかった 「To」に関するマナー(?)が登場→後で 署名
３行程度（以内）が適当 添付ファイル
勝手に送らないのがマナーとされる HTMLメール→後で
携帯メールアドレスの「.」
4 ドコモ 「.」は「..」などのように連続で使用することや@マークの直前で使用す ることはできません。 先頭文字は英文字にしてください。 ソフトバンク 先頭は英文字のみご利用いただけます。 最後に「.」（ドット）を使用することはできません。 「.」（ドット）をアドレス内で連続使用することはできません。 au 「.」をアドレス内での連続使用や「.」をEメールネームの最初/最後に使 用することはできません。また最初に数字の「0」を使用することもでき ません。 これらの注意を守らないとインターネットからメールが届かない RFCに準拠していないためRFC(Request for Comments)
インターネットの技術仕様
「標準勧告文書」が定訳
IETF（インターネット技術標準化委員会）が担当
標準化プロセスが公開←→ISO/JIS
準拠しないと相互にやりとりできない
日本の携帯メールは非準拠による弊害の典型
現在はRFC準拠でないと登録できないが以前取得したも
のが残る
携帯メールを想定した余計な処理が必要→コスト増・時間ロス宛先（To:）に関する最近のマナー
ここ数年「敬称を付けるべき」と言われはじめた
以前は、From:に書く名前は英字にするのがマナーだったのでその返信も英字 From: Masato Masuya <[email protected]>
敬称を付ける方がおかしかった
「To: Masato Masuya 様 <[email protected]>」！？
でも日本語でFrom:を書くのが普通になって From: 升屋正人 <[email protected]> 呼び捨ては失礼ということに To: 升屋正人 <[email protected]> 確かに違和感はあるが… To: 升屋正人様 <[email protected]> そこまでしなくてもいいかも To: [email protected] なら悩む必要が無い。届くし。 今のところ常識とまではなってない 間違えてると失礼 or 恥ずかしい
テキスト形式のメールとは？
メール本文のテキスト（＝文字列）の位置や装飾に関す
る付加情報が無いメール
電子メールはその仕組み上、テキストしか送ることができない HTML形式、リッチテキスト形式、添付ファイルなどは付加情報 を付けることで実現 付加情報の解釈はメールソフトやWebメールシステムが行うため、 場合によっては解釈できないこともあるなぜテキスト形式でないとダメと言われるか
どんなメールソフトでも「テキスト形式」なら読むこと
ができる
テキスト形式でないと怒る人がいる
HTML形式の場合、無警戒にリンクをクリックすることでフィッ シング詐欺やウイルスの被害に会いやすい 自分が気をつければいい マナー・モラルを守れ！ 他人に強制されることをマナー・モラルとは呼ばないが… 容量が大きいと通信費がかかる 最近は常時接続が普通 コミュニケーションの手段である以上、相手を不愉
快にさせる行為は避けるべき
電子メールによるウイルス感染の仕組み
9 「添付ファイル」としてウイルスが送られてくる
【実行】によりウイルスが作動・感染 ダブルクリックによる実行のほか，OutlookやOutlook Expressではセキュリティホールを利用されプレビューしただ けで自動的に実行される場合も 自分自身を添付したメールを大量送信 自分自身を共有フォルダにコピー 一見無害な画面などを表示しながらシステムを破壊 サービス妨害（DoS）攻撃を行う場合もある 【実行】しない限り，絶対に感染しない
Exploitによる遠隔実行もある実際のメール（テキスト形式）
X‐Message‐Delivery: Vj0zLjQuMDt1cz0wO2k9MDtsPTA7YT0x X‐Message‐Status: n:0 X‐SID‐PRA: [email protected] X‐Message‐Info: JGTYoYF78jHgSoyUVw8OIzMQtmeEJ2IlhrCEpJY0e3cY9GaWUK4Z9/s6+frIGbg7UU0Fpnd1mg9ARVrb62GYxORTM/IHNoEj Received: from bay0‐omc2‐s10.bay0.hotmail.com ([65.54.246.146]) by bay0‐pamc1‐f10.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2444); Sun, 18 May 2008 19:17:15 ‐0700 Received: from BAY118‐W2 ([207.46.8.165]) by bay0‐omc2‐s10.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 18 May 2008 19:17:14 ‐0700 Message‐ID: <BAY118‐[email protected]> X‐Message‐Routing: srcVTZO7LVkOhx4aauZVIA7NfdeTcRtJ4GbFc0mSJ8pCMtxTrDqByCo1ZqTNb8oa9akHsfvmlJZr1ctdUydI3Asl73ITJEbR5Cp0pj7mnPJ+r3p5KqhyImQ1vwA== Return‐Path: [email protected] X‐Originating‐IP: [163.209.230.11] From: <[email protected]> To: <[email protected]> Subject: =?iso‐2022‐jp?B?GyRCPnBKcyVhJUclIyUiJEglJCVzJT8hPCVNJUMlSBsoQg==?= Date: Mon, 19 May 2008 11:17:14 +0900 Importance: Normal Content‐Type: text/plain; charset="iso‐2022‐jp" Content‐Transfer‐Encoding: 7bit MIME‐Version: 1.0 X‐OriginalArrivalTime: 19 May 2008 02:17:14.0505 (UTC) FILETIME=[7407BF90:01C8B956] $BCO5e4D6‐2J3X2J(B 2200000000 $B@nLn!!M&5$(B $B$+$o$N!!$f$&$‐(Bテキスト形式のメールは本文のみ
電子メールの本文は7bit JISで送受信される
7bit=ASCIIコード0∼127
コンピュータで扱う最小単位が8bit(1バイト)なので，1bitを エラーチェックに使用(パリティビット) 電子メールでは7bitの文字しか送受信できない
パソコンで使われている文字コードShift JISは8bit UNIX/Linuxで使われている文字コードEUCも8bit 最近使われているUnicodeはいろいろあるがUTF-8は8bit 文字符号化方式としての名前は「ISO-2022-JP」
Content‐Type: text/plain; charset="iso‐2022‐jp"
Content‐Transfer‐Encoding: 7bit
実際のメール（リッチテキスト形式）
Content-Type: multipart/alternative; boundary="_63b24681-6e7a-40e6-b258-246e90b8dfd3_" X-Originating-IP: [163.209.230.11] From: <[email protected]> To: <[email protected]> Subject: =?iso-2022-jp?B?GyRCPnBKcyVhJUclIyUiJEglJCVzJT8hPCVNJUMlSBsoQ g==?=Date: Mon, 19 May 2008 11:07:02 +0900 Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 19 May 2008 02:07:02.0598 (UTC) FILETIME=[074E2660:01C8B955]
--_63b24681-6e7a-40e6-b258-246e90b8dfd3_
Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit $BJ*M}2J3X2J(B 2200000000 $B?eLn!!$$$E$_(B $B$_$:$N!!$$$E$_(B --_63b24681-6e7a-40e6-b258-246e90b8dfd3_
Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit <html> <head> <style> .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } </style> </head> <body class='hmmessage'> $BJ*M}2J3X2J(B<BR> 2200000000<BR> $B?eLn!!$$$E$_(B<BR> $B$_$:$N!!$$$E$_(B<BR> <BR></body> </html>
--_63b24681-6e7a-40e6-b258-246e90b8dfd3_--一つのメールに複数のコンテンツ
multipart/mixed
複数のコンテンツを含む
メールソフトはそれぞれのコンテンツを扱う必要がある 添付ファイルを付けるとこうなるのが普通
multipart/alternative
含まれるコンテンツは同じ内容
テキスト形式とHTML形式を同時に送るのに使われる どちらかを表示すればよい
multipartはRFC2046に規定されている
RFC=インターネットにおけるルール
「boundary=」で区切り文字列を定義
「--区切り文字列」で開始。「--区切り文字列‒-」で終了。
テキスト形式でないと本当にいけないのか？
最近のメールソフトであればmultipart/alternativeに対応済み HTML部分の表示も可能 携帯メールはまだダメかも ウイルス感染を防ぐ方法としては無意味 添付ファイル、URLクリックによる感染はテキストメールでも HTMLメールでも同様に起こる 偏屈な相手を怒らせないくらいの意味しかない でも、世の中には結構多い 教員へのメール（単位に影響）、就活での会社へのメール（就職に影 響）は、人生への影響があるので気をつけよう テキストの改行についても同じ 半角70文字（全角３５文字）以内で改行するのがマナー…と言われてい る【参考】テキスト形式のメールを作成する方法
Windows Live Hotmailの場合
新規作成画面で「差出人」の上あたりを見る
「リッチテキスト形式」となっていればリッチテキスト形式＝HTMLメー ル 直接HTMLを記述する場合は「HTMLタグ形式」 「テキスト形式」を選択すればテキスト形式に フォントを選べなくなる その他の場合
Windows Liveメールなら「書式」メニューで切替可 Outlook Web Appなら画面上部のリストボックス @kadai.jpはこれ
Gmailなら本文入力領域上のリンク（書式なしのテキスト） Yahoo!メールなら件名右のリンク
いろいろなメールサーバ
SMTPサーバ（送信メールサーバとも）
メールの送受信を行うサーバ 厳密な意味でのメールサーバはこれだけ POPサーバ（受信メールサーバとも）
メールをダウンロードさせるサーバ IMAPサーバ
メールをダウンロードさせるサーバ Webメールサーバ
Webブラウザを使ってメールを送受信・読み書きできるサーバ SMTPサーバ(+IMAPサーバ)とメールソフトが一緒になったよう なものSMTPサーバ
SMTPプロトコルを用いて電子メールの送受信を行うソ
フトウェアが動いているサーバ
このソフトウェアをMTA(Mail Transfer Agent)という
古くはsendmailが有名、最近はqmail、postfixなど。
自分が最終目的地でないメールを受信した時は最終目的
地に向けて送信する＝中継
メールソフト(MUA=Mail User Agent)から送信メールサーバに
送ったメールは「中継」される
SMTPサーバでの迷惑メール対策
メールソフトからの送信のみTCP587番ポートでも受け付け
るサーバが増加
OP25B(Outbound Port 25 Blocking)によりTCP25番ポー
トを遮断
TCP25を使って迷惑メールを最終目的地のサーバに直接送信
するウイルスの動きを遮断できる
メールソフトで使っているSMTPサーバは簡単にはわからないので最 終目的地に直接送る POP before SMTP
POPの認証に成功したPCのみ送信可能な仕組み
SMTP-AUTH
ユーザー名とパスワードで認証
この２つのいずれかがあればウイルスにばれても大丈夫
POP・IMAPサーバ
SMTPサーバに到着したメールをPCなどにダウン
ロードさせるソフトウェアが動いているサーバ
POPプロトコル(より厳密にはPOP3)
TCP110
qpopper
IMAPプロトコル(より厳密にはIMAP4)
TCP143
UW IMAP, Courier-IMAP, Cyrus IMAP
ユーザー名とパスワードを使って認証
メールの暗号化
ユーザ名、パスワード、メール本文はすべて暗号化されずにネットワーク 上を流れる SMTPサーバ同士の通信はどうしようもないが、PCとサーバの間は「SSL」 により暗号化可能 サーバが対応している場合のみ 2種類 over SSL＝最初から暗号化→専用ポート STARTTLS＝途中で暗号通信に切替→従来のポートでOK（TLS≒SSL） 使用TCPポート SMTP over SSL = TCP465 STARTTLS(SMTP) = TCP25,587 POP over SSL = TCP995 STARTTLS(POP3) = TCP110 IMAP over SSL = TCP993 STARTTLS(IMAP4) = TCP143Outlook Live App ‒ @kadai.jp
の場合
受信メールサーバ
サーバ名: pod51021.outlook.com
プロトコル: POP3 over SSL/IMAP over SSL
ポート: 995/993
送信メールサーバ
サーバ名: pod51021.outlook.com
