2004 年度情報システム構成論

第 9 回 メイルシステム

西尾 信彦nishio@cs.ritsumei.ac.jp

立命館大学情報理工学部 情報システム学科

ユビキタス環境研究室

MTAとMUA

Mail Transfer AgentMail Server

Mail User AgentMail Client

メイル Box• サーバ上のメイルを貯めておく場所• 構築するシステムに沿ったものにする必要がある

（特に NFS を利用する場合は注意が必要）• 古くからさまざまな種類がある• 古株（というより絶滅危惧種）

– MMDF• おそらく一番単純なメイル Box 形式• 現存しているかどうか不明・子孫が SCO システムで使われて

いる？

– BABYL• MIT の昔のメイルシステムが起源• Emacs のメイルリーダモードで使われている場合があります

（ Emacs の仕様変更によっては使われていないかも）

MH 形式

• 古くからあるメイル Box 形式• MH 系ソフトが利用している• メイルが一つ一つ別々のファイルに保管される• ファイル名は連番で記述される• 管理用のファイルを編集する必要がある• 管理用ファイル編集を同時に行うなどするとメ

イルが正しく管理されなくなる場合がある• NFS の場合、正常に書き込まれない場合がある

mbox 形式

• 比較的古くからあるメイル Box 形式• Unix のメイル Box 形式としては一般的• 全メイルがひとつのファイルに凝縮• メイルとメイルの基本的な区切りは From で

始まる行があるかどうかで判断する（メイルの途中で From から始まる行があると > が頭に付く）

• 未対応のメイルソフトが少ないので導入が比較的楽

mbox 形式（問題点）

• 配送途中で（つまりファイル編集中に）サーバが落ちる、他のソフトが同時に書き込む、NFS のマウントが切れるなどするとメイル消失の危険性がある。

• ファイル中で From 行が消失すると、複数のメイルがひとつに融合してしまう可能性がある

• さまざまな亜種が存在するが、その亜種間での互換性は保障されていない

• NFS を利用している場合、ファイルロックを別々のホストで実行すると無意味

Maildir 形式

• 別名 , qmail-maildir 形式• 比較的新しいメイル Box 形式• メイルが一つ一つ別々のファイルに保管される• NFS を意識して NFS 上で利用した場合にも、

正常に処理されるようにしている• 中央制御ファイルを置かないためファイルロッ

クを行う必要がなく、複数のプロセスで利用した場合においても安全

Maildir 形式が安全な理由

• 下記のアルゴリズムを利用しているため1. maildir ディレクトリに 移動する 2. 名前 tmp/time.pid.host の存在をチェック

• time は GMT で 1970 年の開始からの秒数• pid はプログラムのプロセス ID• host は MTA のホスト名

3. すでに同名ファイルがあった場合は、数秒待ち再試行する、これを、回数の上限まで繰り返す

4. tmp/time.pid.host を生成 5. ファイルを NFS 書き込み (NFS-writing) する 6. ファイルを new/time.pid.host に link する

この瞬間、メッセージは正常に配送される

Maildir 形式が安全な理由（ 2 ）

• NFS 書き込み (NFS-writing) とは1. いつものように、各 write() コールから返された

バイト数をチェックする 2. fsync() を呼び出し、戻り値をチェックする 3. close() を呼び出し、戻り値をチェックする などを意味します。

• 標準的な NFS の実装では、 fsync() を誤って処理するが、 close() して書き込みを強要している（ qmail 実装）

• 実際のアルゴリズムは実装による

受信用プロトコル• POP3

– サーバ上のメイル Box から受信– サーバ上のメイル Box からメイルを削除する– サーバ上からメイルを削除するため、メイル Box の容量

が少ない場合などに有効– 単一のマシンでしか同一のメイルを扱うことができない

APOP（ Authenticated POP)

• POP はパスワードを暗号化せずに流すため安全ではない

• APOP は POP のパスワードを暗号化して通信する• 多くのメイルクライアントが対応済み

– Outlook, Outlook Express, Becky!, Sylpheed, Wanderust, etc• 問題

– 多くの場合 , サーバ上のアカウントとは別にパスワードを保存するため , 別途パスワードが必要になる

