ビジネスにおける電子メールの使い方とセキュリティ

平成 15 年度豊橋市中小企業技術者研修
IT を活用したビジネス革新講座（２）
∼ビジネスにおける電子メールの使い方とセキュリティ∼
朝日大学経営学部奥山徹
ビジネスにおける電子メールの使い方とセキュリティ
朝日大学経営学部奥山徹
第一回
電子メールの概要とビジネスレターとしての電子メール
１．１．はじめに
電子メールはいまやインターネットの普遍的なツールとして定着した感があります。例えば、通信
総合研究所（MIN：Marketing Interactive Network: http://www.commerce.or.jp/）のアンケート調
査によれば、2001 年の第 21 回「インターネット利用者アンケート」
（2001 年 3 月 12 日から 15 日に
調査、母数：3653、http://www.commerce.or.jp/result/min21/index.html）では電子メールの利用の
有無を問う設問（なお、結果は 98.6％が電子メールを利用すると答えている）がありますが、2003
年の第 38 回「ブロードバンド＆インターネット・ショッピング利用実態調査Ⅵ」
（2003 年 6 月 5 日
から 15 日に調査、母数：7,037、http://www.commerce.or.jp/result/min38/index.html）では電子メ
ールの利用の有無に関する設問はもはやありません。もちろん、2 つの調査は目的が異なるために、
あえて電子メールの有無について触れていない可能性がありますが、両者とも電子メールの送受信数
に対する調査項目はありますので、第 38 回の調査では、既にインターネットユーザのすべてが同時
に電子メールを使っていると判断し、設問項目を設けなかったとするほうが妥当なように思えます。
これは、インターネットユーザにとり、電子メールの利用が浸透したことを示していると考えられま
す。
一方、ビジネスにおける動向は、少し古い調査ですが、E ジャパン協議会（http://www.ejf.gr.jp/）
の企業における電子メールの利用、及びインターネットのビジネス利用に関する動向調査（2001 年
3 月実施、http://www.ejf.gr.jp/report/daikigyo.htm）の結果では、インターネットに接続している企
業の 98.3%が電子メールを利用していると答えています。
（1999 年度の調査では 89.5%でした。
）そ
れから2 年経過した現在、
企業における電子メールの利用率もほぼ 100%に達している推測されます。
しかしながら、同じ調査の普及率では図 1-1 に示したように、必ずしも全社員に普及しているわけで
はありません。この状況は、少しは改善されてきているとしても、それほど大きく変動しているとは
思えません。
（これは、筆者の種々の企業と付き合っている現場での直感です。きちんとした調査に裏
付けられた結果ではありません。
）
このように、電子メールの利用者は日常的な利用や企業活動の利用を問わず、インターネットユー
ザのほぼ全体に浸透していると考えてよいでしょう。ところで、インターネットにおける電子メール
が配送される仕組みを理解して、インターネットにおける電子メールの脆弱性や問題点を把握してい
るユーザはどれくらいいるのでしょうか？これも筆者の観測からの私的意見ではありますが、
（別に知
らなくてもよいのも事実なのですが）ほとんどのユーザは電子メール配送の仕組みを知らないと思わ
れます。また、電子メールの脆弱性や危険性については、おぼろげながら認識していますが、実際の
問題点について把握している人は少ないと思われます。そこで、本講座では、電子メールの仕組みか
らはじめて、電子メールの問題点を最初に考えます。さらに、ビジネスシーンでの利用を前提に置い
た問題解決策を考え、最後に、ビジネスでの利用全般の問題点について取り上げます。
−1−
平成 15 年度豊橋市中小企業技術者研修
IT を活用したビジネス革新講座（２）
∼ビジネスにおける電子メールの使い方とセキュリティ∼
朝日大学経営学部奥山徹
図 1-1．企業内での電子メールの普及率（数値は%）
１．２．電子メールの利用の実態
それでは、
これまでに示しました調査結果から、
電子メール利用の実態について見ておきましょう。
まずは、MIN の調査におけるインターネット全体の利用目的の変化について、第 21 回と 38 回の調
査結果を比較してみましょう。
2003年度
2001年度
仕
オ
ン
ラ
イ
ン
事
ゲ
や
ー
学
個
ム
仕
仕
業
人
な
事
事
オ
上
的
ど
や
や
ン
の
の
な
学
学
個
個
ラ
コ
コ
エ
イ
業
業
人
人
ミュ
ミ
ン
ン
ュ
上
上
的
的
タ
・
ニ
ニ
の
の
な
な
シ
ー
ケ
ケ
情
情
情
情
ョッ
テ
ー
ー
イ
報
報
報
報
ピ
シ
シ
メ
収
収
発
発
ン
ン
ョ
ョ
集
集
信
信
グ
ン
ン
ト
そ
の
他
インターネットの利用目的
0
10
20
30
40
50
60
70
80
図 1-2. インターネットの利用目的
図 1-2 は 2 つの調査におけるインターネットの利用目的を示したものです。残念ながら 2 つの調査
は回答方法が異なるので、直接数値を比較することはできません。しかしながら、傾向を知ることは
できます。若干の違いはありますが、両年度ともほぼ同じような傾向を示していると考えて差し支え
ないと思います。一方、電子メールの利用目的の調査は、第 21 回の調査（2001 年度）のデータしか
ありません。全体の利用目的と電子メールの利用目的の関係を図 1-3 に示します。図に示したとおり、
電子メールの利用目的はコミュニケーションが中心となります。この傾向は 2003 年度も同様である
と推測されます。
−2−
平成 15 年度豊橋市中小企業技術者研修
IT を活用したビジネス革新講座（２）
∼ビジネスにおける電子メールの使い方とセキュリティ∼
朝日大学経営学部奥山徹
全体
電子メール
仕
事
や
学
業
上
オ
ン
ラ
イ
ン
ゲ
ー
ム
仕
仕
な
事
事
オ
ど
や
や
ン
の
の
学
学
個
個
ラ
コ
エ
イ
業
業
人
人
ミュ
ミュ
ン
ン
上
上
的
的
タ
・
ニ
ニ
の
の
な
な
シ
ー
ケ
ケ
情
情
情
情
ョ
テ
ー
ッ
ー
イ
報
報
報
報
ピ
シ
シ
メン
発
収
発
収
ン
ョン
ョン
信
集
信
集
グ
ト
そ
の
他
インターネットの利用目的
0
10
20
30
40
50
60
70
80
90
図 1-3. 電子メールの利用目的（2001 年度調査）
次に、電子メールの送受信の件数を比較しておきます。表 1-1 は、2001 年度と 2003 年度の電子メ
ールの送受信数を示します。
（ただし、両者のデータとも自宅でのインターネット利用者を対照として
います。
）
表 1-1. 電子メールの送受信数
受信数（2001）送信数（2001）受信数（2003）送信数（2003）
100～200 通未満
75～100 通未満
50～75 通未満
25～50 通未満
20～25 通未満
15～20 通未満
10～15 通未満
5～10 通未満
3～4 通
1～2 通
1 通未満
不明
3.4
4.3
8.4
20.1
11.5
12.8
14.7
15.8
4.8
2.7
1.1
0.4
0
0.2
0.2
1.3
1.3
2.1
4.8
21.3
28.4
27.5
12.5
0.1
7.2
3.4
5.6
16.1
7.8
9.5
10
15.4
7.9
7.9
5.2
3.9
0.3
0.2
0.4
1.3
1.3
1.9
3.1
12.6
18.1
32.2
27
1.5
平均
33.3
5.4
27.98
4.57
表に示す通り、電子メールの送受信数は若干減少傾向にありますが、ほぼ横ばいと見てよいでしょ
う。
次に、ビジネスでの利用を E ジャパン協議会のデータから示します。
（2001 年度のデータです。
）
表 1-2 は企業での電子メールの利用状況を示すものです。
−3−
平成 15 年度豊橋市中小企業技術者研修
IT を活用したビジネス革新講座（２）
∼ビジネスにおける電子メールの使い方とセキュリティ∼
朝日大学経営学部奥山徹
表 1-2. 企業における電子メールの利用状況
同一建物内
国内事業
所間
取引先以外
海外事業
国内取引先海外取引先
の外部企業
所間
利用頻度
頻繁に利用
たまに利用
77.4
66.4
11.0
76.4
62.1
14.3
22.9
12.3
10.6
73.7
41.5
32.2
26.6
11.3
15.3
46.5
18.9
27.6
接続形態
イントラネット
イントラネット以外
インターネット
商用電子メール
パソコン通信
74.7
17.9
7.7
1.3
0.4
59.1
15.7
22.6
1.7
1.3
21.7
8.7
68.1
1.4
1.4
11.7
5.4
71.6
5.0
3.2
11.3
3.8
83.8
1.3
-
12.1
5.0
77.1
4.3
1.4
データの種類
テキスト
業務データ
画像・映像
音声・音楽
93.1
78.5
40.8
3.0
90.9
76.5
45.2
1.3
89.9
72.5
46.4
1.4
90.5
57.2
38.7
1.4
96.3
57.5
38.8
1.3
92.9
43.6
39.3
1.4
利用用途
業務連絡・周知
98.3
98.3
94.2
82.9
85.0
83.6
各種データの共有・共用
82.0
75.7
56.5
40.1
30.0
33.6
決裁・稟議
15.5
13.9
4.3
1.8
0.7
電子取引
2.6
2.2
2.9
11.3
6.3
5.7
表に示したとおり、約 75％の企業が、自企業内だけでなく、他の国内取引先との間で電子メールの
交換を行っています。このような傾向は、現在ますます強まっています。また、海外との電子メール
での連絡もさらに拡大しているものと推測されます。
１．３．懸念される問題
このように、一般利用にしろビジネス利用にしろ、電子メールの利用は拡大しつづけています。で
は、
電子メールを利用する場合の問題点は無いのでしょうか。
一般に電子メール利用上の問題として、
次のような 3 つの点が指摘されています。
（１）セキュリティ問題：電子メールに関するセキュリティに関連した問題であり、次のような各
種の問題点が指摘されています。
(ア) ウイルス問題：ウイルスの伝染媒体として電子メールが利用されています。特に MIME
（Multi-Purpose Internet Mail Extension）の普及により、各種のファイル形式を電子メー
ルに添付できるようになってからは、電子メールの添付ファイルをウイルスの最大の媒介源
となっています。
(イ) 情報漏洩問題：インターネットを利用する電子メールは中間に位置するたくさんのネットワ
ークを経由して配送されます。中間のネットワークやルータで電子メールを運ぶパケットを
盗み見されると情報漏洩が生じます。また、サーバ管理者やクラッカーによりメールサーバ
にスプールされたメールを盗み見される危険性もあります。
(ウ) 情報改竄問題：情報が漏洩するだけでなく、時として電子メールの内容を改竄されてしまう
かもしれません。電子商取引や電子決裁では、このような事態は深刻な問題となります。
−4−
平成 15 年度豊橋市中小企業技術者研修
IT を活用したビジネス革新講座（２）
∼ビジネスにおける電子メールの使い方とセキュリティ∼
朝日大学経営学部奥山徹
(エ) 認証問題：例えば電子メールの送信者は簡単に偽造できます。偽造された送信者からのメー
ルによる取引は、偽の電話による出前の注文のような状況を想定していただければよいでし
ょう。
（２）安定性問題：
(ア) システムの安定性の問題：電子メールシステムはメールが通過するネットワークの状況に強
く依存します。途中のネットワークやメールを扱うサーバの状況によってはメールが途中で
消えてしますことがあります。また、電子メールを送信する方の注意が欠落すると簡単に未
着問題が発生します。
(イ) 巨大メールの取り扱い問題：MIME の普及により各種のファイルを電子メールに添付できる
ようになると、メールの容量自体が巨大となります。このような状況では、メールサーバの
設定やアクセスラインの状況によっては電子メールを正しく取り扱えなくなる場合があり
ます。また、多くのプロバイダは電子メールの保持件数や一通あたりの電子メールの容量を
制限している場合が多く、あまり大きな添付ファイル付のメールは配送されない場合があり
ます。
(ウ) フィルタリング問題：セキュリティ問題や迷惑メールと関連して、一定のメールアドレスの
発信者からのメールをフィルタリングしたり、特別フォルダに納めたりする設定ができるメ
ールソフトウェアが急増しています。そのような設定では、インターネットの Web サイト
からブラックリスト形式のフィルタリングアドレスを取得する場合が多く、そのようなリス
トに自身のメールアドレス（所属するドメイン名からのメールアドレスを含む）が掲載され
ると、メールがフィルタされて未着問題を引き起こす場合があります。また、個人的なフィ
ルタリング設定の失敗により、メールが届かない状況が発生する場合があります。
（３）迷惑メール問題：
(ア) SPAM メール：SPAM メールと呼ばれる一連のメールが到着することがあります。これは、
受け取るいわれのない各種のメールで、例えばダイレクトメールによる商品販売、不幸の手
紙などの各種のチェーンメールなどがあります。これらのメールは送信者を偽造している場
合が多く、SPAM フィルタなどを導入することで一定の効果はあげられますが、フィルタの
情報管理の問題が発生します。
(イ) メール爆弾：サービス妨害攻撃の一種で、大量のメールによりメールサーバの機能を麻痺さ
せたり、受信メールスプールをあふれさせ、新しいメールが到着できない状況に追い込んだ
りします。
(ウ) 各種の広告メール：SPAM メールの一種ですが、広告メールを出す場合は、一定の規則に従
うことが政府の通達により決められています。それを守らない場合は行政指導などを受ける
ことがあります。
(エ) 誹謗中傷問題：例えばメーリングリストなどに入っていて、各種の議論をする場合、時によ
り相手から誹謗中傷メールを送りつけられることがあります。あるいは、相手に対して不快
感を与えるようなメールを出してしまう場合があります。電子メールは書き言葉だけで相手
に意図を伝える必要がありますので、表現には十分注意する必要があります。このような行
為が行き過ぎると、犯罪行為と結びつく可能性はネットストーカー行為となる可能性もあり
ます。
(オ) 犯最行為との関連：電子メールを使った犯罪行為が横行しています。電子商取引行為と関連
した詐欺やメールで知り合った相手からの犯罪行為などが頻発しています。
以上のような問題点について、特にビジネスと関連した部分について、今回の研修の中で取り扱い
ます。
−5−
平成 15 年度豊橋市中小企業技術者研修
IT を活用したビジネス革新講座（２）
∼ビジネスにおける電子メールの使い方とセキュリティ∼
朝日大学経営学部奥山徹
１．４．電子メール配送の仕組み
インターネットの電子メールはどのように運ばれるのでしょうか。その仕組みを見てみましょう。
その前に、インターネットにおける各種のサービスがどのように行われているかを概観します。図 1-4
はインターネットで使われているサービスをモデル化したものです。このようなモデルはクライアン
クライアン
トーサーバモデルと呼ばれています。インターネット上にあるサーバ（
サーバ（Server
トーサーバモデル
サーバ（Server）
Server）は各種のサービスを
行うためのコンピュータおよびその上で稼動しているサービスアプリケーションプログラムを指しま
要求（Request
す。一方、クライアント（
クライアント（Client
クライアント（Client）
Client）はサーバに対してサービスの要求（
要求（Request）
Request）を出し、サーバか
らの返答
返答（Response
（Response）
Response）をユーザに返すためのアプリケーションプログラムあるいはそのアプリケーシ
ョンプログラムが稼動しているコンピュータを指します。クライアントは、一般的にサーバとの通信
制御とユーザインターフェイスの両者を備えています。ここで、サーバとクライアントの間で利用さ
れる通信の約束事をプロトコル（
プロトコル（Protocol
プロトコル（Protocol）
Protocol）と呼んでいます。また、インターネット上でのサービス
を識別するために整数値が使われます。例えば、WWW のサービスなら 80、電子メールなら 25 が使
われます。このようなサービスを識別する整数値をポート番号
ポート番号（Port
（Port Number）
Number）と呼びます。例えば、
最近話題の W32/MSBlaster というウイルスは 135 という番号に初期アタックが来ることが知られて
います。例えば、Personal Firewall の設定で 135 へのアクセスを制限することで MSBlaster の感染
を防ぐことができます。
要求
返答
サーバ
クライア
ント
ネットワーク
図 1-4. クライアントーサーバモデル
例えば、WWW の場合サーバは、Apache（http://www.apache.org/）のような WWW サーバプロ
グラムの稼動しているコンピュータとなります。また、クライアントは IE のようなブラウザが稼動
しているコンピュータとなります。
閑話休題。インターネット上での電子メールサービスを行うために必要なソフトウェアを考えて見
ます。電子メールサービスも図 1-4 のクライアントーサーバモデルによりサービスされています。し
1-5 は電子メールのサービスを
たがって、メールサーバ
メールサーバとメールクライアント
メールクライアント
メールサーバメールクライアントが必要となります。図
行うために必要とされるプログラム群とコンピュータを示したものです。
図 1-5 の説明を行うまでに、電子メールが必要としているアドレスの話をしておきます。インター
（実
ネットで利用されるメールアドレス（
メールアドレス（Mail
メールアドレス（Mail Address）
Address）は、次のような形式に統一されています。
は他の書き方もあるのですが、それは時間があれば説明します。
）
[email protected]
ここで、foo とか bar とかいう書き方はインターネット関係者がよく使う単語で、代名詞の変わりだ
と思ってください。[email protected] の foo の部分がユーザ ID を示します。また、bar.jp はドメイン名と呼
ばれていて、電子メールサービスを行っているメールサーバの名前となります。実は、ドメイン名の
部分はコンピュータの名前ではなく、所属しているネットワークの代表名となっている場合がありま
す。例えば、筆者は電子メールだドレスとして、
[email protected]
を使っています。（ただし、プライベートの場合だけです。大学で使用しているアドレスは
[email protected] です。
）ここで、okuyama がユーザ ID で dsl.gr.jp がドメイン名となり
−6−
平成 15 年度豊橋市中小企業技術者研修
IT を活用したビジネス革新講座（２）
∼ビジネスにおける電子メールの使い方とセキュリティ∼
朝日大学経営学部奥山徹
ます。ただし、これは代表名で省略された書き方で、正確には [email protected] となります。ド
メイン名の話は、どこか別の機会に改めて行いたいと思いますが、電子メールアドレスについての記
述形式については、既によく知っていると思いますので、これくらいにしておきます。
メールサーバ
メールサーバ
メール
スプール
SMTP
ネームサ
ーバ
MTA
MTA
MDA
メール
ボックス
POP3
ＳMTP
MUA
MUA
クライアント
クライアント
[email protected]
[email protected]
図 1-5. 電子メールサービスの仕組み
図 1-5 の説明に移ります。ここでは、説明の都合上 [email protected] から
[email protected] へメールを出すことを考えます。ここで、図中の MTA や MUA などの記号は表
1-3 にようなアプリケーションを指します。 MTA としては、 UNIX 上での sendmail
（http://www.sendmail.org）というプログラムが有名ですが、最近では qmail や postfix と呼ばれる
プログラムも使われています。MUA
MUA はメールクライアント、メールハンドラ、メーラなどともよば
れ、各種のメールプログラムが利用できます。例えば、Outlook、Eudra、Vecky、PostPet、AL-Mail
などです。最近では、今回の実習でも使う Web メーラと呼ばれる Web 上でのインターフェイスも提
供されています。MUA の機能は、ユーザにメールを読み書きするためのユーザインターフェイスを
提供するとともに、作成したメールを MTA に転送したり、MDA に接続して、到着しているメール
を読み出したりします。MDA
MDA は MTA により受け取られて、ユーザのメールスプールに保存された
電子メールを MUA の要求に応じて処理する（MUA に転送するとかメールスプールから削除すると
か）ためのプログラムで、POP3（qpopper など）や IMAP4（IMAP サーバなど）と呼ばれるプロト
コルを使って MUA と通信します。なお、
（）内は代表的なプログラムの名前です。
表 1-3. 図 1-5 中の各記号の説明
記号
説
明
Full Spell
MTA
Mail Transfer Agent インターネット上でメールを転送するアプリケーション
メールのユーザインターフェイスと提供するとともに、MTA と
MUA
Mail User Agent
接触し、メールを送り出すアプリケーション
メールクライアントからの要求に応じてメールスプール中に存
MDA
Mail Delivery Agent
在するユーザのメールを MUA に転送するアプリケーション
−7−
平成 15 年度豊橋市中小企業技術者研修
IT を活用したビジネス革新講座（２）
∼ビジネスにおける電子メールの使い方とセキュリティ∼
朝日大学経営学部奥山徹
ユーザがメールを送る場合は次のような手順となります。
（１）ユーザは自分自身のコンピュータの MUA を起動し、電子メールを作成します。
（作
成の手順は書く MUA で異なるので省略します。Web メーラを使った作成実習を同時
に行います。実習のページを参照してください。
）
（２） MTA に接続して、メールの配送を依頼します。
MUA から配送を依頼された MTA は次の手順に従って、電子メールをドメイン名で示される相手
のコンピュータまで配送します。
（３）メールアドレスのドメイン名からネームサーバを参照して、送るべきメールサーバを
検索して、そのコンピュータの IP アドレスを取得します。
（４）相手のコンピュータの MTA に接続して、メールを配送します。
配送された相手のコンピュータの MTA は次のような処理を行います。
（５）ユーザ ID を参照して、当該ユーザを探します。このとき、ユーザが見つからなけれ
ばエラーメールを生成して、返します。
（６）ユーザの別名で登録されている場合（例えば、 [email protected] は、
[email protected] へ転送するような別名登録がされている場合）
、別名の処理手順
に従って処理します。
（７）別名が登録されていない、あるいは、別名も含めて自分自身のコンピュータのユーザ
を指している場合、ローカルメールシステムを起動して、ユーザのメールスプールに
到着した電子メールを保存します。
以上の一連の操作で、相手のメールスプールまでメールが届いたことになります。メールに対する
別名登録については、時間があれば説明します。
一方、ユーザがメールを読む場合はどのような手順となるでしょうか。以下に、それを示します。
（ア）ユーザは自分自身の MUA を起動し、MDA と接続してメールの有無を確かめます。
（イ）メールが到着していれば、MDA にメール転送を指示します。
（ウ）転送されてきたメールを表示させます。
以上が、電子メールを書く（送信する）および読む（受信する）場合の一連の手続きとなります。
なお、メールを送信する場合は、MTA も MUA も SMTP（Simple Mail Transfer Protocol）と呼ば
れるプロトコルを使います。一方、MTA が MDA からメールを受け取る場合は、POP3（Post Office
Protocol、Version 3）や IMAP4（Internet Mail Access Protocol、Version 4）などを使います。
ところで、MTA や MDA があるコンピュータは、通常ユーザが使っているクライアントのコンピ
ュータとは異なります。
（通常、それらのコンピュータはインターネット上にあります。
）どのコンピ
ュータを使うかは、使用するプロバイダから指示があります。その指示に従って、MUA ごとに決め
られた手順で設定することになります。なお、今回使用する MUA での指定方法は後ほど示します。
MTA のあるコンピュータは通常メールサーバとか SMTP サーバとか呼ばれ、プロバイダからも、
そのような名前で指示があります。また、MDA のあるコンピュータは POP サーバと呼ばれることが
しばしばありますが、これは POP を使っている場合のみ該当する名前です。IMAP を使っている場
合は IMAP サーバと呼ぶのが妥当でしょう。いずれにしても、プロバイダから使用するメールの転送
プロトコル（POP3、APOP、IMAP4 など）と同時に、サーバの名前を指定してきますので、それを
MUA に設定することになります。
１．５．メールヘッダとエンベロープ
さて、技術的な話が続いて少々うんざりしているかもしれませんが、メールに関する重要な話がも
う少しありますので、続けます。
−8−
平成 15 年度豊橋市中小企業技術者研修
IT を活用したビジネス革新講座（２）
∼ビジネスにおける電子メールの使い方とセキュリティ∼
朝日大学経営学部奥山徹
電子メールには必ずメールヘッダ（
メールヘッダ（Mail
メールの本文（Mail
メールヘッダ（Mail Header）
Header）と呼ばれるものとメールの本文（
メールの本文（Mail Body）
Body）
が存在します。本文は、各ユーザが作成したメールそのものですから、特に問題は無いでしょう。メ
ールヘッダは、MTA や MUA がメールを転送する場合に必要とされる情報や各種の付加的な情報が
記述されています。例えば、メールの宛て先（通常「To:」というフィールドが使われます）や差出人
（
「From:」というフィールドが使われます）
、表題（
「Subject:」
）
、あるいは日付（
「Date:」
）などです。
ヘッダの情報はメール作成時に MUA が生成します。図 1-6 はメールヘッダと本文の例です。
図 1-6. メールヘッダと本文の例
図 1-6 の「NO.1：Test Mail」以降を見てください。この中の「Date:」から「X-Mailer:」までが
−9−
平成 15 年度豊橋市中小企業技術者研修
IT を活用したビジネス革新講座（２）
∼ビジネスにおける電子メールの使い方とセキュリティ∼
朝日大学経営学部奥山徹
ヘッダの情報で、罫線の後の「This is a test mail for myself.」以降がメールの本文となります。代表
的なメールヘッダのフィールドの意味を表 1-4 に示します。
表 1-4. 代表的なメールヘッダのフィールドとその意味
フィールド名
意
味
MUA で設定された送り主のアドレス
From
メールの宛て先のアドレス
To
カーボンコピーの宛て先のアドレスのリスト
Cc
ブラインドカーボンコピーの宛て先のアドレスのリスト
Bcc
メールの表題
Subject
メールの発信時刻
Date
メールを発信した送り主のアドレス
Sender
メールに対する返事を送るべきアドレスのリスト
Reply-To
どのメールに対する返事かを示す識別子
In-Reply-To
メールに付けられた個別の識別子
Message-ID:
X-ではじまるもの利用者定義のヘッダフィールド
ヘッダの情報は MUA で作成されます。したがって、多くの MUA は宛て先である To や表題
（Subject）の入力を要求します。しかし、一般的には送り主のアドレスである From などはあらかじ
め MUA に設定されたアドレスを使います。したがって、MUA の設定を間違えると、間違ったメー
ルアドレスを相手に伝えてしまう可能性があります。また、それを逆手にとって、自分のアドレスと
は異なるメールアドレスを From フィールドに挿入してメールを送ることが可能となります。通常の
MUA はユーザインターフェイスの画面で送り主のアドレスを変更することはできませんが、MTA と
SMTP で直接接続すれば、あらゆるメールアドレスを偽造することができます。
では、偽造されたアドレスであるかどうかを見破る方法はないのでしょうか。電子メールにはユー
ザが操作できるメールヘッダ情報とは別に、MUA や配送経路にある各 MTA がつけるエンベロープ
（封筒の宛名書き）が付きます。したがって、エンベロープについている MTA がつけた From 情報
（通常、これを UNIX From とか呼んで、ヘッダの From フィールドと区別します）と From フィー
ルドの情報を付き合わせれば、From フィールド（つまり、送り主のアドレス）が偽造されているか
どうかを調べることができます。ただし、UNIX From は通常では表示されません。MUA に「すべ
てのヘッダ情報を表示する」などのオプションがある場合は、それを使って表示させることができま
す。例えば、図 1-6 で示したメールのすべてのヘッダを表示させると、リスト 1-1 のようになります。
リスト 1-1. 電子メールのすべてのヘッダ（含むエンベロープ）情報
----リスト 1-1 はじまり
From [email protected] Tue Aug 5 11:52:14 2003
>From toyo00 Tue Aug 5 11:52:14 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: from www.inl-au.jp (ns.inl-au.jp [218.224.200.202])
by ns.inl-au.jp (Postfix) with SMTP id 5E12F888CB
for <[email protected]>; Tue, 5 Aug 2003 11:52:14 +0900 (JST)
Date: Tue, 5 Aug 2003 11:52:14 +0900(JST)
Message-ID: <[email protected]>
−10−
平成 15 年度豊橋市中小企業技術者研修
IT を活用したビジネス革新講座（２）
∼ビジネスにおける電子メールの使い方とセキュリティ∼
朝日大学経営学部奥山徹
From: [email protected]
To: [email protected]
Subject: Test Mail
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-UIDL: S"@!!I1Y"!8<a!![jC!!
X-Mailer: WebMailer Ver0.954 on Apache/1.3.24 (Unix) with Mozilla/4.0 (compatibl
e; MSIE 6.0; MSIE 5.5; Windows NT 5.0) Opera 7.03 [ja]
Status: RO
This is a test mail for myself.
Please, ignored.
Cheers,
T. Okuyama
-----リスト 1-1 終わり
リスト 1-1 の最初の 2 行を見てください。これらが、ユーザが定義したヘッダ情報とは独立に付け
られるエンベロープの情報です。例えば、[email protected] からのメールを hotmail.com のメール
サーバ上から出したとすると、この部分はメールを出した hotmail.com のサーバ上の MTA が付けま
すので、当然 [email protected] とは異なる名前から送られたことが UNIX From として付きます。
したがって、これらの情報を総合的に見ると、アドレスが偽造されているかどうかは、大体判断する
ことができます。
１．６．電子メールのマルチメディア化
電子メールにファイルを添付できることは、既によく知られています。例えば図 1-7 を見てくださ
い。ここでは、メールに添付されたファイルがあることを MUA が知らせています。ところで、電子
メールを転送するプロトコルである SMTP には「7 ビットのコード以外は扱わない」というルールが
あります。このルールは現在も有効です。ところが、日本語の例えば Shift-JIS と呼ばれている漢字
コードは 8 ビット目を使います。したがって、そのままでは電子メールに日本語を挿入して送ること
ができません。そのため、電子メールでは、ネットワーク上に送信する場合、日本語のコードを JIS
コードに変換しなければなりません。時々、字化けメールを受け取ることがあるかも知れませんが、
それは、例えば Shift-JIS でそのまま送り出されたメールが、経由するネットワーク上のどこかで 8
ビット目のコードが削除されて、漢字コードとして意味をなさないものとなってしまっているような
ことが、原因として考えられます。
ファイルを転送する場合も同じで、ファイル中のバイト単位の 8 ビット目が落ちてしまうと、デー
タとしては意味をなさなくなります。そこで、電子メールにファイルを添付する場合は、UUENCODE
や Base64 と呼ばれる、ビット列と ASCII 文字の変換プログラムを使って、ファイルの全内容を一度
ASCII 文字列に変換して、それを添付して送信します。一方、受信側では、送信されたメールから
ASCII 文字列に変換された部分を取り出し、それから逆変換を掛けて、元のファイルを復元します。
−11−
平成 15 年度豊橋市中小企業技術者研修
IT を活用したビジネス革新講座（２）
∼ビジネスにおける電子メールの使い方とセキュリティ∼
朝日大学経営学部奥山徹
図 1-7. 電子メールに対する添付ファイルの例
初期の MUA では、これらの処理は手動で行われていました。したがって、ファイルをメールで送
るという操作は、煩雑で煩わしいものでした。しかも、あまり大きなファイルを送ることはネットワ
ークや相手のメールサーバに過度の負担を掛けることから、ファイルを分割して送るなどの処置が必
要でした。一方、各種のファイルを、
「電子メールを使って送りたい」
、という欲求は大きくなるばか
りでした。そこで、各種のマルチメディアファイルを統一的な取り扱う規格が登場しました。それが、
MIME と呼ばれるものです。ここで、MIME の説明を長々とすることはできません。そこで、例を
示して、MIME の勘所だけ説明することにします。リスト 1-2 を見てください。
−12−
平成 15 年度豊橋市中小企業技術者研修
IT を活用したビジネス革新講座（２）
∼ビジネスにおける電子メールの使い方とセキュリティ∼
朝日大学経営学部奥山徹
リスト 1-2. 添付ファイルがある電子メール
----リスト 1-2 はじまり
From [email protected] Tue Sep 9 07:27:40 2003
X-UIDL: dbJ"!%m=!!0`j!!KaZ"!
>From toyo00 Tue Sep 9 07:27:40 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: from 127.0.0.1 (catv-157-053.tees.ne.jp [202.216.157.53])
by ns.inl-au.jp (Postfix) with SMTP id 777AE888CB
for <[email protected]>; Tue, 9 Sep 2003 07:27:29 +0900 (JST)
Date: Tue, 9 Sep 2003 07:44:41 +0900(JST)
Message-ID: <[email protected]>
From: [email protected]
To: [email protected]
Subject: Test Mail 2
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----------PGDbHl83g30GKErg2kkKco"
X-Mailer: WebMailer Ver0.954 on Apache/1.3.27 (Win32) with Mozilla/4.0 (compatib
le; MSIE 6.0; MSIE 5.5; Windows NT 5.0) Opera 7.03 [ja]
Status: RO
This is a multi-part message in MIME format.
------------PGDbHl83g30GKErg2kkKco
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
This is a test mail for attached file.
Please, ignore.
T. Okuyama
------------PGDbHl83g30GKErg2kkKco
Content-Type: application/msword; name="=?ISO-2022-JP?B?GyRCJVMlOCVNJTkkSyQqJDEk
a0VFO1IlYSE8GyhC?=
=?ISO-2022-JP?B?GyRCJWskTjtIJCRKfSRIJTslLSVlJWolRiUjGyhC?=.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="=?ISO-2022-JP?B?GyRCJVMlOCVNJTkkSyQqJ
DEka0VFO1IlYSE8GyhC?=
=?ISO-2022-JP?B?GyRCJWskTjtIJCRKfSRIJTslLSVlJWolRiUjGyhC?=.doc"
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAHAA
AAegAAAAAA
AAAAEAAAfAAAAAEAAAD+////AAAAAHkAAAB/AAAAgAAAAIEAAACCAAAAgwAAAPkCAA
D/////
−13−
平成 15 年度豊橋市中小企業技術者研修
IT を活用したビジネス革新講座（２）
∼ビジネスにおける電子メールの使い方とセキュリティ∼
朝日大学経営学部奥山徹
----リスト 1-2 おわり
まず、ヘッダ中の次の 2 行（リスト中では下線が引いてある）に注目してください。
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----------PGDbHl83g30GKErg2kkKco"
これが、MIME の基本情報になっています。まず、MIME のバージョンは 1.0 であることが示され
ています。MIME はバージョンにより記述が若干異なりますので、このようなバージョン情報が必要
となります。次に、
「Content-Type」が続きますが、これが、このメールに含まれているコンテンツ
のタイプを示すことになります。比較のために、リスト 1-1 の同じ部分を抜き出してみます。
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
リスト 1-1 の場合は、コンテンツタイプは「text/plan」となっています。これは、本文はプレーンテ
キストだけからなることを示しています。一方、リスト 1-2 の方は「multipart/mixed」となってい
ます。これは、本文は複数の部分からなり、それぞれに異なるタイプのコンテンツが存在しているこ
とを示します。そして、その区切り記号が「boundary=”…”」に示されているのです。一方、リスト
1-1 では、テキストの文字セットが「us-ascii」であることが示されていて、転送文字のエンコードが
7 ビットであることが示されています。
マルチパートとなっているリスト 1-2 の最初の部分を見てみましょう。
------------PGDbHl83g30GKErg2kkKco
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
まず、マルチパートの区切りである「boundary=”…”」で示された文字列を探します。すると、その
文字列の下にコンテンツタイプと転送文字コードのビット数が示されています。これは、この部分が
プレーンテキストで 7 ビットエンコードされていることを示しています。
では、次の部分はどうでしょうか。再び、区切り記号を探します。
------------PGDbHl83g30GKErg2kkKco
Content-Type: application/msword; name="=?ISO-2022-JP?B?GyRCJVMlOCVNJTkkSyQqJDEk
a0VFO1IlYSE8GyhC?=
=?ISO-2022-JP?B?GyRCJWskTjtIJCRKfSRIJTslLSVlJWolRiUjGyhC?=.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="=?ISO-2022-JP?B?GyRCJVMlOCVNJTkkSyQqJ
DEka0VFO1IlYSE8GyhC?=
=?ISO-2022-JP?B?GyRCJWskTjtIJCRKfSRIJTslLSVlJWolRiUjGyhC?=.doc"
すると、上のような部分が見つかります。ここでは、まずコンテンツタイプが msword というアプリ
ケーションプログラムで作成され、名前が「name=”…”」であることが示されています。ここでは、
名前は日本語（
「ビジネスにおける電子メールの使い方とセキュリティ.doc」ですので、日本語の部分
−14−
平成 15 年度豊橋市中小企業技術者研修
IT を活用したビジネス革新講座（２）
∼ビジネスにおける電子メールの使い方とセキュリティ∼
朝日大学経営学部奥山徹
も ISO-2022-JP と呼ばれる国際的な文字コード規格で ASCII 化されています。次に、転送文字のエ
ンコードが Base64 で ASCII 化されていることがわかります。最後に、添付ファイルの名前が、やは
り ISO-2022-JP でエンコードされてついています。
では、実際の WORD のファイルはどうのように ASCII 文字列かされているかを示すと、次のよう
な文字列としてメール本文中に挿入されています。
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAHAAAAegAAAAAA
AAAAEAAAfAAAAAEAAAD+////AAAAAHkAAAB/AAAAgAAAAIEAAACCAAAAgwAAAPkCAAD/////
現在の多くの MUA は MIME のマルチパートを自動的に解釈し、必要ならばファイルを展開して
保存してくれます。それはしばしば、Outlook Express に見られるような、行き過ぎた処理を行い、
ウイルスを媒介する原因となっています。したがって、添付ファイルの取り扱いには十分注意する必
要がありますが、それは次回の時に詳細にお話します。
１．７．ビジネスレターとしての電子メール
さて、本研修の一つの目玉がビジネスレターとしての電子メールをどのようにとらえるかというこ
とですが、これについては、E ジャパン協議会が非常によいドキュメントを作成しています。これは、
2003 年 2 月 28 日に出されたドキュメントで、次の URL で参照できます。
http://www.ejf.gr.jp/report/email_guide/index.html
今回の研修でも、このドキュメントを参照しながら、筆者の経験を交えて補足説明を加えていきた
いと思っています。付録に、このドキュメントの PDF 版の全文を示しておきますので、この節に関
してはそちらを参照してください。
１．８．実習環境
今回の実習環境については、サイエンスコアの OA 研修室のパソコンに各自の実習環境を用意しま
した。また、電子メールサーバとしては筆者が管理しているメールサーバを使うことにします。詳し
い実習環境については、当日、各自のユーザ ID とパスワードとともに配りますので、それを参照し
てください。
１．９．実習内容
実習内容については、現在 Web ページ中に準備中です。当日、URL を示しますので、それを参照
しながら、実習を進めたいと思います。内容的には、次のものを予定しています。
（１） MUA の設定：今回はフリーの Web メーラを使います。セットアップまでの手順を見ること
で、メールサーバや POP サーバの本文中での説明を補足します。
（２）メール送受信実験：設定した MUA を使って、実際にメールを送受信してみます。ユーザ ID
とパスワードは当日配ります。
（３）エラーメールの例：各種のエラーメールを生成させ、その原因を考えます。
付録：
「ビジネスにおける電子メール活用ガイド」
、E ジャパン協議会
−15−