– パスワードのみ暗号化できるが、メイル本文は暗号化しないため、通信内容は丸見えである (SSL 利用に）

受信用プロトコル• IMAP４

– サーバ上のメイル Box を閲覧– サーバ上のメイル Box からメイルを削除せず、手元にはキャッシュのみを残す

• 携帯電話・ Web メイルなどで利用されている• 複数のマシンで同一のメイルを扱うことができる

IMAP のユーザ認証

• IMAP標準のユーザ認証は暗号化したパスワードを利用しない

• 暗号化したパスワードを利用する方法として、 CRAM-MD5 などが用意されている

• APOP と同様に、暗号化したパスワードを利用する場合はアカウント用パスワードとは別にパスワードが必要になる場合が多い

メイル配送• SMTP プロトコル• DNS の MX レコードを参照して、リ

レー形式であて先まで配送する

A

DC

B

MX レコード•A宛は A まで•B宛は B まで•C宛は C まで•D宛は B まで

MTAとMUA

Mail Transfer AgentMail Server

Mail User AgentMail Client

SMTP が抱える問題点

• 古くに作られたプロトコルであり , 性善説にのっとって作られたプロトコル

• 送り元の判定をしていない– どの SMTP サーバにメイル送信を頼んでも , 目的地に届く

– この特性を SPAM などに利用され、踏み台にされているサーバが多数存在する

• 暗号化されていないため、内容は丸見えである

ユーザ認証機構を付加した SMTP

• POP before SMTP– SMTP 送信を行う前に POP にて認証を行

う– SMTP サーバは POP認証を行ったホスト

に対して認証後、規定時間以内のメイル送信を許可する

POP認証

規定時間以内にメイルを送信

POP認証をしていない（正規の権限がない）ホスト）

POP before SMTP の問題点• 毎回 POP認証を行うため、ネットワークトラ

フィックの増加と、スループットの低下を招く• 送信元を偽ってメイルを出すことによって、誰

かが行った POP認証にまぎれて、メイルを飛ばすことが可能である

POP認証

規定時間以内にメイルを送信

送信元偽装メイルは送信可能

ホスト A

ホスト B

私はA

ユーザ認証機構を付加した SMTP

• SMTP Authentication （ SMTP AUTH ）– 文字通り、 SMTP接続時に認証機構を組み

込んだもの– SMTP接続時に認証を実行する

（暗号化 or plain ）認証　＋　メイル送信

認証されない限り、メイル送信は不可能

ホスト A

ホスト B

SMTP Auth の問題点

• パスワード認証を提供するが、パスワードが暗号化されて利用されるとは限らない

• 暗号化する場合はチャレンジ - レスポンス認証でCRAM-MD5 を利用することになる

• 暗号化したパスワードを利用する場合、アカウント用パスワードとは別にパスワードが必要になる

• たとえ、暗号化したパスワードを利用したとしても、通信内容は暗号化されず、内容は丸見えである

チャレンジ - レスポンス認証• APOPや SMTP/IMAP の暗号化パスワード利用時に

使われる認証方法（ CRAM-MD5 ）• パスワードを直接暗号化したものは利用しない• パスワードを特定方法で符号化（ MD5 などと同

様）し、符号化後のものと符号化の鍵を送信する• サーバ側では、クライアント側と同様に保存して

ある生のパスワードを送られてきた符号化の鍵を使って符号化し、値を比較して成否を判定する

• APOP/SMTP/IMAP などで暗号化パスワードを利用する場合に別途パスワードが必要になるのはこのためである

チャレンジ - レスポンス認証図解

生パスワード

生パスワード

ランダム鍵

②不可逆変換

③不可逆変換

④比較して成否判定 ①乱数発生

チャレンジ - レスポンス認証利点・欠点

• 利点– パスワードそのものを暗号化して送らないため、途中で盗聴

されたとしても、復号してパスワードを取得することはできない

– 鍵をランダムに決めることにより毎回異なる文字列が生成できる

• 欠点– 双方が生のパスワードを保管しておく必要がある– 保管されているパスワードの管理に注意が必要– サーバ側がクラックされた場合は、すべてのパスワードが流

出する– サーバ・クライアント双方であらかじめ利用する符号化方式

をあわせておく必要がある

SSL/TLS の利用• 通信経路すべてを暗号化する• 暗号化された通信経路内で、生のパスワー

ドを利用しても問題ない• 通信経路すべてが暗号化されるため、パスワードのみではなくメイルの内容自体も暗号化することができる

• SSL/TLS証明書により接続先の安全性を検証することができる

SSL/TLS とは

• SSL (Secure Sockets Layer) – Netscape Communications社が開発した通信経路暗号化プロトコル

– はじめに公開鍵暗号化方式で共有鍵を交換し高速な暗号化経路を実現している

– 第三者認証機関が発行した開鍵（電子証明書）を利用することで、サーバ・クライアントが公的に正規のものであることを証明することができる

• TLS (Transport Layer Security)– SSL3.0 に若干の拡張と改良を加えたもの– RFC 2246 として IETF で標準化されている

暗号化非対応クライアントとの共存

• SMTP に SSL のみを組み込むと、 SSL 未対応の SMTP サーバからのメイルを受け取ることができない

• SSL 未対応クライアントが利用できない• はじめに SSL を利用するか（できるか）を選択することを可能にする– SSL 対応 SMTP サーバ間の通信はセキュアに、 S

SL 未対応の SMTP サーバからの通信は今までどおり行うことができる

– SSL 対応・ SSL 未対応クライアント双方を同一サーバで利用することができる

メイルまとめ• メイル Box の信頼性確保のためにシステム

にあったメイル Box 形式を選ぶ• POP はサーバ容量が少なくても利用可能• IMAP は複数のマシンで同一メイルが利用

可能だが、多くのサーバ容量が必要• SMTP メイルのスパム対策は必須• パスワードなどセキュリティ項目の検討

（利用者のクライアントソフト・ネットワーク構成上利用できない場合など）

2004 年度情報システム構成論

第 10 回 多重化とバックアップ

西尾 信彦nishio@cs.ritsumei.ac.jp

立命館大学情報理工学部 情報システム学科

ユビキタス環境研究室

メイルサーバの多重化

• メイルサーバはリアルタイムで情報が届くため、一度稼動させると停止させることが難しい– メンテナンスや故障時など

• 二重化し、一方が停止している場合、バックアップ用のサーバが稼動するように設計することが必要になる

メイルサーバの多重化

• MX レコードを利用して転送先を制御する– MX レコードは複数設定可能– 優先順位により、転送先が自動的に変更される

• 実際の MX レコードの例（ ***.ubi.is.ritsumei.ac.jp宛のメイル配送先）ubi.is.ritsumei.ac.jp IN MX 50 mail1.ubi.is.ritsumei.ac.jp.

IN MX 90 mail2.ubi.is.ritsumei.ac.jp.

メイルサーバ多重化時の注意点

• メイルサーバごとにメイル Box が異なると障害時やメンテナンス時にメイルが分散する– NFS を利用して同一のメイル Box を利用する– NFS を利用するため、メイル Box 形式は Maildir が望ましい

• 双方で同一アカウントを利用する必要がある– NIS/LDAP などで同一アカウントが存在する状態に

しておく• 導入してあるソフトを同一のものにしておく

必要がある

メイルサーバ多重化時の構成例

メイルサーバ

バックアップ

メイルサーバ

NFS NIS

上流メイルサーバ

①メイル配送

②共通のメイルボックスに

追加

①’メイル配送メイルサーバダウン時

ファイルシステムの多重化

• ファイルシステムがクラッシュすると全データが消滅する可能性がある

• 定期的にバックアップを取ることである程度防ぐことが可能– ロールバックはどうしても発生する

• ファイルシステムを多重化する利点– ひとつが壊れた場合でも、正常にサービスを提供し続け

ることができる– サービスを提供しながら、壊れているものを途中で取り替えるなどして、再度多重化状態を構築することができる

RAID（ Redundant Arrays of Independent Disks）• 高速かつ大容量・高信頼性ディスクを構築する方法

• 1987 年にカリフォルニア州バークレー大学で発表された「 A Case for Redundant Arrays of Inexpensive Disks」という論文が基礎となっている

• 上記のように、もともとは安価（ Inexpensive ）なディスクを利用することを前提にしていたものであるが、現在は個別（ Independent ）のディスクを用いてという意味になっている

• 専用ハードウェアを利用する方法– 効果、高速、高信頼性

• ソフト上でエミュレートする方法– 安価、オーバーヘッドが大きい、信頼性はソフトと実行環境依存

RAID0• 2台以上のディスクをひとつのディスクとして扱

う• 書き込み、読み込み時は複数のディスクにひとつ

のファイルを分散し、並列アクセスすることにより高速アクセスを可能にする (striping)

• 理論上、おおよそ接続台数倍のアクセス速度向上が見込まれる

• 分散して書き込むため、ひとつのディスクが壊れた時点で全ファイルが読み出せなくなる– 信頼性という面では期待できず、信頼性は接続台数が多いほど低下する

RAID1• 2台以上のディスクをひとつのディスクと

して扱う• ミラーリングを行い、複数のディスクに同

一の情報を書き込む• 最悪一台のディスクが生き残っていれば、

処理を続行することができる• 信頼性は接続台数を増やすほど向上する• ディスク利用効率は接続台数に反比例する

– 2台同時に利用すれば 1/2 、 3台同時に利用すれば 1/3 となる

RAID5• データに対してパリティを作成する• 作成したパリティとデータを分散して配置する

– ディスクが壊れた場合でも、他のディスク上のパリティから壊れたデータを復旧することが可能

• 専用機器の場合、ディスク故障を自動検出し、自動的に修復するものもある

• 書き込み速度はパリティ計算のため多少低下する• 読み込み速度は並列アクセス可能なため向上する• ディスク利用効率は、ディスク一台分がパリティ

で利用されるが、 ストライピングされるためほぼ接続台数に比例する

その他の RAID• RAID2,3,4 が存在するがほとんど使われていない• RAID0+1

– ミラーリングし、それをさらにストライピングしたもの– 最低 4台以上での構成となる

• RAID6– RAID5 に独立パリティを追加し、複数台異常のディスク

が同時に壊れた場合で、修復可能にしたもの

クラスタリングシステム

• 複数のマシンを相互に接続し、ひとつのマシンのように見せる

• ひとつのサービスに対してサーバを複数用意することにより、一部のマシンが故障しても、全体としてはパフォーマンスが落ちたように見える（サービスそのものは停止しない）

• パフォーマンスや信頼性の向上は単に接続台数を増やすことによって実現できる

• ネットワークトラフィックには注意が必要

クラスタリングシステム図解

一つのシステムとして利用一部ホストが故障中でも全サービスが利用可能